View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0018005 | MMW 5 | Other | public | 2021-06-09 02:28 | 2021-07-16 15:03 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | crash | Reproducibility | sometimes |
| Status | closed | Resolution | reopened | ||
| Product Version | 5.0.1 | ||||
| Target Version | 5.0.1 | Fixed in Version | 5.0.1 | ||
| Summary | 0018005: MM crashes on resuming from sleep or hibernation: crashlog 87388314 | ||||
| Description | With 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 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2424 | ||||
|
|
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? |
|
|
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" |
|
|
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). |
|
|
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) |
|
|
Fixed |
|
|
Verified 2414. |
|
|
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). |
|
|
Fixed |
|
|
Verified 2422. |
|
|
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 |
|
|
Fixed |
|
|
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. |
|
|
Fixed |
|
|
Verified cases 1a)-d) & 2a)-d) on 2424 test build; reverified 1a) & 2b) on final build. |
|
|
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 |
|
|
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 |
