The Case of the Installer Service Error

This case unfolds with a network administrator charged with the rollout of the Microsoft Windows Intune client software on their network. Windows Intune is a cloud service that manages systems on a corporate network, keeping their software up to date and enabling administrators to monitor the health of those systems from a browser interface. It requires a client-side agent, but on one particular system the client software failed to install, reporting this error message:

The dialog’s error message translates to “The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.”

The administrator, having seen one of my Case of the Unexplained presentations where I advised, “when in doubt, run Process Monitor,” downloaded a copy from Sysinternals.com and captured a trace of the failed install. He followed the standard troubleshooting technique of looking backward from the end of the trace for operations that might be the cause, but after about a half hour of analysis he gave up and switched to a different approach. Instead of looking for clues in the trace, he thought he might be able to find clues by comparing the trace of the failing system to another captured on a system where the client installed successfully.

A few minutes later he had a second trace to compare side-by-side. He set a filter to include only events generated by Msiexec.exe, the client setup program, and proceeded through the events in the trace from the problematic system, correlating them with corresponding events on the working one. He eventually got to a point where the two traces diverged. Both traces have references to HKLM\System\CurrentControlSet\Services\BFE, but the failed trace then has registry queries of the ComputerName registry key:

The working system’s trace, on the other hand, continues with operations from a new instance of Msiexec.exe, something he noticed because the process ID of the subsequent Msiexec.exe operations were different from the earlier ones:

It still wasn’t clear from the failed trace what caused the divergence, however. After pondering the situation for a few minutes he was just about to give up when the thought crossed his mind that the answer might lie in the operations that the filter was hiding. He deleted the filter he’d applied that included only events from Msiexec.exe from both traces and resumed comparing traces from the point of divergence.

He immediately saw that the trace from the working system had many events from a Svchost.exe process that weren’t present in the failed trace. Working under the assumption that the Svchost.exe activity was unrelated, he added a filter to exclude it. Now the traces lined up again with events from Services.exe matching in both traces:

The matching operations didn’t go on for very long, however. Only a dozen or so operations later the trace from the failing system had a reference to HKLM\System\CurrentControlSet\Services\Msiserver\ObjectName with a NAME NOT FOUND error:

The trace from the working system had the same operation, but with a SUCCESS result:

Sure enough, right-clicking on the path and selecting “Jump to…” from Process Monitor’s context menu confirmed that not only was the ObjectName value missing from the failing system’s Msiserver key, but the entire key was empty. On the working system it was populated with the registry values required to configure a Windows service:

Somehow the service registration for the MSI service had been corrupted, something the initial error dialog had stated but without guidance for how to fix the problem. And how the service had been corrupted would likely remain forever a mystery, but the important thing now was fixing it. To do so, he simply used Regedit’s export functionality to save the contents of the key from the working system to a .reg file and then imported the file to the corrupted system. After the import, he reran the Microsoft Intune installer and it succeeded without any issues.

With the help of Process Monitor and some diligence, he’d spent about forty-five minutes fixing a problem that would have ended up costing him several hours if he’d had to reimage the system and restore its applications and configuration.

You can find more tips on running Process Monitor, as well as additional illustrative troubleshooting cases, in my Windows Sysinternals Administrator’s Reference, a book I recently published with Aaron Margosis. If you’ve read it, please leave a review on Amazon.com.

Comments

• Anonymous
  January 01, 2003
  Although not an IT professional I consider myself a PC expert and often use Process Monitor and Process Explorer to find useful information and/or debug. For example many applications cannot be fully configured via their UI but one can check what registry keys etc are checked for configuration information. As per this article I look for NOT FOUND references in the log and see if the named key(s) look "interesting". Just yesterday I was able to customize SNMP community names for a program that provided no way to set them and had no documentation (even on the vendors website).

• Anonymous
  January 01, 2003
  Procmon is a life saver...Thanks Mark!

• Anonymous
  January 01, 2003
  appreciable write up, I wonder why don't Microsoft hold OEM's to a elevated standard?

• Anonymous
  January 01, 2003
  Awesome Mark. Procmon is an AMAZING tool.

• Anonymous
  January 01, 2003
  Same thing happened to me once. Only I took a slightly different approach: I went about to confirm the assertions of the error message. So, I checked with SC.EXE and it told me that there was no Windows Installer service registered. So,  I imported the correct service registration data. Process Monitor is an excellent tool, but one who uses it must know exactly what he is looking for. (Strange though, I could swear I posted this comment here before.)