View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0018283 | MMW 5 | General | public | 2021-09-12 03:27 | 2022-11-12 00:25 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | crash | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Product Version | 5.0.2 | ||||
| Target Version | 5.0.4 | Fixed in Version | 5.0.3 | ||
| Summary | 0018283: Crash or Black screen on resume from sleep/hibernation (5.0.2 logi ID 4AD4000) | ||||
| Description | 1 Ran MM5 build 2502 and initiated auto-tag on several files 2 PC went to sleep (with the auto-tag window open) 3 PC woke from sleep (after 25 hours). Signed into the PC. 4 Clicked the auto-tag dialog --> crashlog 4AD4000 | ||||
| Additional Information | Ticket 3622 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2619 | ||||
| duplicate of | 0019063 | closed | rusty | Crash when resuming from sleep on systems using 'Modern standby' |
| related to | 0018447 | closed | petr | Changing display causes Minimize/Maximize/Close buttons to stop working |
| related to | 0017072 | resolved | petr | Micro Player: stops responding & other issues |
| related to | 0018584 | closed | Ludek | Task queue deadlock detected - crashlog 0AF10000 |
| related to | 0019008 | closed | michal | Wake from sleep 2x causes Taskbar to "progress" indefinitely and Playback to start by itself |
| has duplicate | 0018343 | closed | petr | Scrolling in Tracklist --> crash AB1A000 |
| related to | 0017835 | assigned | petr | Dialogs sometimes fail to render (appear black) |
| related to | 0018847 | closed | petr | Update Chromium to v98 |
| related to | 0018609 | closed | Ludek | Some users can't run MM5 (until HW accelaration is disabled) |
|
|
Debug log didn't help to show root of the issue so i've added some debug. |
|
|
I haven't been able to replicate this in 2508. Resolving. |
|
|
Re-opening as a variant just occurred with 2513. No crash occurred, but on resume, all other app windows functioned, but MM appeared as a black square. After clicking the black square, the UI re-appeared and seemed to function normally. Testing further, but I believe that the issue occurred when the PC hibernates or overheats AND the laptop lid is closed (for the past few months I've been testing with the laptop lid open so that may be why it didn't occur). |
|
|
I've added some switches based on recomendations on the internet, so please retest in next build. |
|
|
Verified 2514. I'll retest again to make certain, but looks good! |
|
|
So I spoke too soon. This log covers the following: 1 Set Windows to Extend mode (primary-laptop; secondary-very-hi-res monitor) 2 Close laptop cover 3 Run MM on the secondary screen 4 No activity for an hour so that laptop goes into hibernation 5 Open laptop and log-in (around line 10,000 in the log) --> MM appears as a black box on the primary monitor 6 Drag MM window to secondary monitor --> MM still appears as a black box! 7 No activity for about 5 minutes so monitor goes to sleep (I don't think that the laptop actually went to sleep since iirc I didn't have to log in) 8 Click the mouse --> Secondary screen re-activates and MM displays normally (around line 11,000)! |
|
|
Unable to replicate with the latest test build provided by Petr. |
|
|
Fixed |
|
|
Unfortunately, build 2515 has a worse manifestation of this issue--the black screen sometimes occurs even without switching monitors (i.e. the bug is much worse). The issue seems to be preceded by failure of the min/resize/maximize buttons to work (I don't think its a trigger though). e.g. 1 Set Windows to Secondary Monitor only (primary-laptop; secondary-very-hi-res monitor). All tests are only on the secondary monitor. 2 Run MM and Leave the PC --> it hibernates 3 Turn PC on and log in --> MM appears normally and functions normally 4 Run an app that appears on top of the MM window 5 Leave the PC --> it hibernates 6 Turn on the PC and log in 7 Go to the MM window (around line 112000) in the log --> MM appears normally, but the Minimize/Maximize/Resize buttons dont function 8 Attempt to resize the window --> It turns black I then attempted various actions to get the Window to re-appear, but nothing worked and MM had to be force-terminated. Log posted to the ftp server. Note: I've seen this occur a few times, but was unable to capture it in a short log until now. |
|
|
Unfortunately this black window is the chromium issue and workaround don't work well for current build ... hopefully any future chromium build will fix this issue. Related info https://bugs.chromium.org/p/chromium/issues/detail?id=156038 https://stackoverflow.com/questions/60939551/black-screen-in-chrome-after-sleep |
|
|
A couple of other details: - After resuming the PC, if upon hovering over the Minimize/Resize/Maximize buttons and they don't highlight, it means that the issue is going to occur. i.e. this issue may be somehow related to 0018447. - The issue also occurs if just using the laptop screen (i.e. no secondary monitor at all) |
|
|
Tested 2520 and the hibernation-related crashes seem to be partially fixed. What is now happening is that: However, a side effect of the fix is that on resume from Sleep or Hibernation MM often remains frozen for about 0-60 seconds (0-10 seconds for Sleep, 0-60s for Hibernation) during which: - UI interactions are queued and take place at the end of the 'freeze' - Attempts to resize the dialog result in the 'black space bug', until the end of the freeze at which point it self-corrects Note: on some occasions ?1/10?, the issue doesn't self correct. |
|
|
Probably fixed in 2523 by the same fix as 0018584 Actually the 'OnPCWakeup' message were sometimes called more times and thus code for re-enabling dummy Eureka freeze window was called more times and could be cause of the subsequent issues. This would correspond to the Rusty's tests that the issue does not occur with regular builds (without Eureka). So Rusty please re-test in 2523 |
|
|
Verified 2523 Unable to replicate, and based on logs "OnPCWakeup" is not called multiple times. No regressions in non debug build |
|
|
This issue is still occurring in build 2523, so I suppose it's independent of 0018584. |
|
|
Looks like fixed alongside 0018609 |
|
|
Verified 2608 by user, |
|
|
Not sure why this issue was tagged as fixed--it was never resolved and still occurs with current builds (2610). |
|
|
I've improved wake up detection so hopefully it will detect correctly now |
|
|
Tested 2619. The good news is that there are no regressions. i.e.: - The regular build continues to work well (no issues on resume from sleep or hibernation) - The debug build resumes from sleep properly The not-so-good news is that: - The debug build continues to experience problems occasionally on resuming from hibernation and once the problem occurs, it tends to reccur on subsequent resume from hibernation operations. Note: the problem that occurs is that after resuming from hibernation the exterior window resizes independently of the interior window, and the menu bar commands and minimize/close buttons don't work (and the user must consequently force-close MM). Considering that it doesn't occur consistently and only with the debug build, we may want to push this again. |
|
|
Isn't this just duplicate of 0019063 that has been already fixed? |
|
|
It's possible that this issue was also caused by 'modern standby', and that the fix to 0019063 also fixes resume from hibernation issues. Setting to 'fixed' for testing. |
|
|
Verified 2683 Tested during pre-release regression testing |
