When I looked in the 32bit module path C:\Program Files (x86)\Common Files\Adobe\Acrobat\WCIEActiveX I could see that AcroIEFavClient.dll (the Adobe PDF Toolbar for IE) was missing from this path. However, the More information link above can only show you the path for the 64bit module if both are present. The Acrobat add-on for IE supports both 32bit and 64bit process modes for IE. I quickly spotted the issue and knew what the problem was: I further filtered the results using Count Occurrences from the Tools menu and focused on No Such File results as there were only a handful and if a dependency was missing, it should be easily spotted here. I clicked on the dysfunctional toolbar a couple times and stopped the trace. Sure, enough, the DLL was present in C:\Program Files (x86)\Common Files\Adobe\Acrobat\WCIEActiveX\圆4.įor a deeper dig, I fire up Process Explorer and set a filter to only look at iexplorer.exe processes. How about the actual DLL itself? Where this resides can be gathered from the bottom portion of the Manage add-ons window by clicking on More information: And, yes, it seems to be there and enabled: This can be done from Internet Options > Programs > Manage add-ons. The first thing to check was that the toolbar add-on module was actually loaded into the browser. Specifically, opening or trying edit form-fillable PDFs would result in a generic “Error opening URL to submit this form.”Īdditionally, it was noticed the Acrobat PDF Toolbar in IE stopped working and clicking on it did nothing. Soon after, we began to receive complaints that working with PDFs from the Internet in IE was at times dysfunctional. Although we did pilot it, once it went into our production environment, the wider user audience found that there were too many issues with the new product and we decided to go back to Adobe Acrobat. The next course of action would be to modify the company firewall to allow the traffic.Ī while back we had decided to transition to a new PDF software application. To verify this was the case, I changed Outlook to use a legacy proxy server (this is done via IE > Internet Options > Connection Settings) that we still keep around and was able to see the image preview tiles after performing the process again. You can see that after hitting the initial IP (52.109…) for what looks to be, a disconnect takes place with path from, which is our firewall returning a false-positive for what it suspects to be adult content. I further isolated these events by removing activity for File, Registry, and Process Activity, keeping only Network: While quickly scrolling through the events, I noticed a couple entries for Network Activity with an obvious clue as to what was blocking the image previews. I fired up Process Monitor and reproduced the issue, filtering for processes only from Outlook.exe. In this particular case, when using the I nsert Online Pictures option available in a new Outlook message, after selecting one of the categories in the initial image window, a series of grayed-out tiles are presented instead of the actual image preview tiles: But here is a quicky on an often overlooked part of Process Monitor, specifically the basic logging it does for Network Activity. I have been out of it for sometime now, often tied up with one thing or the other and have not been able to contribute recently.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |