Compartilhar via

.NET Framework 2.0 setup bug related to registry permissions and regtlibv12.exe is now fixed

  • Artigo

A little while ago I wrote a post explaining how to report a bug in the .NET Framework and Visual Studio setup. I tried to encourage everyone who read that post to report bugs they find instead of giving up on installing VS 2005, reformatting their hard drive, or something like that. I wanted to share a concrete example of what can happen when you do report a bug.

A little while after .NET Framework 2.0 beta 2 and VS 2005 beta 2 shipped, I heard from a couple of customers who could not get the .NET Framework 2.0 beta to install correctly. It repeatedly failed and rolled back while trying to register type libraries. I had not heard of anyone running into an issue like this in .NET 1.0 or 1.1 or in any of the previous beta builds of .NET 2.0. In addition, none of the teams working on VS 2005 and .NET 2.0 had seen this problem during daily testing, official test passes, etc.

I worked closely with one of the customers and we narrowed down the problem to missing registry permissions. The typelib registration is done by a custom action inside of .NET Framework setup, and the custom actions were marked with a flag that caused Windows Installer to "impersonate" the logged in user and run the action with the same permission as the user who is running setup. In nearly all cases, that works fine because .NET Framework setup requires that the user be an administrator in order for setup to launch and run correctly. However, on this customer's machine the Administrators group did not have permissions to the HKEY_CLASSES_ROOT hive that is needed to register type libraries.

This investigation gave us a cause for the setup failure, but not any ideas about how the machine got into that state so that we could try to come up with a solution. One other customer who reported this same bug on the Customer Feedback website provided us a workaround (described here), but the steps were pretty involved. After some brainstorming with the .NET Framework setup team and the Windows Installer team, we decided to try marking these type library registration custom actions to not impersonate anymore. This would cause Windows Installer to run the actions in system context. We created a hand-modified version of the .NET Framework setup and asked the customer to try it for us. This version succeeded where all other .NET 2.0 setup packages had failed on his machine.

Now we had a cause and a solution, but we still had not seen anyone inside of Microsoft reproduce this problem, and the teams were steadily nearing the time to lock down the .NET Framework 2.0 to prepare for shipping. So we needed more data to justify fixing this bug. This is where the Customer Feedback site and Watson reports (the dialog boxes that appear after an error or crash and ask if you would like to send the information back to Microsoft) came in. We were able to look at data from bugs reported by customers on the Customer Feedback site to determine that this particular .NET setup problem was not an isolated incident. Then, we were able to look at data reported back to Microsoft when customers received errors during .NET 2.0 setup and chose to send the report back to Microsoft. As Quan (a program manager on the VS and .NET setup team) described here, this issue turned out to be the #2 cause of setup failures for .NET 2.0 during beta 1 and beta 2.

Now we had a cause, a solution, and data to support the case that this issue would lead to customer support calls if we decided not to fix it. There were a couple final things to do to prepare this bug for the VS shiproom process. The .NET setup team created a buddy build of the proposed fix and had to get test signoff. Since the bug had not ever been reproduced inside of Microsoft, Quan and I each contacted a customer who had run into this issue in the .NET 2.0 beta program and they validated that the fix worked. The .NET setup took this bug to shiproom and presented the problem, the solution, the Customer Feedback site and Watson data and the customer sign-off, and the bug was approved to be checked in.

I'm very happy to say that this fix will be in the final release of .NET Framework 2.0. This bug was never reproduced inside of Microsoft and would not have been fixed if it were not for customers who participated in the VS 2005 and .NET Framework 2.0 beta program. The bug reports on the product feedback site and comments posted on my blog gave us valuable direct contact to customers who saw this problem first-hand so we could gather more data. And each of the customers who saw this problem and chose to send the problem report back to Microsoft in essence provided "me too" votes to show us how frequent this bug would be if it were not fixed. I want to say a big thank you to each customer who made this possible, and in particular to Michael. Your detailed data and infinite patience made it possible for us to get to the bottom of this issue.

If anyone reading this is running into this setup bug, you can find a hand-fixed version of .NET Framework 2.0 beta 2 here. If you are running into this with some other build of the .NET Framework 2.0, please contact me and I can provide you an updated version that will work correctly for you.

Comments

  • Anonymous
    August 29, 2005
    Yesterday, I posted a description of a registry permission bug that was preventing the .NET Framework...
  • Anonymous
    August 29, 2005
    Yesterday, I posted a description of a registry permission bug that was preventing the .NET Framework...
  • Anonymous
    September 27, 2005
    tsk, no luck. i had the same error as described, but the hand patched fix yielded:

    Error 1920.Service '.NET Runtime Optimization Service v2.0.50215_X86' (clr_optimization_v2.0.50215_32) failed to start. Verify that you have sufficient privileges to start system services.

    manually starting said service yielded "this service started and immediately stopped"
  • Anonymous
    September 27, 2005
    Hi Mousse - this .NET Runtime Optimization Service error is a separate bug that existed in .NET Framework 2.0 beta 2 that has subsequently been fixed.

    You can resolve this by running sc delete ".NET Runtime Optimization Service v2.0.50215_X86" from a cmd prompt. After this completes, you should be able to install the .NET Framework 2.0 beta 2 and avoid this error.

    Please contact me using http://blogs.msdn.com/astebner/contact.aspx if this doesn't work and I can try to dig into this further....
  • Anonymous
    September 28, 2005
    i'm not concerned. especially now that i see a newer release is just out. i've already tried another site's suggestion of my computer->manage->services->uninstall .net2.0
    that much let the original dvd install (not your patch). it's still not correct though: no vb template projects show.
  • Anonymous
    September 30, 2005
    Hi Mousse - what is the exact version of VS and the .NET Framework that you are using (is it beta 2, or a CTP, or the PDC build, etc)? Also, I assume you mean that there are no VB template project types listed inside of Visual Studio 2005, is this correct?

  • Anonymous
    October 03, 2005

    Microsoft Visual Studio 2005
    Version 8.0.50727.24 (RTM.050727-2400)
    Microsoft .NET Framework
    Version 2.0.50215

    and you're correct about the templates.
  • Anonymous
    October 03, 2005
    Hi Mousse - the configuration you list will not work correctly. You have the RC build of Visual Studio 2005 but the beta 2 build of the .NET Framework 2.0. The versions of VS and the .NET Framework need to match for everything to work as expected.

    I think you might want to try to uninstall the .NET Framework 2.0 beta 2 and install the RC version that should be in the wcudotnetframework folder on your VS 2005 RC DVD. Then you can try to repair VS 2005 and see if that will resolve this VB Template project issue.

  • Anonymous
    October 10, 2005
    exactly, "wipe it all and redo with the latest release" was my angle from the start ^_-

    your bugfixing exuberance is refreshing tho =)
  • Anonymous
    November 18, 2005
    I had the same error 1920. I fixed by going to Services under Administrative tools.

    Do not try and start the service it is complaining about you will get the error mousse mentions. Instead start the OTHER .NET service right below it... mine is ".NET Runtime Optimization Service v2.0.50727_X86". Then return to the install for .NET and hit retry. Works now for me.

    Good luck!

    Cheers,
    Brandon Franzke
  • Anonymous
    November 21, 2005
    Hey,

    I have Visual C# Express Edition 2005 on my machine and it is running fine. However when I downloaded the WinFX SDK and then clicked on XAMLPad an excpetion occurs as System.IO.FileNotFoundException has in XAMLPad.exe while on running ILDASM I get the following error that it will run with .NET Version 2.0.50215. I checked all the System and User paths and I have Version 2.0 installed, so what might be the problem ?
    All the lib and bin paths are also fine.
  • Anonymous
    November 21, 2005
    Hey,

    I have Visual C# Express Edition 2005 on my machine and it is running fine. However when I downloaded the WinFX SDK and then clicked on XAMLPad an excpetion occurs as System.IO.FileNotFoundException has in XAMLPad.exe while on running ILDASM I get the following error that it will run with .NET Version 2.0.50215. I checked all the System and User paths and I have Version 2.0 installed, so what might be the problem ?
    All the lib and bin paths are also fine.
  • Anonymous
    January 12, 2006
    Thanks for the fix. Wasn't ready to dive into overcoming this issue!
  • Anonymous
    March 29, 2006
    I stumbled across a post on the Internet Explorer team's blog from last Friday that I wanted to post...
  • Anonymous
    May 17, 2006
    The link is broken, this seemed like the fix i was looking for but unfortunatly it's down now :( thanks anyway.
  • Anonymous
    May 17, 2006
    Hi Mike - This bug only applied to the .NET Framework 2.0 beta 2.  I removed the package linked to above because the final version of the .NET Framework 2.0 has shipped, and that version has the fix for this issue.  I would suggest downloading and installing the final release of the .NET Framework 2.0 from http://msdn.microsoft.com/netframework/downloads/updates/default.aspx to see if that resolves the problems you have run into.
  • Anonymous
    April 28, 2007
    Visual Studio codename Orcas beta 1 was recently released, and now a standalone version of the .NET Framework