Exceptions Thrown (Errors Encountered) After Program Termination

Answer 1

I've seen plently of errors just like this recently. My issues were releated to how the CRT (C Runtime) intereacting with the .NET runtime cleans up a closing process. My application is complicated by the fact it is C++, but allows COM add-ins to to loaded, some which are written in C#.

To debug this, I think you're going to need to use native debugging. Visual Studio (set to mixed mode debugging) or WinDbg. Look up how to use the Microsoft public symbol server to download PDBs for windows components - you'll need those symbols.

Many of our problems were with .NET's (awful) COM client support. I say awful since it doesn't reference count correctly (without a lot of work on the developer's end). COM objects were not being referenced-counted down to zero until garbage collect was done. This often setup odd timing issues during shutdown - COM objects being cleaned up long after they should have been.

Answer 2

If your app is multi-threaded you could be getting errors from worker threads which aren't properly terminating and trying to access disposed objects.

Answer 3

A fancier word for "inconsistent" is "non-deterministic." And what happens non-deterministically in the .NET environment? Object destruction.

When this happened to me, the culprit was in the class that I wrote to wrap unsafe calls to an external API. I put cleanup code in the class's destructor, expecting the code to be called when the object went out of scope. But that's not how object destruction works in .NET, When an object goes out of scope, it gets put in the finalizer's queue, and its destructor doesn't get called until the finalizer gets around to it. It may not do this until after the program terminates. If this happens, the result will look a lot like what you're describing here.

Once I made my class implement IDisposable, and explicitly called Dispose() on the object when I was done with it, the problem went away. (Another advantage of implementing IDisposable is that you can instantiate your object at the start of a using block and be confident that Dispose() will get when the code leaves the block.)

Answer 4

I have IDISPOSE implemented but still getting similar error in my code. Can you guys confirm if did manage to solve the problem?

Thanks in advance for your help.

Answer 5

I have been getting this same error after running Microsoft Bootvis. It's an admin application used to speed up Boot times, it logs the time to load drivers on the next reboot, but normally after it reboots the program will load and show the result times. But, instead of loading the program I get this error like you are getting, and another error right before... Two errors read: "The instruction at "0x7c910ed4" referenced memory at "0xffffffff". The memory could not be "read"."

Then I get this error after I click ok on the first error:

"The instruction at "0x7c9113a0" referenced memory at "0xffffffff". The memory could not be "read"."

I believe the problem started arising around the time I upgraded to Service Pack 3 for XP. Ironically SP3 also broke the Remote Desktop feature, a great program now not able to run at all. Nice Service Pack, Microshit.

As for debugging, that's not my best subject as it is, but debugging a closed program well you got me there I do not have a clue how to do that.

Answer 6

PERHAPS THIS (IN MY TOTAL IGNORANCE) CAN SHED SOME ADDITIONAL LIGHT FOR YOU ALL - BEGAN AFTER MOST RECENT M'SOFT MONTHLY UPDATES - RUNNING WINXP SP3 - I SEEM TO GET THIS ERROR (BELOW) ON JUST ABOUT ALL APPLICATION CLOSINGS:

WINDOC.EXE - Application Error The instruction "Ox7c9113aO" referenced memory at "0x00000000". The memory could not be "written". Click OK to terminate the program.

LuComServer_3_4.EXE - Application Error The instruction "Ox7c9113aO" referenced memory at "0x00000000". The memory could not be "written". Click OK to terminate the program.

ALSO SAME FOR NAVW32.exe Application Error AND MANY OTHERS???

Answer 7

try this to force the bug to happen while under program control

   //set as many statics as you can to null;
   GC.Collect();
   GC.WaitForPendingFinalizers();
} //exit main

Answer 8

The error stopped appearing after using the suggested code:

GC.Collect(); GC.WaitForPendingFinalizers();

Answer 9

I had this problem using AcrobarReader COM component. Every now and then after application exit I had "Application.vshost.exe - Application Error" "memory could not be read". GC.Collect() and WaitForPendingFinalizers() didn't help.

My google-fu lead me to this page: http://support.microsoft.com/kb/826220. I modified method 3 fo my case.

Using process explorer I found that my AcroPDF.dll is not released before last line in Main function. So, here come the API calls.

DLLImports (DLLImport is in System.Runtime.InteropServices namespace):

<DllImport("kernel32.dll", EntryPoint:="GetModuleHandle", _
       SetLastError:=True, CharSet:=CharSet.Auto, _
       CallingConvention:=CallingConvention.StdCall)> _
Public Overloads Shared Function GetModuleHandle(ByVal sLibName As String) As IntPtr
End Function

<DllImport("kernel32.dll", EntryPoint:="FreeLibrary", _
    SetLastError:=True, CallingConvention:=CallingConvention.StdCall)> _
Public Overloads Shared Function FreeLibrary(ByVal hMod As IntPtr) As Integer
End Function

And then before application exit:

Dim hOwcHandle As IntPtr = GetModuleHandle("AcroPDF.dll")
If Not hOwcHandle.Equals(IntPtr.Zero) Then
    FreeLibrary(hOwcHandle)
    Debug.WriteLine("AcroPDF.dll freed")
End If

This procedure can be modified for any other ill-behaved dll. I just hope it doesn't introduce any new bugs.