Windows Explored

Often times when sorting through Process Monitor logs, you find yourself having to employ some intuition to zero-in on what is an otherwise vague result: NAME NOT FOUND. Its normal to see these results en masse, and most of these are perfectly legit. But knowing how to apply a few filters and some basic understanding of what you are looking for is sometimes enough to narrow down why your application is failing. In a previous post, I demonstrated this approach. Here is another example.

In this case, the user was not able to open PDFs from within our Outlook-integrated document management system. The error reported was rather generic as you can see below:

Initial troubleshooting consisted of repairing both Adobe Reader and our document management system from Add or Remove Programs, but the problem persisted. I copied Process Monitor from our lab to the problem workstation and ran it as the local administrator, set a filter for Outlook.exe, reproduced the error, and stopped the trace. There were 3600+ operations. Fortunately, procmon offers filters galore. I first start with Tools > Count Occurrences. There is nothing “unique” here so I start with NAME NOT FOUND and we go down to a manageable 468 operations.

PDFs open fine outside of the document management system, so we’re likely dealing with some missing registry key and we can filter some more by looking only at registry operations by leaving only that option selected:

Last, we can focus on the likely operation type, RegOpenKey, narrowing the log down to a manageable 368 operations. With that, I scan the log, working my way up and spot an Adobe Reader key (Acrobat) that looks interesting:
HKCR\AcroExch.Document\shell\open\command

On the problem workstation we see instead Shellex, a sign that another PDF application was present at some point. However, the critical Open\Command keys are missing. The Command key would contain a string value equal to the path of the required PDF application.

Compared to another workstation where the PDFs opened fine from the document management system:

Knowing this, creating a Shell\Open\Command subkey with a (Default) string value equal to “C:\Program Files\Adobe\Reader 9.0\Reader\AcroRd32.exe” “%1” on the problem workstation resolved the problem.*

Alternatively, reinstalling Adobe reader (and deleting the AcroExch.Document key in extreme cases) should also properly restore the key and value. The cause for this is due to the installation and removal of the other internal PDF application we use for editing PDFs. Checking the history of this workstation revealed that, in fact, the alternative PDF app was removed previously, and likely during installation or removal the Adobe Reader Shell sub keys were deleted.

If you’re wondering if this can also be accomplished by editing the extension from the File Types tab in the Explorer Folder Options by editing the Open action, the answer is, yes. This is the same approach to modifying the registry programmatically.

*The Shell key may also contain a View\Command subkey that should also contain the same default string value.