I've been debugging a crash in an application which appears to stem from the Acrobat Reader ActiveX components, when Acrobat Reader DC 2017 is installed on the computer. The application is a native Windows application written in C++, but I cannot easily create a sample project for it (inherited code base, not my forte), but I'm getting the same error (Structured Exception) from a simple test/repro project made in C#.
In this specific crash instance, it appears that the key step is performing any key press operation, within the control, after loading a document. This brings up the special tools in the right-hand side of the viewer's control area.
The sample C# repro project can be downloaded here: Dropbox - AcrobatReaderCrash.zip , and the steps to reproduce from it are as follows:
- Start the application, with or without debugging enabled
- Click on either of the "Load" buttons, at least once, up to however many you'd like
- Click within the viewer
- Press the "Esc" key
- Click the load buttons again, if you'd like. This part doesn't make a different
- Click the "Exit" button (or "X" in the Windows bar, Alt+F4, System menu + "Close", etc)
- Exception is raised and application crashes.
To the best of my diagnosing abilities, but don't take my word as the final authority on it, what appears to be happening is that a component created or referenced within the ActiveX control is getting double-freed, thus causing the "NullReferenceException" in the .net code, and the "ACCESS_VIOLATION" SEH from "native" code.
Is there any call which should be made prior to closing or disposing of the control? Or perhaps some property that can be set to prevent the command bar from being displayed (it can also be activated by clicking the "Acrobat" triangle logo which appears in the floating bar with page numbers, etc, in the viewer).
1
Reply
AdChoices