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
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]
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.
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?
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
On my computer Rolling back to Adobe Reader 8 was fixing the issue but this was not an acceptable solution/workaroud
static extern void CoFreeUnusedLibraries();
protected override void Dispose( bool disposing )
if( disposing )
if(axWebBrowser != null)
if(axWebBrowser.LocationURL != "about:blank")
axWebBrowser.Visible = false;
axWebBrowser = null;
if(components != null)
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)
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.
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.
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.
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.
(vmoreau) THANKS A LOT !! YOU SAFED ME ;-)
I just had to swap the browser dispose call and the Frr Unusued Libraries call:
static extern void CoFreeUnusedLibraries();
protected override void OnFormClosed(FormClosedEventArgs e)
// I set usedAcrobat to true if I open a PDF in my application
webBrowser.Visible = false;
This definitely works, I thought as well, that the reader somehow talks back after closing, but didn't know about CoFreeUnusedLibraries. Thousand thanks again
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:
[Frames below may be incorrect and/or missing, no symbols loaded for BIB.dll]
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?
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
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.