Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mkolmar]

I can pretty much crash MC at will.

All you have to do is overburden MC or the Windows OS in any way, but chiefly related to wait for network-attached storage under any library view in audio. Click mouse button at the very last second before the action is completed, while you get the spinning mouse pointer and classic grey stretch screen.

MC will crash. I have been able to reproduce this for years.

[Matt]

Please provide a crash dump.

[mkolmar]

Please let me know how to produce the most useful logging for this purpose. My sense is that the type of crashes I am talking about fail before logging.

[mkolmar]

My wild but educated guess is that the problem happens under network I/O wait in Windows, where JRiver MC is waiting for OS, and process is "mercifully" killed for some stupid reason rather than being able to wait for network disk. I can make Windows Explorer go into grey screen too, reliably, but it never actually crashes out. I really think MC is the victim of the OS, but I have no way to prove it.

[JimH]

When it seems hung, open Task Manager, right click on MC and choose crash dump.  Then post the file.

[mkolmar]

Would it be sufficient to catch MC while the screen is stretched, but before I click in the window? That's more-or-less the condition that sets up a crash sometimes with one well-timed mouse click. A zipped dump is about 115MB.

If the screen stretches (after about 7-10 seconds usually, if something MC does takes longer than that) a mouse click causes Windows to ask whether to wait or to end the program, and the color lightens. If the timing of that click is just right, instead MC terminates without any warning. It happens in a split second, no way to catch it as it happens unless MC were to log exactly what it's about to do before the app terminates. I did that several times in a short period yesterday, loading different views and timing mouse clicks like it was a game. I was unable to recreate the problem so easily today. With few if any exceptions I can remember, this is always the scenario if MC crashes. Some other factor that I am not aware of may make MC more susceptible to these crashes at times.

[JimH]

Would it be sufficient to catch MC while the screen is stretched, but before I click in the window? That's more-or-less the condition that sets up a crash sometimes with one well-timed mouse click. A zipped dump is about 115MB.

Yes.

[mkolmar]

Where can I upload a zipped dump file? It's too large to post, for one, and has more info than needs to be public.

The issue with blue circle mouse prompt, screen stretch, etc., is related to library size in the sense that if the library is very small, everything in the stock library views responds too quickly for the issue to come up. I tried with an empty library, importing audio files. After a few thousand files, views with several panes of stats, for example, will take long enough to load that the screen will always stretch for a moment. As more files are added, or running import or tagging at the same time, stock views start to take long enough to load that this issue will come up.

[AndreaT]

I can pretty much crash MC at will.

All you have to do is overburden MC or the Windows OS in any way, but chiefly related to wait for network-attached storage under any library view in audio. Click mouse button at the very last second before the action is completed, while you get the spinning mouse pointer and classic grey stretch screen.

MC will crash. I have been able to reproduce this for years.

I am having the same problem even with the last 29.0.50...