Skip navigation
Currently Being Moderated

The instruction at "0x0700609c" referenced memory at "0x00000014". The memory could not be read

Oct 1, 2008 8:31 AM

When viewing a PDF file in a browser using Adobe Reader v9.0 I received - The instruction at "0x0700609c" referenced memory at "0x00000014". The memory could not be read.

This occured in Google Crome after viewing a pdf file and then closing the Crome application. I was also able to reproduce this in a .NET application using the System.Windows.Forms.WebBrowser control and loading PDF files in the browser control.

The error does not occur every time but can be reproduced in my .NET application fairly easily by loading several pdf files quickly then closing the application.

This error does not occur when using Adobe Reader v8.
 
Replies
  • Currently Being Moderated
    Oct 7, 2008 3:10 PM   in reply to (Joe_Huber)
    I am get the error - The instruction at "0x0c69609c" referenced memory at "0x00000014" - working in .NET v9. I also received no error with v8. When I ran my .NET application with v8 Adobe Reader (AcroRd32) appeared in Task Manager. I upgraded to v9 because it was available. Now when I run my .NET application with v9 installed, "AcroRd32" (Adobe Reader) does not appear in Task Manager. I encountered this today
     
    |
    Mark as:
  • Currently Being Moderated
    Oct 11, 2008 10:34 PM   in reply to (Joe_Huber)
    I also got this message trying to use acrobat. I read on [edited by host] blog, that it is fixed by fixing some of the regitry entries in the regedit. Does someone knows something about it?
     
    |
    Mark as:
  • Currently Being Moderated
    Oct 12, 2008 4:42 AM   in reply to (Joe_Huber)
    Dor,

    That website is site for selling tools that edit the registry and other tools. If you had a specific blog entry that was relevant to this topic posting a specific link to an article of relevance would be helpful. I saw nothing directly related to this discussion. Hence I deleted the website reference you posted.

    Generally speaking it is a bad idea to edit the registry unless you know what you are doing. Registry editing tools that clean the registry generally are a bad idea that cause more problems than they fix.

    Mike [forum host]
     
    |
    Mark as:
  • Currently Being Moderated
    Oct 14, 2008 6:56 AM   in reply to (Joe_Huber)
    Mike,

    What is the solution? Should I just ignore this error every time it comes up?
     
    |
    Mark as:
  • Currently Being Moderated
    Nov 4, 2008 11:38 AM   in reply to (Joe_Huber)
    Has anyone posted a fix for this issue.
     
    |
    Mark as:
  • Currently Being Moderated
    Nov 23, 2008 12:56 PM   in reply to (Joe_Huber)
    This is still alive issue. I just received the same error after installing v.9 yesterday. It occurred when trying to close a window running v.9.
     
    |
    Mark as:
  • Currently Being Moderated
    Nov 26, 2008 3:05 PM   in reply to (Joe_Huber)
    I have the same error message, and i get it specifically when i open a pdf with form fields, and i have been entering information in the form fields. The error happens when the program is closed.

    I have been able to reproduce this error with the Adobe Reader 9 SDK sample applications (in particular AcrobarActiveXVB) and the FormSample.pdf from TestFiles on the SDK. To reproduce run the AcrobatActiveXVB application by double clicking the exe file in the bin folder, and load the FormSample.pdf, enter information in the form and then close the application (this may need to be done 10 times or so to produce the error)

    I have not been able to reproduce this error when the AcrobatActiveXVB program is run with the debugger attached. And also when i step through code in my program i don't get the error. Is there some way that memory is handled better when the debugger is attached, or could this be a timing issue.
     
    |
    Mark as:
  • Currently Being Moderated
    Feb 12, 2009 7:11 AM   in reply to (Joe_Huber)
    This issue is still present today. I've verified this by running the SDK sample "BasicIacOCXCS" and pushing one of the "Go" buttons and then closing the sample. It ends (not always, but most of the time - a timing issue?) with a message box: The instruction as "0x0700609c" referenced memory at "0x00000014". The memory could not be "read".

    I was using Acrobat Reader 9 with all the latest downloads.

    Does anyone have a solution to this problem?
     
    |
    Mark as:
  • Currently Being Moderated
    Mar 3, 2009 11:30 AM   in reply to (Joe_Huber)
    b Found an issue if adobe 9 used in WebBrowser

    We got the same issue in our application since some user have been upgraded to adobe reader 9 (latest liveupdate didn't fix issue).

    We are using WebBrowser [axWebBrowser] in a c# .NET 1.1 Application to mainly display .pdf
    Most of the time.. user had the this error when closing our application:
    ---------------------------
    sw: TestBrowserNET11.exe - Application Error
    ---------------------------
    The instruction at "0x0700609c" referenced memory at "0x00000014". The memory could not be "read".
    Click on OK to terminate the program
    ---------------------------
    OK
    ---------------------------

    On my computer Rolling back to Adobe Reader 8 was fixing the issue but this was not an acceptable solution/workaroud

    Fix:

    [DllImport("ole32.dll")]
    static extern void CoFreeUnusedLibraries();

    protected override void Dispose( bool disposing )
    {
    if( disposing )
    {
    if(axWebBrowser != null)
    {
    if(axWebBrowser.LocationURL != "about:blank")
    {
    axWebBrowser.Visible = false;
    axWebBrowser.Navigate("about:blank");
    }

    while(axWebBrowser.Busy)
    {
    Application.DoEvents();
    }

    CoFreeUnusedLibraries();

    axWebBrowser.Dispose();
    axWebBrowser = null;
    }

    if(components != null)
    {
    components.Dispose();
    }
    }

    base.Dispose( disposing );
    }

    I hope this could point you to a solution, even if some of you are directly using the Adobe ActiveX,
    thoose sites help me to find out what's going one... thanks to all, and hope this reply can save time to others ;o)
    [you guys]http://www.adobeforums.com/webx/.59b6a24b
    http://www.xtremevbtalk.com/showthread.php?p=1321672
    http://savij.com/2007/06/19/webbrowser-control-and-sharepoint-crash-at -close/
     
    |
    Mark as:
  • Currently Being Moderated
    Jun 29, 2009 3:01 PM   in reply to (Joe_Huber)

    My colleague and I are both using Adobe Acrobat 8 Professional. This similar error was happening to my colleague while viewing a specific pdf on a Sharepoint site. I tried to reproduce the error on my machine and I couldn't--I did not get the error.

     

    Today we were testing it on his machine to try to solve his problem and found the answer!

     

    When a file name had the letter "I", a space, then the letter "S", we got the error.

     

    For example:

    I Summary.pdf gave the error. (due to the "I" [space] "S")

    I_Summary.pdf did NOT give the error.

     

    So in Sharepoint, we simply added an underscore to the filename and the error went away.

     

    Weird...

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 30, 2009 8:02 AM   in reply to RuthJ1

    Another thing to try is to run the Microsoft Office Diagnostics tool. That fixed another problem I was having with that error.

     

    Go to Start, Programs, Microsoft Office, Microsoft Office Tools, Microsoft Office Tools Diagnostics.

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 2, 2009 1:36 PM   in reply to (Frederik_Mangelsdorf)

    I am getting the exact same error that only occurs in Reader 9. I have a WebBrowser component (not using Acrobat SDK at all) within a form that displays PDFs and my application crashes on exit. Since this problem has occurring for more then a year, I submitted a bug to Adobe. Hopefully it will be fixed soon.

     

    Igor

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 8, 2009 4:43 AM   in reply to (Joe_Huber)

    The same error in my application since AdobeReader 9 is installed. The error occurs sometimes when the application is closed, and it happens only when a pdf with font(s) has been loaded, the error doesn't occur in AdobeReader 8. I make use of the AdobeReader activex (uses AcroPDFLib_TLB in Delphi 7). Try..Except..End in the destructor doesn't help.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 9, 2010 6:06 PM   in reply to (vmoreau)

    (vmoreau) THANKS A LOT !! YOU SAFED ME ;-)

     

    I just had to swap the browser dispose call and the Frr Unusued Libraries call:

     

    [System.Runtime.InteropServices.DllImport("ole32.dll")]
    static extern void CoFreeUnusedLibraries();

     

    protected override void OnFormClosed(FormClosedEventArgs e)
    {
        base.OnFormClosed(e);

     

        // I set usedAcrobat to true if I open a PDF in my application
        if (usedAcrobat)
        {
            webBrowser.Visible = false;
            webBrowser.Navigate("about:blank");
            while (webBrowser.IsBusy)
            {
                Application.DoEvents();
            }
            webBrowser.Dispose();
            CoFreeUnusedLibraries();
        }
    }

     

    This definitely works, I thought as well, that the reader somehow talks back after closing, but didn't know about CoFreeUnusedLibraries. Thousand thanks again

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 29, 2010 2:11 PM   in reply to (Joe_Huber)

    Here  is my experience with this issue:

     

    In the Adobe Acrobat  8.1 and 9.1 SDKs, the BasicIacOCXCS project is meant to demonstrate, in  C#, proper use of the AxAcroPDFLib.AxAcroPDF class, which makes the reader available as an activeX control.

    If I open this project in either SDK, and in the project property pages, I mark the "Enable  unmanaged code debugging" check box, often enough I can run the app,  load a pdf, and crash on exit with:

    Unhandled exception at 0x0700609c in BasicIacOCXCS.exe: 0xC0000005: Access violation reading  location 0x00000014

    The call stack looks like this:

    >BIB.dll!0700609c()
    [Frames below may be incorrect and/or missing, no symbols loaded for  BIB.dll]   
    BIB.dll!07006184()
    BIB.dll!070064db()
    msvcr80.dll!78132bd9()
    ole32.dll!775057b3()
    ole32.dll!775057c8()
    mscorwks.dll!79f9e0bd()
    mscorwks.dll!79f9e024()
    mscorwks.dll!79f4c7d9()
    mscorwks.dll!79ef004e()
    mscoree.dll!79007c24()
    kernel32.dll!7c816d4f()
    kernel32.dll!7c8399f3()

     

    After this crash, the app is  still running, and so visual studio can't rebuild this code until the  IDE is closed, which causes the app to close, and then reopenned.

    If  I unmark the "Enable  unmanaged code debugging" checkbox, the app does not crash (in my experience),  which tells me that the unmanaged exception is ignored by visual studio,  and all is "well".

     

    What I get out of all this, is that  Adobe's BIB.dll, where blocks of memory are allocated using a custom  memory management system, is crashing occasionally when it is time to  exit. It is doing this whether or not the IDE is paying attention  (debugging unmanaged code or not).

     

    The application to which I wanted to add the ActiveX control is written in managed C++. In that environment, the exception is never ignored like it is in the C# environment. There, the way to see the call stack is to set the "Debugger Type" in the Debugging section of the project properties on the startup project from "Auto" to "Mixed". But even when it is set to Auto, the exception makes itself known with a dialog box informing me of the access violation, and telling me to click ok to terminate the application.

     

    This seems to be  quite an old issue, though it is new to me.

     

    I have tried using CoFreeUnusedLibraries, but have caused an occasional AccessViolation in the process, which is no better to me than an occasional unmanaged exception elsewhere.

     

    Igor, did your request go anywhere with Adobe? Does anyone have an  update on any advice Adobe has for this?

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 19, 2010 8:07 PM   in reply to (Joe_Huber)

    On my .Net application, I put this code to solve this problem on exiting the program:

     

     

     

    Private Sub BatchOrganizerForm_FormClosing(ByVal sender As Object, ByVal e As System.Windows.Forms.FormClosingEventArgs) Handles Me.FormClosing

     

    If Me.pdfViewFile IsNot Nothing Then

    System.Threading.Thread.Sleep(2000)

     

     

    Me.pdfViewFile.Dispose()

    Application.DoEvents()

     

    End If

     

     

    End Sub

     

    I think the problem is you must give time to dispose first the pdf control before the application.

     

    This code worked for me. I hope this helps.

     

     

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)