View Issue Details

IDProjectCategoryView StatusLast Update
0000388MMW 5Install/Configpublic2020-11-14 14:52
Reporterrusty Assigned To 
PriorityurgentSeverityminorReproducibilityalways
Status closedResolutionduplicate 
Fixed in Version5.0 
Summary0000388: MMHelper.dll sometimes prevents uninstallation/installation (regression in MM5)
DescriptionThis 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.
TagsNo tags attached.
Fixed in build2270

Relationships

duplicate of 0007838 closedpeke MMW v4 MMHelper.dll is Locked during installation 
related to 0002430 closedLudek MMW v4 Handling Multimedia Keyboard APPCOMMAND_MEDIA Keys sometimes misses 
related to 0011868 closedLudek MMW v4 Error Code 5 on upgrade 
related to 0017067 closedpetr MMW 5 MM fails to re-install when closed to tray (regression) 

Activities

rusty

2007-07-27 17:47

administrator   ~0009943

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?

jiri

2007-07-27 19:29

administrator   ~0009950

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.

Owyn

2008-12-15 02:57

reporter   ~0015648

Problem showing up again.
http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=29632

jiri

2008-12-15 16:52

administrator   ~0015656

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

rusty

2009-10-29 16:49

administrator   ~0019399

Last edited: 2009-10-29 16:50

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.

Owyn

2009-10-29 16:57

reporter   ~0019400

Heck. I have got in the habit of just clicking Ignore. The dll has not changed in a dog's age.

jiri

2009-11-02 16:53

administrator   ~0019488

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

Ludek

2009-11-12 12:53

developer   ~0019693

Last edited: 2009-11-12 13:14

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

jiri

2009-11-12 15:23

administrator   ~0019694

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.

Ludek

2009-11-12 18:31

developer   ~0019698

Last edited: 2009-11-12 18:45

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.

jiri

2010-06-02 14:12

administrator   ~0020211

Merged to build 1295.

stephen_platt

2010-06-03 02:07

developer   ~0020229

verified 1295

Ludek

2020-10-12 20:24

developer   ~0059834

Last edited: 2020-10-12 20:28

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.

Ludek

2020-10-12 20:55

developer   ~0059835

Last edited: 2020-10-12 21:10

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

peke

2020-10-16 22:30

developer   ~0059885

Verified 2270

not encountered error and no regressions found during testing.

peke

2020-11-13 23:31

developer   ~0060191

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.

Ludek

2020-11-14 14:08

developer   ~0060211

Last edited: 2020-11-14 14:09

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

peke

2020-11-14 14:52

developer   ~0060225

Great, thx for clarifying then it is Verified 2274

Closing as it will not happen after 2274 upgrade.