View Issue Details

IDProjectCategoryView StatusLast Update
0018283MediaMonkey 5Generalpublic2022-05-25 12:02
Reporterrusty Assigned To 
PriorityurgentSeveritycrashReproducibilitysometimes
Status resolvedResolutionfixed 
Product Version5.0.2 
Target Version5.0.4Fixed in Version5.0.3 
Summary0018283: Crash or Black screen on resume from sleep/hibernation (5.0.2 logi ID 4AD4000)
Description1 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 InformationTicket 3622
TagsNo tags attached.
Fixed in build2619

Relationships

duplicate of 0019063 feedbackrusty Crash when resuming from sleep on systems using 'Modern standby' 
related to 0018447 closedpetr Changing display causes Minimize/Maximize/Close buttons to stop working 
related to 0017072 assignedpetr Micro Player: stops responding & other issues 
related to 0018584 closedLudek Task queue deadlock detected - crashlog 0AF10000 
related to 0019008 closedmichal Wake from sleep 2x causes Taskbar to "progress" indefinitely and Playback to start by itself 
has duplicate 0018343 closedpetr Scrolling in Tracklist --> crash AB1A000 
related to 0017835 assignedpetr Dialogs sometimes fail to render (appear black) 
related to 0018847 closedpetr Update Chromium to v98 
related to 0018609 closedLudek Some users can't run MM5 (until HW accelaration is disabled) 

Activities

petr

2021-09-14 19:28

developer   ~0064620

Debug log didn't help to show root of the issue so i've added some debug.

rusty

2021-10-14 15:10

administrator   ~0065200

I haven't been able to replicate this in 2508. Resolving.

rusty

2021-11-02 01:44

administrator   ~0065629

Last edited: 2021-11-02 01:46

View 2 revisions

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).

petr

2021-11-03 12:06

developer   ~0065673

I've added some switches based on recomendations on the internet, so please retest in next build.

rusty

2021-11-03 21:21

administrator   ~0065689

Verified 2514. I'll retest again to make certain, but looks good!

rusty

2021-11-04 00:42

administrator   ~0065697

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)!

rusty

2021-11-04 18:38

administrator   ~0065721

Unable to replicate with the latest test build provided by Petr.

petr

2021-11-04 19:13

developer   ~0065722

Fixed

rusty

2021-11-05 04:30

administrator   ~0065749

Last edited: 2021-11-05 04:36

View 2 revisions

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.

petr

2021-11-05 13:31

developer   ~0065750

Last edited: 2021-11-05 13:32

View 2 revisions

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

rusty

2021-11-15 17:12

administrator   ~0065939

Last edited: 2021-11-15 17:14

View 3 revisions

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)

rusty

2021-11-16 21:30

administrator   ~0065957

Last edited: 2021-11-16 22:26

View 5 revisions

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.

Ludek

2021-11-24 17:31

developer   ~0066086

Last edited: 2021-11-24 17:36

View 5 revisions

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

peke

2021-11-25 00:54

developer   ~0066116

Verified 2523

Unable to replicate, and based on logs "OnPCWakeup" is not called multiple times.

No regressions in non debug build

rusty

2021-11-25 01:42

administrator   ~0066118

This issue is still occurring in build 2523, so I suppose it's independent of 0018584.

peke

2022-02-19 12:04

developer   ~0067039

Looks like fixed alongside 0018609

peke

2022-02-19 12:05

developer   ~0067040

Verified 2608 by user,

rusty

2022-03-14 14:04

administrator   ~0067285

Not sure why this issue was tagged as fixed--it was never resolved and still occurs with current builds (2610).

petr

2022-04-29 08:53

developer   ~0067864

I've improved wake up detection so hopefully it will detect correctly now

rusty

2022-04-29 22:50

administrator   ~0067887

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.

Ludek

2022-05-25 11:49

developer   ~0068229

Isn't this just duplicate of 0019063 that has been already fixed?

rusty

2022-05-25 12:02

administrator   ~0068230

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.