View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000388 | MMW 5 | Install/Config | public | 2003-05-14 12:49 | 2020-11-14 14:52 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | duplicate | ||
| Fixed in Version | 5.0 | ||||
| Summary | 0000388: MMHelper.dll sometimes prevents uninstallation/installation (regression in MM5) | ||||
| Description | This is an occasionally reported problem that occurs when upgrade notifications are sent out: When MM is running and playback occurs, and then MM is closed, MMHelper.dll often remains locked for up to 10 minutes this means that: a) if the user attempts to uninstall MM, the uninstallation is incomplete (error: 'some files could not be deleted') b) if the user attempts to install a new version of MM, the installation cannot complete because the file is locked. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2270 | ||||
| duplicate of | 0007838 | closed | peke | MMW v4 | MMHelper.dll is Locked during installation |
| related to | 0002430 | closed | Ludek | MMW v4 | Handling Multimedia Keyboard APPCOMMAND_MEDIA Keys sometimes misses |
| related to | 0011868 | closed | Ludek | MMW v4 | Error Code 5 on upgrade |
| related to | 0017067 | closed | petr | MMW 5 | MM fails to re-install when closed to tray (regression) |
|
|
I've noticed recently that the reason this dll doesn't delete is often that it is locked by _other_ applications! i.e. on my system, if I stop editpad and thunderbird, then the file gets unlocked and I'm able to delete it. Any particular reason why this would be the case? |
|
|
This is how it works, i.e. it can happen that any running application has the dll linked. Windows manages it this way and we can't do anything about it. |
|
|
Problem showing up again. http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=29632 |
|
|
This is necessary in order to properly receive Multimedia specific keys from keyboards (like Play/Pause key) when MM isn't the foreground application. The only way how to prevent this is to disable capturing such keys (which isn't a good fix for most users). |
|
|
I've found that all I have to do is find out which .exes are locking MMHelper.dll (I use http://www.diamondcs.com.au/freeutilities/fileunlocker.php ), bring the applications in question into focus, and then MMHelper.dll is let go. As discussed, perhaps we can do this automatically during the uninstallation/installation processes. |
|
|
Heck. I have got in the habit of just clicking Ignore. The dll has not changed in a dog's age. |
|
|
Ludek, please check out, whether the fix is really possible the way Rusty suggested on other machines. If so, we probably could create a small dll that would be called from the uninstaller and would do these steps (i.e. enumerate applications that have MMHelper.dll locked, focus them and the continue uninstallation). |
|
|
I can't seem to repro. However I don't like this heck thus I am trying to find a real reason for this and fix it properly. I wondered why this is still happening despite the fact we removed Low level keyboard hooks in 0002430, but then I remember that we added shell hook for receiving APPCOMMAND messages and it seems to be the reason. I think that the real reason is that function UnhookWindowsHookEx() fails for some reason, because it should be the function responsible to unhook the DLL from all other apps. It seems that solution could be here: http://www.experts-exchange.com/Programming/Languages/C/Q_22874323.html Specifically this text: "I noticed that occasionally the DLL wouldn't unload immediately from various random processes upon calling UnhookWindowsHookEx(). The solution was to broadcast a WM_* message [PostMessage(HWND_BROADCAST, WM_NULL, 0, 0)] which caused the straggling processes to unload the DLL from memory, letting me replace the DLL on disk." |
|
|
As for reproducing - I think that the dll has at least Shell hook enabled all the time? Or at least something when in the Party mode? As for the solution - the fact that it remains in memory itself isn't a bug, it's how these hooks work in Windows. The Broadcast solution sounds interesting, I guess we can't lose anything be trying it - probably as one of the last tasks MM does before termination. |
|
|
Fixed by using the broadcast solution in build 1301 (SVN revision 8629) Verified by the File Unlocker utility that it works, MMHelper.dll is now unhooked from all apps immediately after closing. |
|
|
Merged to build 1295. |
|
|
verified 1295 |
|
|
Re-opened, this bug does occur again with MM5: https://www.mediamonkey.com/forum/viewtopic.php?p=472342#p472342 LockHunter shown that MM Helper.dll is not locked by any application and clicking [Retry] proceeds normally with the install -- so it rather sounds like a timing issue. |
|
|
This is actually a regression intruduced in SVN revision 32290 by Petr's fix of 0013916 Namely commenting out these lines in MediaMonkey-Main.iss: //pars := '/IM "mediamonkey.exe"'; // just sends WM_CLOSE message to MM in order to properly terminate it //CloseMM( false); So MM5 installer just force kills the MM5 processes instead of calling WM_CLOSE message at first to properly close MM5 (like MM4 does) => Fixed in 2270 |
|
|
Verified 2270 not encountered error and no regressions found during testing. |
|
|
Reopen I manage to trigger it twice when upgrading 2273 -> 2274 and not when upgrading 2269 -> 2270 or reinstall 2274 -> 2274 "MMHelper.dll" get locked for about 1m and can't be deleted and an easy fix is to do quick rename to "!MMHelper.dll" and press retry on installations. MM 2273 are settings Always show tray Icon, Close to tray and Minimize to tray and MM5 was closed to tray. |
|
|
Yes, this has been already fixed as 0017067 i.e. when 2270 - 2273 are closed to tray then they don't get the close event properly to broadcast the message described in 0000388:0019693 for unloading MMHelper.dll i.e. already fixed as 0017067 in 2274 |
|
|
Great, thx for clarifying then it is Verified 2274 Closing as it will not happen after 2274 upgrade. |
