View Issue Details

IDProjectCategoryView StatusLast Update
0018005MediaMonkey 5Otherpublic2021-07-16 15:03
Reporterrusty Assigned To 
PriorityurgentSeveritycrashReproducibilitysometimes
Status closedResolutionreopened 
Product Version5.0.1 
Target Version5.0.1Fixed in Version5.0.1 
Summary0018005: MM crashes on resuming from sleep or hibernation: crashlog 87388314
DescriptionWith build 2413, MM was running and the system wasn't being used. When I came back to the machine I found that:
- the machine had turned off (likely due to overheating?)
- MM had crashed (crashlog 87388314)
- Explorer was crashed (i.e. desktop and taskbar processes were broken) and would not restart until MM was terminated
TagsNo tags attached.
Fixed in build2424

Relationships

related to 0017716 closedpetr Crash 9E764AA2 on resuming use of the computer after about 10 hours 
related to 0017654 feedbackpetr Issues with new version of Eurekalog (regression) 
related to 0018026 closedpetr MM5 crash while running in the background : C7BC8314 

Activities

Ludek

2021-06-09 10:17

developer   ~0063846

Last edited: 2021-06-09 10:21

View 4 revisions

Seeing crash 87388314 and it is UI freeze error, the PC slept for 3 hours, then woke up and the only activity that I see in the UI thread before the "freeze detection" were repeated messages like this on the UI thread:

                 15619.203s - PID:9964 - MM5 [17304](B) enumDisplays begin ... UISettingsTextZoom is 1
                  15619.203s - PID:9964 - MM5 [17304](B) Device \\.\DISPLAY1 ratio is set to 1.5
                  15619.203s - PID:9964 - MM5 [17304](B) Device \\.\DISPLAY2 ratio is set to 1
                  15619.203s - PID:6196 - MM5 [21020](R) enumDisplays begin ... UISettingsTextZoom is 1
                  15619.203s - PID:6196 - MM5 [21020](R) Device \\.\DISPLAY1 ratio is set to 1.5
                  15619.203s - PID:6196 - MM5 [21020](R) Device \\.\DISPLAY2 ratio is set to 1

Assigning to Petr to review whether it is just Eureka's false positive freeze log after PC wake up (e.g. counting the time when the computer slept as freeze time ?? ) or whether the repeated enumDisplays can be reason for the freeze?
I suspect that there is no reason to call enumDisplays so many times in a row?

Ludek

2021-06-09 10:30

developer   ~0063847

Last edited: 2021-06-09 10:33

View 3 revisions

Otherwise based on the DbgView part seen in 87388314 I doubt that MM was the reason for the PC going to sleep, MM was doing absolutely nothing and it even did not receive the 'r_power_state' message so that it can call Eureka's DisableAntiFreeze before falling asleep.

It must have been something else on your PC causing all of sudden "sleep" or "overheating"

rusty

2021-06-09 11:41

administrator   ~0063853

Ok. But regardless of what caused the PC to go to sleep, mm5 shouldn't have crashed and shouldn't have caused the entire explorer process to stop working (to reiterate, explorer would only work once mm was force terminated).

Ludek

2021-06-09 14:32

developer   ~0063857

Last edited: 2021-06-09 14:36

View 3 revisions

Yes, this looks exaclty like your 0017716 in the past, it was not standard sleep/hibernate so Petr's code to disable Eureka's freeze detection before falling asleep was not applied.
Hard to say what we can do about this and whether Eureka can really somehow cause explorer process to stop working (added relation to 0017654).

Moving to 5.0.2 as it affects just small percentage of users atm (only when using debug build and only when windows sleep/hibernate isn't entered a standard way)

petr

2021-06-09 21:17

developer   ~0063873

Fixed

rusty

2021-06-09 23:38

administrator   ~0063878

Verified 2414.

rusty

2021-07-07 12:45

administrator   ~0064176

I observed a similar crash with build 2421 just by running MM in the background (the machine turned off and showed crashlog E1CE8314 ). As before, it was particularly nasty since it also stopped explorer.exe from functioning properly (e.g. taskbar didn't display correctly) and from restarting (explorer.exe would only restart after the MM process was force-terminated).

petr

2021-07-07 19:26

developer   ~0064184

Fixed

rusty

2021-07-07 21:35

administrator   ~0064187

Verified 2422.

rusty

2021-07-12 20:33

administrator   ~0064203

Last edited: 2021-07-12 20:48

View 2 revisions

Re-opening. This (crash + MM locks the explorer process on wake) just occurred again for me on build 2422. Crashlog was submitted.

note: in contrast to my tests of the fix which verified the bug by configuring the PC to go to _sleep_ after a few minutes of no power, it appears that the cause of this crash was that the machine went into _hibernation_ (i.e. the power button had to be clicked to wake the machine rather than pressing keyboard keys which would normally work to wake a machine from 'sleep' mode). As to why the machine went into hibernation, I'm not sure--the only power setting for which hibernation was enabled as an action is: Power settings > Additional power settings > Change advanced power settings > Critical battery action > On battery/Plugged in: hibernate

petr

2021-07-13 12:30

developer   ~0064207

Fixed

rusty

2021-07-13 23:33

administrator   ~0064212

Last edited: 2021-07-13 23:34

View 2 revisions

Retested build 2423 (final) by resuming from hibernation on battery power (I'd previously tested the test build with power) and MM crashed with crashlog AB1A8314.

Log attached.

petr

2021-07-14 13:30

developer   ~0064217

Fixed

rusty

2021-07-14 23:28

administrator   ~0064223

Verified cases 1a)-d) & 2a)-d) on 2424 test build; reverified 1a) & 2b) on final build.

peke

2021-07-15 01:43

developer   ~0064227

I also verified cases 1a)-d) & 2a)-d) on 2424, Also verified 3a)-d) in Release build

NOTE: 3c)-d) is also tested while conversation is happening

peke

2021-07-15 01:49

developer   ~0064228

Also tested:
4) Deep sleep (AMD and Motherboard function where PC Goes to sleep, but also hibernation file is written in case of power loss)
a) MM in focus
b) MM not in focus
c) MM minimized
d) MM UI obscured by another app

Finally
5) Force Hibernate / resumption that do not generate crash and Video/playback stays paused on resumption
a) audio/video playback
b) audio/video remote playback (UPnP / Chromecast)
c) serving content via UPnP
d) syncing

Steps to test 5):
1. Right click on Start -> Power Options
2. Open Additional power settings (right part of dialog)
3. Select on left what power button do
4. Select Hibernate on power button press
5. Test cases a)-d) so that forced interruption not crash MM and show info/log of canceled/failed action