Our application is a 32-bit .NET application running on top of the .NET Framework 2.0 for compatibility with some third-party dependencies which it uses.
The application takes PDF documents and simply views them, in-situ, within a viewing pane hosted within the main application. This is done by…
1. Taking the PDF file from a central location and copying it locally to a temporary area to prevent file locking issues with other users viewing the same document.
2. The viewing pane hosts a .NET WebBrowser control, and interface code (as we have different types of viewer for different types of file).
3. To view the PDF internally within our application, we simply call the Navigate() method of the WebBrowser control, passing it the path and filename of the PDF we wish to view.
4. The PDF file appears within the WebBrowser control allowing the user to see and interact with it.
5. Upon closing we dispose of the PDF by navigating to an empty URL, and then calling WebBrowser.Dispose() to get rid of the control.
Obviously the above relies on IE being available, along with the Adobe Reader plugin correctly installed. If either of these two dependencies are missing then the internal viewing doesn’t work.
Since the updates which rolled out early last week, we have had various customers who use our software complaining of random 523:523, 507:507 and 1:1 errors when trying to view documents in our software. No exceptions are passed back from the WebBrowser control to our software, showing that the error is occurring externally to the application within Adobe Reader itself.
Previously we have been able to fix the 523:523 errors by advising customers to remove the ‘Enable Protected Mode at Startup’ setting, which has been successful up until now.
Now that Adobe has been quite dangerously forced to update to 64-bit, we have found that the 523:523 errors occur irrespective of whether the protected mode setting is on or off, but if Adobe Reader is reverted back to the 32-bit instance, the errors stop again with protected mode off.