Uninstalling the 64-bit .NET Framework 2.0 can break the .NET Framework 1.1

Back when the .NET Framework 1.1 originally shipped, only a 32-bit version was released.  In addition, the MSI contains a launch condition that specifically blocks the .NET Framework 1.1 from being allowed to install on 64-bit operating systems.

Since then, 64-bit systems have become much more mainstream, and some folks on the Windows team worked with some folks on the .NET Framework team to add a shim to newer 64-bit operating systems that allows users to bypass that launch condition and install the .NET Framework 1.1.

However, since the .NET Framework 1.1 was not originally designed to install on 64-bit operating systems and co-exist with newer versions of the .NET Framework (such as 2.0) that are designed for 64-bit operating systems, some .NET Framework side-by-side uninstall scenarios ended up not working exactly correctly.

In particular, the following scenario has proven problematic on a 64-bit operating system:

  1. Install the .NET Framework 1.1
  2. Install the .NET Framework 2.0
  3. Uninstall the .NET Framework 2.0

When uninstalling the .NET Framework 2.0 in this type of scenario, some registry entries will be removed out from under the .NET Framework 1.1 and cause it to not function correctly.  You must repair the .NET Framework 1.1 after uninstalling the .NET Framework 2.0 in order to restore the necessary registry values.

There are instructions for repairing the .NET Framework 1.1 in the file %windir%\Microsoft.NET\Framework\v1.1.4322\1033\repairRedist.htm on a system that has the .NET Framework 1.1 installed.  To summarize those instructions, you will need to do the following:

  1. Re-download the .NET Framework 1.1 setup package (dotnetfx.exe)
  2. Click on the Start menu, choose Run, type cmd and click OK
  3. Run this command:  <full path to dotnetfx.exe> /t:%temp% /c:"msiexec.exe /fvecms %temp%\netfx.msi"
Comments (9)
  1. JasonG says:

    I believe this "shim" needs to be documented because even running the repair commands as above results in the dreaded "This setup is not supported on 64-bit versions of Windows XP"

    Also, in many cases, the 1.1 dir will be empty after people follow instructions to completely uninstall a broken .NET with your tool.

    Can I successfully work around this issue by repackaging the msi after clearing the LaunchCondition table?

  2. Hi JasonG – The shim should clear that launch condition from the 1.1 setup in all cases.  I’m surprised to hear that you were able to install 1.1 originally on this system but that attempting to repair would lead to that error message.

    If the .NET Framework 1.1 directory is empty, you can download and run .NET Framework 1.1 setup from the original source location instead of using the steps in repairRedist.htm.

    It is possible for you to manually update the MSI by removing the entry from the LaunchCondition table to workaround this, but I don’t recommend modifying shipped MSIs in general because it could inadvertantly lead to problems in the future (such as the inability to apply future hotfixes and service packs in the worst case).  It would be best to try to narrow down why the shim isn’t being triggered correctly.  It is possible that you have an older version of 64-bit Windows that didn’t yet contain the shim.  If that is the case, then the .NET Framework 1.1 isn’t going to be officially supported on that system.

    Heath Stewart wrote a tool that lets you examine OS shim settings in more detail that might be helpful in this scenario.  You can take a look at the information at http://blogs.msdn.com/heaths/archive/2007/11/06/appcompat-in-windows-installer.aspx for more details about this tool.

  3. JasonG says:

    That was very interesting reading on how application compatibility works and now I discovered that the shim is indeed there, but is somehow inaccessible.  I see this in the msi setup log:

    MSI (s) (E4:EC) [08:51:57:197]: APPCOMPAT: unable to initialize database.

    Where (I’m guessing) I should be seeing something similar to:

    MSI (s) (10:B0) [13:33:43:361]: APPCOMPAT: looking for appcompat database entry with ProductCode ‘{00000000-0000-0000-0000-000000000000}’.

    I manually exported the shim (netfx64.mst) using Heath’s tool.  By applying this transform it indeed allows the setup to continue and I can accept the license agreement.  It is interesting that the shim is actually not a more advanced dll/SysCall hooking type but just a plain old transform to do exactly what I proposed to the original MSI (removing the row from LaunchConditions).  Anyway…

    A few more problems cropped up:

    v1.1 registry entries were missing which I fixed via (changing InstallRoot to Framework64): http://blogs.msdn.com/astebner/archive/2007/06/12/3260076.aspx

    The 32-bit mscoree.dll was also missing (discovered via Process Monitor) in SysWOW64.  I recovered the file from a fully up to date 32-bit Win2k3 box and I was *almost* finished!

    Finally, I was bitten by DEP and had to follow steps to temporarily disable it as you listed here:


    It’s been a long road but I appreciate your patience in describing at length these various problems.

    I will have to watch very closely the next time I install a 64-bit machine and try to determine when AppCompat DB is getting broken and etc…

  4. Hi JasonG – I’m glad you were able to work this out with Heath’s tool and some in-depth investigation.  I haven’t seen any cases like this where the app-compat database was not accessible during installation.  There might be some underlying issue on your OS that is preventing all shims from being applied.

    In this case, the product being shimmed is an MSI, so the underlying hook needs to be at the MSI level as opposed to at the DLL level (because we only want the shim to apply for a specific MSI product code and not globally to any code that calls into a given DLL for example).

  5. megawatt says:

    Hi Aaron!

    Meg A. Watt here again! I am having some customers write in that are having difficulties getting the .NET Framework 1.1 installed on their Vista 64-bit systems. They are presented with a screen that says there is a known compatibility issues with this program but they still have the option to run the program. Do you know of any known compatibility issues on this? Our program {uicken Medical Expense Manager) requires that it be installed. Any guidance on what I can tell my customers would be greatly appreciated. You are a legend here at Intuit in the Support realm, by the way!

    Thanks for your help,

    Meg A. Watt


  6. Hi Megawatt – There is an OS application compatibility warning that appears when attempting to install the .NET Framework 1.1 on Windows Vista x64, but in my past experience, if you dismiss that dialog and continue with install, it will complete correctly and the .NET Framework 1.1 will wor as expected on this OS after setup completes.

    The main reason this dialog appears is that the .NET Framework 1.1 shipped long before Vista shipped, and it used to block installation on all 64-bit OS’s.  That block was removed by adding an OS application compatibility shim, and since that shim was opening up install paths that weren’t originally supported, they decided to display the compatibility warning dialog as well.

    The one issue I know of related to the .NET Framework 1.1 on 64-bit OS’s is an uninstall issue.  It is described at http://blogs.msdn.com/astebner/archive/2007/09/13/4904120.aspx.  That issue occurs when uninstalling the .NET Framework 2.0 on a 64-bit OS though, and since you mentioned you’re using Vista 64-bit, that issue won’t affect you.  The .NET Framework 2.0 is an OS component on Windows Vista and cannot be uninstalled.

    If you do run into any issues with the .NET Framework 1.1 on 64-bit versions of Windows Vista, please post another comment and let me know.

Comments are closed.

Skip to main content