Windows Explored

I was asked to assist when one of user’s was unable to perform the simple, mundane task of printing a web page in Internet Explorer. Furthermore, they could not even print preview the page. There was no error of any kind and IE simply went on with its business like nothing happened. I started my analysis by running Process Monitor on the workstation, creating a filter in the trace log for iexplore.exe. I then repeated the steps of the user by going to File > Print Preview and then stopped the trace log. There were just over 500 events logged in that one action, small enough that I was quickly able to scroll through it and I some Access Denied results:

The file operations are occurring on mshtml.tlb, which seems to play a role in printing in Internet Explorer or any html content. The obvious thing is that this file resides by default in windows\system32, but the location above is a temp folder, and specifically of the type that is created when Windows is running an update. Ideally, as far the user is concerned, this should be transparent and the process should continue along normally. When completed, the folder should then delete it’s content and\or itself.

When updates run, you can usually find an MSInstaller event in the application logs of the Event Viewer, which I did. But something had gone wrong. To gather some clues, I looked into the System event logs and saw this:

The Microsoft Installer service seemed stalled. To further confirm it was related to the MSI, I opened the registry in HKCR\CLSID and went to the class identifier listed in the description of the error message:

With the MSI Installer hung, I can only assume that the process had locked up the folder where the needed version of mshtml.tlb was required to process the user’s request while the needed files were being updates in windows\system32. To test this theory,  I right-clicked the mshtml.tlb file and got an Access Denied message. Instead, I right-clicked the folder and modified the security permissions by taking ownership and then inheriting rights of C:. I then tested the print preview and print functionality and it worked normally again. Alternatively, a simple reboot should have addressed the problem, too, and te update would try installing again later.

*It is not uncommon for these folders to not get removed after an update completes running. You will not always find them in the root drive; the disk with the most free disk space is where the updates are written to, even if it’s external storage.. It is safe to delete these folders if you run across them.