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

[AccessViolationException]

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

[Akiratorishi]

Sorry Kaozci but this workaround is not so helpful. This workaround is known. This is an old problem that has no solution even with the newest release of acrobat.

[Guest]

For any that need a fix for this in Access/VBA the solution for me was to use a low level keyboard hook. Sub classing the window proc causes all sorts of gimpy behvior in access, even a window proc that does nothing more than call the default window proc. Instead you can install a WH_KEYBOARD_LL hook and supress the tab key on the form housing the acrobat control. For some folks this will be a problem (tabbing through controls) however we personally use the pdf control on its own dialog outside the main access window so it works fine for us. I'm not sure how it affects pdf forms either, again a non-issue for us. Any how, here's the code, adapt it for your needs:

' Win32 Module
Public Const WH_KEYBOARD_LL = 13

Public Type KBDLLHOOKSTRUCT
    vkCode As Long
    scanCode As Long
    flags As Long
    Time As Long
    dwExtraInfo As Long
End Type

Public Declare Function SetWindowsHookEx Lib "user32" Alias "SetWindowsHookExA" (ByVal idHook As Long, ByVal lpfn As Long, ByVal hmod As Long, ByVal dwThreadId As Long) As Long
Public Declare Function UnhookWindowsHookEx Lib "user32" (ByVal hHook As Long) As Long
Public Declare Function CallNextHookEx Lib "user32" (ByVal hHook As Long, ByVal nCode As Long, wParam As Any, lParam As Any) As Long
Public Declare Function GetModuleHandle Lib "kernel32" Alias "GetModuleHandleA" (ByVal lpModuleName As Any) As Long
Public Declare Function GetActiveWindow Lib "user32.dll" () As Long

' Some other module
' Please note the keyboard hook procedure HAS to be in a module, AddressOf will not work 
' for a function inside a form module.

Public Property Get KeyboardHookHandle As Long
     KeyboardHookHandle = ' where ever the handle of the hook is stored
End Property

Public Property Let KeyboardHookHandle(val as Long)
     ' store the hook handle in global variable, in a control on a form, wherever you like....
End Property

' Form_PdfViewer is the form that holds the adobe pdf viewer control
Public Function KeyboardHook(ByVal nCode As Integer, wParam As Long, lParam As Win32.KBDLLHOOKSTRUCT) As Long
    If nCode >= 0 Then
        If lParam.vkCode = vbKeyTab And Win32.GetActiveWindow() = Form_PdfViewer.hwnd Then
            Debug.Print "Aborted tab key press!"
            DoEvents
            KeyboardHook = 1
            Exit Function
        End If
    End If
    
    DoEvents
    KeyboardHook = Win32.CallNextHookEx(KeyboardHookHandle, nCode, wParam, lParam)
End Function

' The form housing the adobe pdf viewer control
Private Sub Form_Load()
     KeyboardHookHandle = Win32.SetWindowsHookEx(Win32.WH_KEYBOARD_LL, AddressOf KeyboardHook, Win32.GetModuleHandle(vbNullString), 0)
End Sub

Private Sub Form_Unload(Cancel As Integer)
    Win32.UnhookWindowsHookEx KeyboardHookHandle
End Sub

Another alternative is to use the web browser control which works fine in access 2003 on windows 7 with ie9 however you can't resize the control on windows xp with access 2002 and ie8 and unfortunately we still have users with that configuration so it's not an option for us.

[Guest]

Thanks hugely jptros, this (ignored by Adobe) bug has been annoying me for quite a while. I'd implemented a kludge to handle the tab but your solution is much better.

I had to fiddle with it a bit to get it to work for me - in case anyone else needs it, my adjusted version is pasted below.

' Until Adobe get around to fixing the bug with the Tab key, have this in a stand alone module

' When (if) it's fixed, delete the module and remove the references in the Form_Load and Form_Unload on any forms that are referencing this code

Option Compare Database

Option Explicit

' This lot are used to hook the [TAB] key on forms showing the Acrobat PDF viewer control

' because of the bug in their code that causes Access to lock up.

' http://forums.adobe.com/thread/530591?tstart=0

Public Const WH_KEYBOARD_LL = 13

Public Type KBDLLHOOKSTRUCT

    vkCode As Long

    scanCode As Long

    flags As Long

    Time As Long

    dwExtraInfo As Long

End Type

Public Declare Function SetWindowsHookEx Lib "user32" Alias "SetWindowsHookExA" (ByVal idHook As Long, ByVal lpfn As Long, ByVal hmod As Long, ByVal dwThreadId As Long) As Long

Public Declare Function UnhookWindowsHookEx Lib "user32" (ByVal hHook As Long) As Long

Public Declare Function CallNextHookEx Lib "user32" (ByVal hHook As Long, ByVal nCode As Long, wParam As Any, lParam As Any) As Long

Public Declare Function GetModuleHandle Lib "kernel32" Alias "GetModuleHandleA" (ByVal lpModuleName As Any) As Long

Public Declare Function GetActiveWindow Lib "user32.dll" () As Long

Dim gKeyboardHookHandle As Long

Public Property Get KeyboardHookHandle() As Long

     KeyboardHookHandle = gKeyboardHookHandle

End Property

Public Property Let KeyboardHookHandle(val As Long)

     ' store the hook handle in global variable, in a control on a form, wherever you like....

End Property

Public Function KeyboardHook(ByVal nCode As Integer, wParam As Long, lParam As KBDLLHOOKSTRUCT) As Long

Dim hwnd_Form_PDFViewer As Long

    ' I'm only using the PDF viewer on a single form so only care about a single hwnd

    If Screen.ActiveForm.Name = "frmDocumentArchive" Then hwnd_Form_PDFViewer = Screen.ActiveForm.hwnd

    If nCode >= 0 Then

        If lParam.vkCode = vbKeyTab And GetActiveWindow() = hwnd_Form_PDFViewer Then

            Debug.Print "Aborted tab key press!"

            DoEvents

            KeyboardHook = 1

            Exit Function

        End If

    End If

    DoEvents

    KeyboardHook = CallNextHookEx(KeyboardHookHandle, nCode, wParam, lParam)

End Function

'---- From here on, these are in the form which needs the [TAB] presses to be consumed to prevent the crash.

Private Sub Form_Load()

    ' Handle the Acrobat bug

    KeyboardHookHandle = SetWindowsHookEx(WH_KEYBOARD_LL, AddressOf KeyboardHook, GetModuleHandle(vbNullString), 0)

End Sub

Private Sub Form_Unload(Cancel As Integer)

    ' Clean up after handling the Acrobat bug

    UnhookWindowsHookEx KeyboardHookHandle

End Sub

[Guest]

I spoke to soon.

Maybe it's the changes I made - but this code consumes all TAB presses in all windows, not just the ones in Access... and then Access crashes when you exit the application.

Looks like the same crash that would have occurred without this hook consuming the key presses.

Improvement over crashing any time that Tab is pressed when the form with the reader control is open and the control is populated, but still doesn't resolve the problem.

Ah well, rolling back to my bodgy fix.

[Guest]

Are you saving the hook handle? The code above doesn't seem to be, you never put anything in the body of the KeyboardHookHandle setter. That means you're not unhooking when the forms closes and when you call the CallNextHookEx function you're passing an invalid hook handle in the first parameter. Also, I've tested this code with multiple forms and it only drops tab presses on the form with the acrobat control, that's what the GetActiveWindow() = Form_FooBar.hwnd in the keyboard hook is for. The way we use the adobe reader control is to open a popup form outside of access. Tabbing between controls on other forms works fine so the GetActiveWindow() check is working fine in our application. In addition to testing I performed, I deployed this fix to a few users this afternoon and didn't hear a peep out of them for the rest of the day so it's working for us.

---

Forgot to add that I've only tested this method of preventing the crash in access 2002 and 2003.

[Guest]

I thought it was odd that there was nothing in the Get or the Let, but I have not used those so had no idea what was supposed to be done and thus left them as is.

What should be in there?

[Guest]

Dim m_hookHandle as Long

Public Property Get KeyboardHookHandle As Long

   KeyboardHookHandle = m_hookHandle

End Property

Public Property Let KeyboardHookHandle(val as Long)

   m_hookHandle = val

End Property

That should get you started. The reason I didn't include a body to those properties is because some folks handle things differently. Access, if you have never noticed, will reset all variables in the event of an unhandled error. In a locked down mdb, the code silently discards the error and continues to run only now with unexpected data stored in the global variables which obviously is a pretty bad thing. I've seen folks store global variables in hidden form fields and in tables. Just depends on the person and the scenario, so I just left those properties empty. This really goes outside of the scope of the problem here, a quick google search for 'access vba variables reset' should turn up plenty of details about what happens if you don't do proper error handling in your vba projects.

--

And as a result, if you don't unhook and call the next hook in the chain properly, wierd things can happen so it's important that you retain the handle returned when you set the keyboard hook until your hook has been released.

[Guest]

Perfect, thanks hugely.

[Akiratorishi]

PROBLEM FIXED IN ACROBAT READER XI !!

Hello Everybody. I tried the AxAcroPDFLib in a windows form app and with Acrobat reader XI.

The problem with this ocx/dll is not present with this version of acrobat reader. I think the problem is definitively solved.

Peace.