Thoughts from the EPS Windows Server Performance Team
Useful Microsoft Blogs
Here on the Performance team we support the functionality of the Windows Installer engine and the installation and uninstallation of .msi packages. We are also often engaged to help with issues by other teams when an installation fails to install (or uninstall). So today, we’re going to cover some basic concepts that we use when troubleshooting the Windows Installer engine as well as some useful tools.
There are two phases to every Windows Installer installation, Acquisition and Execution. If an installation is unsuccessful, then a rollback may occur. At the beginning of the acquisition phase a user instructs the installer to install a feature or component. The installer gets all of this information from the installation database (.msi). This is performed under the users context, referred to as client side. This information is used to generate a script that provides the installer with step-by-step instructions for performing the installation. We then enter the execution phase, the installer passes this information off to a process with elevated privileges and we run the script - referred to as the server side.
An equally important feature of the Windows Installer is the rollback. As I mentioned above if the installation is unsuccessful a rollback may occur. During the installation the installer keeps track of all the registry changes and files that are updated and it compiles those into a rollback script, so if the installation does fail we can put the machine back to its pre-existing configuration prior to executing this particular package. The benefit of this is that it allowed software vendors to reduce the ever growing "DLL Hell" that was a common problem with some older installation technologies.
So, let's dive right into troubleshooting a Windows Installer issue. This issue concerns a SQL 2005 SP2 installation on a Windows Server 2003 (64-bit). On this server, we'd noticed some random issues with this server in respect to the Windows Installer. When launching some applications the Installer would run and some applications wouldn’t uninstall but with this being a SQL server it didn’t become a real problem until it was time to apply the latest SQL service pack. The error that we got during the SQL Server service pack installation was pretty nondescript so we started by checking the basic functionality of the installer by attempting to uninstall an application from this server. When we tried to do this we were presented with the error message as shown.
The first thing that we want to do is check for any Windows Installer Event Logging. To learn more about Windows Installer Event Logging, check out this MSDN Article on Event Logging. In this scenario, by checking the Application Event Log we see that we are getting an Event 1015 and the error code is 0x80040154 as shown below. Here’s where knowing what tool to use to extract the right data from the event will get us pointed in the right direction.
Using a tool call Error Lookup from the Visual Studio Tools (ERRLOOKUP.EXE), we can use some of the information from the Application Event log to help us in determine what are next steps are going to be. We want to take the error code from the error message "Failed to connect to server. Error: 0x80040154" and insert that into the Error Lookup tool and click "Look Up".
NOTE: You can also use the ERR.EXE utility included with the Windows Server 2003 Resource Kit to get the same information.
So the error message that we're getting is "Class not registered." With this little bit of information we know that our first step is to re-register the Windows Installer service. In this particular scenario we need to pay attention to the fact that we are performing this installation on 64-bit version of Windows. Thus, we need to make sure to register the Windows Installer engine (msiexec.exe) that resides in the \Windows\SysWOW64\ folder as well as the 64-bit version of the Windows Installer which resides in the \Windows\System32 folder.
Once we re-register the installer, we can then enable the Windows Installer Logging policy. This can be done from the Group Policy Snap-in (gpedit.msc). From within the snap-in, Local Computer Policy --> Computer Configuration --> Administrative Templates --> Windows Components --> Windows Installer --> Logging and add the values “voicewarmup” (without the quotes). You can also add the logging policy by editing the registry directly per the instructions in KB 314852. Now that the server is prepared to generate a log file during the installation of SQL 2005 SP2 we can now launch the installation again and see what happens. During the installation of the Service Pack, installing the SQL Server Support Files we receive the following error:
We’ll want to take a look through the Windows Installer log that was generated; which is always generated in the logged on user’s \temp directory (%temp%):
=== Verbose logging started: 7/5/2007 10:04:57 Build type: SHIP UNICODE 3.01.4000.4042 Calling process: c:\8353cbfd29e082f755ad9957\hotfix.exe === MSI (c) (20:14) [10:04:57:494]: SOFTWARE RESTRICTION POLICY: Verifying package --> 'C:\WINDOWS\Installer\941ae4.msi' against software restriction policy MSI (c) (20:14) [10:04:57:494]: Note: 1: 2262 2: DigitalSignature 3: -2147287038 MSI (c) (20:14) [10:04:57:494]: SOFTWARE RESTRICTION POLICY: C:\WINDOWS\Installer\941ae4.msi is not digitally signed MSI (c) (20:14) [10:04:57:509]: SOFTWARE RESTRICTION POLICY: C:\WINDOWS\Installer\941ae4.msi is permitted to run at the 'unrestricted' authorization level. MSI (c) (20:14) [10:05:27:572]: Failed to connect to server. Error: 0x80080005
At this point we need to make note of the "Failed to connect to server" error. This is a different error code than before, we can use the same tool mentioned earlier (Visual Studio Tools - Error Lookup) to get some more details on this.
So, from here we know the service is registered but fails during the execution of the installation of the .msi package. Since the windows installer logs aren’t giving us much to go on in this scenario we can use a different tool - Process Monitor. We covered Process Monitor in a previous post. When setting up Process Monitor you’ll want to set a filter for msiexec.exe to watch what’s going on behind the scenes during the service pack installation as shown in the image below:
Now that that’s all setup we can try the installation again. Looking at the msiexec.exe process we can see in the Process Monitor log files that we are getting ACCESS DENIED errors when trying to access HKEY_CLASSES_ROOT\Installer and HKEY_CLASSES_ROOT\CLSID:
Knowing that we are seeing ACCESS DENIED messages when trying to access the registry, the obvious thing to check is permissions. When we check the permissions in the registry on HKCR\Installer, we find that the SYSTEM account has DENY privileges and that it is an inherited permission (Figure 1).
After giving the SYSTEM account FULL CONTROL to HKCR (Figure 2) and allowing these permissions to propagate down through the remainder of the HKCR hive we’re ready to try the Service Pack installation again. At this point, we were able to successfully install SQL Server 2005 Service Pack 2.
That brings us to the end of this post. As you can see, sometimes it takes a variety of tools to accurately diagnose and troubleshoot Windows Installer issues.
- Brian Zoucha
7/31 EDIT: Figures 1 and 2 above were transposed. Thanks to Charles Gaudette who spotted the mistake.
PingBack from http://www.ditii.com/2007/07/13/troubleshooting-a-windows-installer-issue/
Thanks for the excellent blog posts - they're extremely useful for solving real world problems.
Couple of comments though - we now have the memory to be able to store the error string, so there shouldn't be any need to use ERRLOOKUP.EXE and its ilk. As troubleshooters we need to stop accepting this crap programming practice and push back hard on the developers to stop being lazy in their coding. Their lack of code completeness cascades to each and every one of us who has to perform this lookup. It's a huge cost impost imposed upon all businesses that employ sysadmins.
The second comment regards Process Monitor. It constantly astounds me the lack of quality troubleshooting tools Microsoft release for their own products. The Sysinternal tools are a good example. Another good example is the lack of good WMI Diagnosis tools. It staggers me that WMIDiag is an unsupported tool, yet it's one of the few comprehensive diagnosis tools for WMI. Absolutely amazing given how critical WMI is to the health of a server system.
Microsoft QA really needs to look at the quality and availability of support tools as part of a product release cycle.
I did download & install the utility called Err.exe,but i am not sure how to use the tool to lookup the error.Can you point me to some resources that might help
When you downloaded Err.exe you should have gotten a word doc along with the utility. Basically there are five different parameters you can pass to Err:
1. decorated hex (0x54f)
2. implicit hex (54f)
3. ambiguous (1359)
4. exact string (=ERROR_INTERNAL_ERROR)
5. substring (:INTERNAL_ERROR)
Try passing the following parameters so you can see the results:
- err 1708
- err 0x7b
- err IRQL_NOT_LESS_OR_EQUAL
Hope this helps - and THANK YOU for reading the AskPerf Blog!
- CC Hameed
This is very interesting. Thank you. However, aren't "Figure 1" and "Figure 2" supposed to be the other way around? It looks like the images do not match your text. As I am seeing it fig. 1 has check-marks in the "Allow" column; and fig. 2 has dimmed check-marks in the "Deny" column.
Are there any other tools available? My error keeps coming up although all access is available for the SYSTEM. Evrything says SUCCESS in Performance Monitor, so I'm not sure where to go now.
When I log on to the internet a windows installer window always pops up and it says preparing to install,then after 30 seconds to a minute goes by it goes away but sometimes it keeps popping up and it will not let you to any surfing the web until it disappears.you can click on cancel but it does no good. and if you open up like a smaller window to view it always pops up and the window will not display untill it goes off. please help i have tried everything. Thanks
I have the same problem with the windows installer as
Robert Tackett can anyone help?
I need to increase the performance of my installer. I am using Install Shield X permier edition and it takes lots of time to uninstall/install the software.
I have exactly the same problem with my window installer popping up every time I try to use word. The Dell Support man tried for 2 hours but couldn't solve the problem.
Can you please help, as I am writing a book together with other important tasks and at the moment I cannot do anything, the windows installer will not let me.
Please, please help. Anne-Lucinda
Robert / Kathy / Anne-Lucinda -
Your best bet is to open a support incident with Microsoft for assistance. It sounds like there is an application that is trying to finish an install and keeps failing - but you really need to work with a Support Engineer on your issue.
InstallShield is not a Microsoft product. You would probably need to contact the developers of InstallShield for assistance with your custom installer script. The odds are that if you look through your installation logs you'll find that there's a specific action in the script that is causing the issue. Try to install a generic MSI downloaded from the Microsoft.com site. If that MSI installs fine, then the problem is with your particular script. If not, then you may have an installer problem and you should open a support incident with Microsoft Product Support for assistance with the Windows Installer (not InstallShield)
I have a issue with everytime we long on to the computer, the Windows Installer window pops on & is preparing to install every application. This is driving me nuts. How can I remove this. Thank you