View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0017655 | MMW 5 | UPnP / DLNA | public | 2021-03-11 02:07 | 2024-04-08 20:36 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | crash | Reproducibility | sometimes |
| Status | resolved | Resolution | reopened | ||
| Product Version | 5.0 | ||||
| Target Version | 5.0 | Fixed in Version | 5.0 | ||
| Summary | 0017655: Crash on close after running for awhile (crashlog ID 8F658A3F ) | ||||
| Description | I don't remember what I was doing (if anything). iirc I just ran MM and then left it, came back a couple of hours later to close it and it crashed with a black screen. Fortunately dbgview was running (although I believe that it may have been running even before the MM session in which the crash occurred so just look at the end of it). This may be related to recent UPnP changes...not sure. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2326 | ||||
|
|
There was a blocked waiting in UPnP.dll for mutex owned by thread 13292, but the thread 13292 no longer exists and based on debug log it never existed in MM5, it must have been internal thread in UPnP.dll I don't think this is a new problem, I saw similar logs from LowLander in the past and also the same problem you have already reported as 0016265 in the past. Revising C++ code in UPnP.dll for a possible defect... |
|
|
Traversed PLATINUM UPNP SDK's code and I haven't found a defect yet, but added more debug messages to see which mutex exactly it was -- I know (thanks to enhanced messaging in 0016265) that it was either PLT_SsdpListenTask::m_Lock or PLT_UPnP::m_Lock --> will see more from the future logs. |
|
|
Verified for regression in 2324 @Rusty, Can you please confirm verification and close. |
|
|
Replicated in build 2324 by running MM for 25 hours (not doing anything) and then closing it. --> black screen, crashlog, frozen (force close required). Logs and crashlogs available. |
|
|
Fixed in 2326 |
