View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011971 | MMW v4 | Other | public | 2014-03-21 20:29 | 2014-03-23 10:44 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | feedback | Resolution | open | ||
| Product Version | 4.1.1 | ||||
| Target Version | 4.1.1 | ||||
| Summary | 0011971: MediaMonkey fails to terminate (1697) | ||||
| Description | For some reason, MediaMonkey 4.1.1.1697 fails to terminate on my system. I've uploaded a log to the ftp server consisting simply of: 1 Run MMW 2 Close MMW As you can see at the end of the log, MMW never terminates! | ||||
| Additional Information | This bug doesn't occur with MMW 4.0.7 or MMW 4.1.0. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
Rusty, if MM terminates correctly (as in my case) then the last debug lines are: InstanceManager - window destroyed TBackgroundQueue: Still waiting for finishing 0 threads. TBackgroundQueue: Destroying... as we can see in your case there are InstanceManager - window destroyed TBackgroundQueue: Still waiting for finishing 0 threads. TBackgroundQueue: Destroying... In WM_DEVICECHANGE So I wonder whether the WM_DEVICECHANGE message could have an influence on this or whether it is unrelated, e.g. does this happen if you disable d_WMDM.dll ? You indicated that it is a regression in recent builds (1693 - 1697), could you find in which exact build this started? Are you always just starting/closing MM, couldn't it be instance of 0011471, anyhow watching MediaMonkey.exe in ProcessExplorer should us more (but this shouldn't be necessary on the assumption that it is really a regression as a side effect of a change between 1692 and 1697). |
|
|
Further testing showed that disabling wmdm has no effect. Moreover, the issue occurs on any copy of MediaMonkey.exe that is installed to /Program Files (x86)/MediaMonkey/ (even 4.0.7 and 4.1.0). When I tested with 4.0.7 and 4.1.0 previously, the bug didn't occur because I'd tested them in different (portable) directories. Even more strangely, when I rename MediaMonkey.exe to MediaMonkey4.exe, the bug no longer occurs?!? I believe that this has something to do with the tests that I carried out last week using a custom MediaMonkey.exe, and the fact that I told windows SmartScreen to allow the program to run despite the fact that it wasn't recognized. In case this is something that should be fixed, I've also attached a dump and stack from MediaMonkey.exe generated via Process Explorer once MM had failed to terminate (posted to ftp). Please delete it if it's of no use--it's rather large. |
|
|
From the MediaMonkey.exe!ExceptionManager+0x73f38c_thread_details (Process Explorer) I see that there was an exception, but that's all. I know that you indicated that MM service was unistalled, but could you ensure that it is really properly uninstalled? If you go to services, is MediaMonkeyService really missing? I don't know what else could have an impact on this espacially if you indicated that it appears only if the filepath to MediaMonkey.exe is /Program Files (x86)/MediaMonkey/MediaMonkey.exe |
