AccessViolationException fatal error, Acrobat 9, AxAcroPDFLib, .NET, Win7

Report · Nov 25, 2009

How do I work around the following fatal error: AccessViolationException

Steps to reproduce the error:

1. In MS VisualStudio 2008, Create a Windows Form Application, add a Panel and a Button components to the form.

2. Add a Reference to the Acrobat COM component for AxAcroPDFLib

3. Add the following code to the main form:

private AxAcroPDFLib.AxAcroPDF ax = new AxAcroPDFLib.AxAcroPDF();

    private void button1_Click(object sender, EventArgs e)
    {
      panel1.Controls.Add(ax);

      ax.LoadFile(@"c:\temp\myfile.pdf");
      ax.setView("Fit");
    }

4. Run the application

5. Click the Button

6. Press the TAB key on the keyboard.

Result: The application crashes with an AccessViolationException: Memory Corrupted error.

Note: I had been working on an application for about a month now, but had Never pressed the Tab key while the application was running until today!!

Although I did not yet test EVERY key, all other keys and activities inside and outside of the Acrobat component, application, and OS seem to work ok. I can't deploy an application to production if it will crash on Tab keypress.

Platform:

Windows 7, 32bit, all current updates

Acrobat 9 Standard, all current updates

Microsoft Visual Studio 2008 Professional, all current updates

I'm not an Acrobat SDK developer expert, so this may be some simple configuration setting.

Any assistance is greatly appreciated.

Arnold

Report · Nov 25, 2009

We are aware of the tab issue but I am pretty sure that it was fixed in 9.2 (the current update). Can you verify that you are on 9.2? Also, are you in Acrobat or Reader?

Report · Nov 25, 2009

I verified Acrobat's Help/About: Version 9.2.0 Standard

Windows 7 Enterprise (32 bit).

I tried .NET Frameworks 2.0 and 3.5.

I didn't try Acrobat Reader. Will the Reader behave differently? The final application is for Viewing/Read Only, so I won't need the features of the Standard edition beyond what the Reader comes with. My impression was that I needed the Standard or Pro version license to embed the viewer into a workstation application.

Arnold

Report · Nov 26, 2009

You don't need Standard or Pro - whatever the user has on their computer is what will be used. No "licensing" involved since you aren't distributing any Adobe parts.

Report · Nov 30, 2009

Acrobat 9.2 Standard definitely does not work with Microsoft Visual Studio 2008 interop. The Tab key is the killer. I'll try the Reader now and post the results. I need to resolve this or else I will be forced to use a more stable PDF viewer component.

Report · Nov 30, 2009

Acrobat Reader 9.2.0 crashes with the same AccessViolationException fatal error using Visual Studio 2008, Windows 7, and .NET framework.

This is not good.

Please let me know ASAP when this problem is fixed. I would really like to use Adobe Acrobat and the Acrobat SDK instead of a third party viewer.

Arnold

Report · Dec 03, 2009

I am running Reader 9.2.0, using XP, VS 2008 and the issue is still here.

it has not been fixed in the Reader 9.2.

Have you any information about next version which will fixe the issue ?

Is there any workaround meanwhile ?

Thank's.

Report · Nov 30, 2009

Looks like Acrobat will be dead for us in Windows 7 until this problem is fixed. I cannot get Acrobat 8 Reader to install in Windows 7, so until Acrobat 9.2.0 is fixed in Windows 7, we have to use a third party PDF viewer.

This was really unexpected!

Attention ADOBE: Please fix the <TAB> key problem in Acrobat 9.2.0 in Windows 7 and notify me ASAP as soon as the fix is ready.

Report · Nov 30, 2009

As I already said, we are aware of the problem and will release a fix as soon as possible in our current update schedule.

Report · Apr 09, 2010

I just tested this with Acrobat 9.3.1 on Windows XP and Windows Vista. This issue still exists, and has existed since Acrobat 9.0. There is an untrappable exception thrown when the user attempts to tab out of the AcroPDF control. Additionally, once a document is opened in the AcroPDF control, all keyboard keystrokes apply to the AcroPDF control, not the main application form. As a result, users with accessibility requirements cannot tab back to the application main menu or toolbar to continue operating the application once a document is opened.

I am using the AcroPDF control in a Windows executable application written in Visual Basic .NET 2008. Purchase of Acrobat Standard or better by the client for each PC that will have my application installed is a prerequisite for purchase.

My product cannot pass US Federal Government Rehabilitation Act Section 508 Requirements until this issue is resolved- effectively locking me out of the Federal Government market.

Does Adobe recommend another PDF viewer that developers should use that will allow Accessibility in their applications?

Report · Apr 14, 2010

I believe this was bug #2393752 which is fixed in 9.3.2.

Report · Apr 16, 2010

It is definitely NOT fixed in 9.3.2. At least with VB.Net 2005 on WinXP

Report · Mar 29, 2011

Hello Irosenth,

I've updated to Adobe Reader X and my customers and I still have this issue. Loading the pdf document and hitting the "TAB" key crashes the ActiveX control and the parent application. Now I think I've determined that it only crashes if Adobe doesn't have an object to tab to; for example I can load a pdf with the GUI disabled then hit tab and results in a crash, and likewise, if I load a pdf with entry fields, then I am able to tab through all of the entry fields but near the end it again results in a crash.

We're not able to override an ActiveX method in our application language; otherwise I wouldn't have a problem doing so as outlined here, but is this issue being looked at so I may inform my customers that you're looking into it? If there is any other information that you require please let me know.

Thanks,

- Dustin Buschow

Report · Mar 29, 2011

FYI:

I submitted this fatal error condition in Acrobat Reader to ADOBE about 1 year

ago. After 2 formal releases and 4 or more updates, this fatal bug is not

fixed.

This bug makes the touch screen application unusable with a keyboard attached,

unless I put a plug under the TAB key to prevent crashing.

The "club" of people that have joined my bandwagon to get this bug fix have

discovered the bug existed a few versions before I reported it. They have tried

all kinds of work-arounds.

It is really a concern, because I want to integrate Acrobat Reader into ATMS

2014. But I don't think anyone wants to give up the TAB key in the ATMS.

Arnold Stadlin

[signature deleted by host]

Report · Apr 16, 2010

Here is a workaround I've found. I haven't had any problems with it (yet), but you'll want to test it out in your application.

I was able to trap the error and prevent it from display by adding an error handler in the load event of my form and the handler subroutines.

This catches the error and prevents the user from seeing it.

I added this code to my form's load event:

Dim currentDomain As AppDomain = AppDomain.CurrentDomain

'for threads behind forms

AddHandler Application.ThreadException, AddressOf MYThreadHandler

and I declared the sub below. I just want to catch and suppress this error, so I have everything in the subroutine commented out.

Sub MYThreadHandler()

' Handle the event.

'MsgBox.Show("MYExceptionHandler caught event.")

End Sub

Hope this helps.

Report · Apr 16, 2010

Forgot to say that I'm using my workaround above is used with Adobe Reader. Seems to work with 9.3.1 and 9.3.2. I haven't tested it with anything else.

Report · Apr 16, 2010

Just a follow up. my project was deployed in January and its Acrobat is updated to the current version of Acrobat at this time. However, the application is a Touch Screen application, so I can't tell if the problem is resolved - since there is no keyboard attached. It is my hope that the problem is fixed so my next project development will not have the same issue.

Arnold

Report · Jun 10, 2010

Ok, guys,they do not seem to fix the problem after about a year of first finding it. I am using Adove Reader 9.3.2 and the bug is still there.

I found the workaround which works perfectly.

In the window where you've created the Adobe PDF Reader Active X control override the OnPretranslateMessage() method.

Paste the following chunk of code to block the internal Adobe's Application message 0x1450 (5200L). If you do not use MFC or C++, then find a place to override message processing.

BOOL CMyDialog::PreTranslateMessage(MSG* pMsg)

{

// insert this chunk of code.

// Replace m_pdfCtrl with the name of your Adobe control.
if(pMsg->hwnd == m_pdfCtrl.GetSafeHwnd())
{
    if(pMsg->message == 0x1450)
    {
      return TRUE;
    }
}

return CDialog::PreTranslateMessage(pMsg);

}

BTW, I've send the detailed report to Adobe with the steps to replicate, and as expected no reply from them. Good for you, Adobe.

Report · Jan 11, 2011

Hello to everyone.

The TAB exception STILL EXISTS in the X (10) version.

The activex generates the same problem both on .net projects and on borland c++ builder projects(no .net but classis COM).

The last answer workS(Pretranslatemessage)!

What you have to do is contained in this link http://geekswithblogs.net/Jaggi/archive/2006/02/02/67999.aspx.

Obviously you have to process the write key message "0x1450" and not WM_KEYUP.

Report · Jun 27, 2011

I tested the following PreFilterMessage handler and it appears to work using VS2010, C#, .NET4, and Acrobat X Reader.

public partial class MyAcrobatReaderCTRL : UserControl, IMessageFilter
{
    public MyAcrobatReaderCTRL()
    {
      InitializeComponent();

      // Add the PreFilterMessage Handler for this control to the Parent Application
      Application.AddMessageFilter(this);
    }

    public bool PreFilterMessage(ref Message m)
    {
      // Block the internal Adobe's Application Fatal AccessViolationException when pressing the TAB key.
      bool bFiltered = true;

// Adobe's Application Message = 0x1450 (5200L)
const int WM_ACROBAT_1450 = 0x1450;

      // Apply the filter
      if (m.Msg == WM_ACROBAT_1450)
      {

        //// Block this message or it will trigger a fatal AccessViolationException when the TAB key is pressed.
        // return true
      }
      else
      {
        // Other messages can pass through the filter
        bFiltered = false;
      }
      return bFiltered;
    }

...

}

** Thank you aucha for the explanation of the Acrobat message causing the bug, and Akiratorishi for pointing me to a reference for C# code that I could modify and implement (hopefully reliably).**

Since this is still an Acrobat/Windows.NET bug, I'm not going to tag it as "Answered" until it is either fixed or until Adobe provides an affirmative work around example that they endorse. That is - until we know that the result of this message being blocked is not causing other problems.

With the above code, at least I can deploy my application to users with keyboards and see what happens.

Arnold

Report · Feb 17, 2011

Working in Access, I'm getting the same fault as everyone else in this thread.

Have disabled tab stops for all controls (including the Reader control) - still occurs.
Have the Form_KeyDown event capturing vbKeyTab and setting it to 0 - still occurs.
Have used Private Declare Function GetAsyncKeyState Lib "User32" (ByVal vKey As Integer) As Long to intercept the Tab's
(but can't find a way to consume the Tab out of the keyboard buffer and am assuming that is why the Reader control still reacts to the Tab)

If anyone knows of a way to implement the PreTranslateMessage workaround posted by aucha in VBA, it'd be greatly appreciated.

Report · Feb 17, 2011

Hi guys,

I'd like to provide you with an update. Back in June 2010 I have lodged an Adobe product Security vulnerability incident report via the Adobe website. It took them 8 months to come up with a solution. The solution is however is not perfect. You need to copy a Microsoft legacy MFC dll MFC71.dll. There is no way you can download this dll officially from the Microsoft website, as they are apparently dropped support for this version of MFC.

Below is the copy of my conversation with Adobe

From: Adobe PSIRT [mailto:psirt@adobe.com]
Sent: Thursday, February 03, 2011 2:04 PM
To: aucha
Subject: RE: Adobe product security vulnerability feedback form (586)

Hello aucha,

Thank you again for your report of Adobe ID 586. Our investigation of this issue found the problem to be related to MFC71.dll , which was not installed in the case of AcroView.exe. After manually copying the MFC71.dll to the same folder as Acroview.exe (alternatively, MFC can be statically linked with the program), no crash was observed. If your investigation proves otherwise, please let us know.

Again, thank you for your continued help and discretion. Please let us know if you have any questions.

Thank you,

Wendy

Adobe Product Security Incident Response Team

-----Original Message-----

From: Adobe PSIRT

Sent: Wednesday, June 16, 2010 12:03 PM

To: aucha

Cc: Adobe PSIRT

Subject: RE: Adobe product security vulnerability feedback form (586)

Hello aucha,

Thank you for your report. We have been able to reproduce the issue and are currently working on a fix. We will be in touch with additional information as available regarding an eventual release schedule. In the meantime, we appreciate your help in not publicly disclosing this potential issue in order to protect Adobe's customers. This has been assigned the Adobe tracking number 586.

Thank you again for your help and discretion! Please let us know if you have any questions.

Thank you,

Wendy

Adobe Product Security Incident Response Team

-----Original Message-----

From: via web form [mailto:PSIRT@adobe.com]

Sent: Thursday, June 10, 2010 12:49 AM

To: Adobe PSIRT

Subject: Adobe product security vulnerability feedback form (586)

Name: aucha

Email: aucha

Phone:

CanAdobeContactUser: Yes

Product: Adobe Reader

ProductOther:

ProductVersion: 9.3.2

VulnerabilityDetail: I am a Senior Software Developer responsible for application design and development at our company. Our team has identified a vulnerability in 'Adobe PDF Reader <1.0>' Active X (IAcroAXDocShim) control residing in AcroPDF.dll. When the control is placed on a dialog form and a pdf file is loaded, then hitting <Tab> key causes the application to crash.

I have researched the Internet and found that this issue has been observed by someone at lease a year ago in version 8, and apparently has not been fixed since.

As far as I know MS Internet Explorer has a workaround for this issue.

Please advise if this will be fixed, or if there is a know workaround for this.

Regards,

aucha

DefaultConfigVulnerable: Yes

ConfigChangesRequired:

VulerabilityResult: DataLossCorruption, DenialServiceApplication

PartiesAffected: ProductOwner, ThirdParty

HowToDuplicate: Create a simple MFC Dialog based application in Visual Studio.

Add new MFC class using VS wizard 'MFC Class from Active X Control'.

Locate 'Adobe PDF Reader <1>' in the list of installed Active X Controls in the system.

Generate a class for the IAcroAXDocShim interface.

Create a pdf control on the default MFC dialog in OnInitDialog() method.

Load a document using LoadFile() method.

Run the program.

Set Focus to the Adobe reader control using mouse click. Tab out of the control by pressing <Tab> key.

The program crashes.

If having troubles creating an MFC project, please load one from codeproject: http://www.codeproject.com/KB/miscctrl/acroview.aspx

ExampleProgram: Yes

WorkaroundsFixes: Yes

WorkaroundsFixesDetail: There is no any crashes in Internet Explorer. Microsoft must have done something. Please check with them please.

At the same time they implemented additional interfaces (such as IAcroIEHelperShimObj, DWebBrowserEvents2, etc). There is no information about these interfaces in the SDK documentation, so I guess they are designed specifically for MS

VulnerabilityBeingExploited: Yes

Report · Feb 17, 2011

I don't understand this, since Acrobat doesn't use MFC....

Report · Feb 17, 2011

As Akiratorishi said, you need to intercept 0x1450 message, not KeyDown message. You need to find our how to use the analog of PreTranslateMessage in MS Access

Maretine wrote:
Working in Access, I'm getting the same fault as everyone else in this thread.
Have disabled tab stops for all controls (including the Reader control) - still occurs.
Have the Form_KeyDown event capturing vbKeyTab and setting it to 0 - still occurs.
Have used Private Declare Function GetAsyncKeyState Lib "User32" (ByVal vKey As Integer) As Long to intercept the Tab's
(but can't find a way to consume the Tab out of the keyboard buffer and am assuming that is why the Reader control still reacts to the Tab)
If anyone knows of a way to implement the PreTranslateMessage workaround posted by aucha in VBA, it'd be greatly appreciated.

Report · Feb 17, 2011

aucha wrote:
As Akiratorishi said, you need to intercept 0x1450 message, not KeyDown message. You need to find our how to use the analog of PreTranslateMessage in MS Access

That's my difficulty.

I've been able to find examples of how to do that in C#, nothing for how to do it in Visual Basic for Applications - and VBA is sufficiently different from VB.Net that a straight transation from C# -> VB.Net doesn't work.