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

  • Article

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.