Windows Explored

Everyday Windows Desktop Support, Advanced Troubleshooting & Other OS Tidbits

Some PDF Internals

Posted by William Diaz on November 2, 2011


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:

image

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.

SNAGHTML16443ab

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:

image

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

image

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.

image

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

image

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.

Advertisements

One Response to “Some PDF Internals”

  1. […] Posted by William Diaz on December 7, 2011 I already discussed a different form of this error (One or more documents could not be opened) when trying to open PDFs from our document management system in Outlook in an earlier blog here. […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: