Why can’t I uninstall my assembly?

When installing an assembly to the GAC, Fusion provides a mechanism for the installer to specify a traced reference count on the assembly being installed. The idea is that if the same assembly is installed multiple times by different clients, the assembly is not removed until all of the clients that installed the assembly have explicitly requested uninstall. Without such a feature, you could run into scenarios where assemblies are prematurely uninstalled. For example: two applications install the same shared assembly to the GAC; one application is uninstalled, and the shared assembly is removed even though another app still needs it.

The reference counts Fusion provides are called “traced” reference counts, because unlike COM reference counts, which simply record the number of outstanding clients, an installer is allowed to specify information identifying who needs the particular assembly. There are different kinds of traced reference counts that an installer can provide, such as a filepath, or an opaque string that is installer-specified. Gacutil allows you to specify traced reference counts in an install command-line via the /r option.

You can read more about traced reference counts in this gacutil MSDN document. There is also information about traced reference count in our support article describing the unmanaged Fusion API.

When you install your assembly using MSI (which is the recommended approach for retail installs), there is no need to specify a traced reference count for your assembly, because MSI has its own internal reference counting mechanism. When Fusion is asked to uninstall an assembly from the GAC, it will check if there are any outstanding traced reference counts. If there aren’t any traced reference counts, Fusion will call a Windows Installer API to determine whether or not MSI holds a reference on the assembly. If any reference count (traced reference count, or MSI reference count) exists, the assembly will not be uninstalled.

If you try to uninstall an assembly in the GAC using “gacutil -u”, you may see a message indicating that some traced reference count remains on the assembly, and gacutil will output the information about the pending traced reference count. In order to uninstall it, you must remove all the traced reference counts. For MSI-installed assemblies, this is only possible by uninstalling the MSI package that installed the assembly via Add/Remove programs.

Some customers have reported unusual cases where an assembly installed into the GAC via gacutil without a traced reference count, can later not be uninstalled via “gacutil -u“. When the uninstall is attempted, the following message appears:

Unable to uninstall: assembly is required by one or more applications Pending references:


This message is informing the user that Fusion thinks that Windows Installer holds a reference count on the assembly, yet this information is clearly wrong because the assembly was never installed via MSI.

If you encounter this problem, it is very likely that you have run into an odd MSI registry corruption (at the time of this writing, the cause is unknown). Without getting into a long-winded explanation of how this registry corruption eventually results in the error message above, the common cause of this is a bogus default value set under one (or both) of the below registry keys:



If these keys are not empty (e.g. they contain a MSI descriptor value), then you have hit this situation, and you should be able to fix the problem by clearing the default value. I can’t guarantee that this will always work, but it has definitely been our experience that this is the most common source of this problem.

(This tip comes courtesy of our resident MSI expert on the Fusion team, Roberto Sciore).

Comments (45)

  1. Alan — thank you for this tip. I recently came across this problem myself and found the same solution, but I wasn’t sure if it was a "kosher" operation. Thank you for verifying my suspicions from a Fusion team member.

  2. Frans Bouma says:

    Isn’t it so that MSI is NOT the right choice for this because of this odd bug? IMHO when using MSI (it’s easy to use, so why not use it) and you want to install to the GAC: shell out and run gacutil.exe to install the assembly. Requires more work, but you can be sure it will uninstall.

  3. Actually, the cause is not so unknown at all! One of our coworkers discovered this problem was consistently triggered by the MSN Messenger 6.0 installation!

  4. Rick Watson says:

    We’ve reproduced the MSN Messenger behavior here at our company.

    I’ve uninstalled that and installed Trillian instead [which can access MSN Messenger contacts]

  5. Alan Shi says:

    Thanks for all the comments. I’ll take the information you’ve provided about MSN Messenger 6.0 creating the corrupt MSI registry problem to the Windows Installer team so we can investigate further.

    Frans, MSI is definitely the recommended way to install your assemblies (particularly in retail environments). The bug being described is a little orthogonal to choosing MSI as an installer; even if you shell out to gacutil.exe to install, doesn’t guarantee the ability to uninstall (because the bug affects all uninstalls).

    I’ll be sure to let you all know when we get more information on this issue.

  6. Jason Aubrey says:

    I have this same problem but both keys contain no values…

  7. Jason Aubrey says:

    It seems that (in Win2KPro) executing the following froma commandline does the trick: rd /s <Assembly Name>

  8. Jason Aubrey says:

    Maybe I should clarify… the "rd /s <Assembly Name>" should be executed from C:WINNTassemblyGAC

  9. george says:

    I would appear to have the same problem but when I check the registry keys mentioned they are empty. I then attempted to manually delete the keys from a dos box I am unable to delete the directory. When I delve down into the directory I finally get to the actual DLL that has been installed, and it would appear that this file is locked in some way. Any thoughts??

  10. george says:


    After a restart and deleting each file manually I was able to remove the files.

  11. Amit Ugane says:

    Thanks It Works Really Good Solution

  12. Amit Ugane says:


  13. Alan – Thanks for this – I had this problem, and your advice was very helpful.

  14. Martin LL says:

    My registry keys where empty, so i have to delete the files manualy… in case someone is wondering which files… i deleted all files in c:[Windows dir]assemblygac[assembly name].

    To delete all this i have to use DOS…

    Thanxs Alan.

  15. Kevin Keenoy says:

    I have been having the same problem and have not been able to fix it with the methods above. Firstly, can I check that I’ve tried the right thing: the [HKCUSoftwareMicrosoftInstallerAssembliesGlobal] key does not exist on my machine (there is no "Installer" in the HKCUSoftwareMicrosoft… part of the registry); the [HKLMSOFTWAREClassesInstallerAssembliesGlobal] does, and has a whole bunch of stuff that appears to be the contents of the GAC. I assume that I shouldn’t delete all of these values (?), but at the top of the list is the key:

    <no name> : REG_MULTI_SZ : …

    This had a value in it, which I have now deleted in accordance with the advice here. Is that right? Or does "clear the default value" mean I should delete the key altogether (and not just the value there)? Sorry if this is a stupid question, but I’m new to fiddling with the registry…

    Secondly, deleting the files manually doesn’t seem to be a good solution – for some reason I need to reboot before I can re-install the assembly (I’m currently developing an assembly so need to uninstall and then reinstall a newer version quite often), and then the same problem occurs again next time so I again have to manually delete, re-boot and re-install each time I want to test a new version of my assembly. Does uninstalling MSN Messenger fix the problem permanently?

    Thanks in advance for any advice you can give!

  16. Alan Shi says:

    Kevin, the very first entry under that registry key is what you want to delete. If you’re using regedit, it should have a name of "(Default)" and the value should have no value (regedit displays this as "(value not set)".

    Deleting files manually from the GAC is definitely not recommended.

  17. Kevin Keenoy says:

    Great – many thanks for your advice, Alan. Deleting the entire entry (not just the value) seems to have worked a treat.

  18. Phil Bishop says:

    DUDE i’m not worthy..thank you so much for solving my problem also…

  19. Vlad says:

    Thx! "Global" key had a default value of REG_MULTI_SZ set to smth like "{Ja9`qF7V@7x@e9P@…". I just uninstalled MSN 6.1. Now its type is REG_SZ, it’s empty and gacutil.exe works fine.

  20. Mario Hernández says:

    Alan!! You have no idea how much I owe you with this tip!!!! Thank youy very much!!!. People, you have to DELETE the key, not just clear the value, ok??

  21. Celia says:

    Alan, I know you heard many "Thanks" already. But this is the exact problem I have and your article solved it in 30 seconds. Thank you!!

  22. GB says:

    One more to add to the "Thanks List" 🙂

  23. Josephina says:

    Alan, you the man! thanks Mario – i cleared first then deleted thank to you.

  24. Mario Hernández says:

    Hi Alan, … and MSN Messenger Development Team don’t fix this problem yet at version 6.2. :S

  25. danielle says:

    i want my msn unstalled please!!!

  26. danielle says:

    i want my msn unstalled please!!!

  27. Hiren Joshi says:

    You can go to c:winntassemblyGAC and remove your folder your_dll without_extension with rmdir folder name /s/q to get rid of the problem.

  28. Poli!!!!! says:


    It really worked!!!!!!!

  29. Alan Shi says:

    Addressing Hiren’s comment, I’ll repeat my recommendation again: simply deleting the directory by hand is not the right solution.

    For everyone interested, we’ve tracked down this problem to any MSI that installs native winsxs assemblies using the built-in MSI support. This ends up causing a corruption on pre-XP systems. There will be a fix in MSI3.0, and we’re also looking at whether a MSI2.0 patch for this is feasible.

  30. beesman says:

    My God, Thank you for your help,

    Comrade Jason Aubrey

  31. Paul says:

    "Addressing Hiren’s comment, I’ll repeat my recommendation again: simply deleting the directory by hand is not the right solution."

    Why not? It seems to achieve the desired effect with the least amount of effort.

  32. Alan Shi says:

    Do you uninstall programs by just deleting the files under program files? Sure, it might look like that works, but it almost certainly doesn’t do what you really want.

    There is state that the system can maintain associated with the contents of the GAC. Going through an API ensures the necessary state is consistent with the contents of the store.

    The obvious example of problems today is traced reference counts being leaked. In future versions, the state of the store is used to determine coherency information with native images. Policy and other state will also be tracked in a similar way.

  33. Jasper... says:

    So deleting the directory is not "right"? What problems could this cause?

  34. B Z says:

    Thank you very much. This has been bothering me for a while and has been frustrating. I did what Alan suggested and it works!!!!!!!!!!

  35. Saurabh Kumar says:

    I do not see the path –


    on my NT 2000 machine.

    Where should i search for AssembliesGlobal ? to remove the Assembly reference.

  36. Marc Loy says:

    You safe my night.

    Just delete the (default) key.