Exceptions Thrown (Errors Encountered) After Program Termination

Question

I have an application that seems to throw exceptions only after the program has been closed. And it is very inconsistent. (We all know how fun inconsistent bugs are...)

My guess is there is an error during the clean up process. But these memory read/write errors seem to indicate something wrong in my "unsafe" code usage (pointers?).

What I am interested in is what is the best method to debug these situations?
How do you debug a program that has already closed?
I am looking for a starting point to break down a larger problem.

These errors seem to present themselves in several ways (some run time, some debug):

1: .NET-BroadcastEventWindow.2.0.0.0.378734a.0:  Application.exe - Application Error

The instruction at "0x03b4eddb" referenced memory at "0x00000004". The memory could not be "written".

2:  Application.vshost.exe - Application Error

The instruction at "0x0450eddb" referenced memory at "0x00000004". The memory could not be "written".

3:  Application.vshost.exe - Application Error

The instruction at "0x7c911669" referenced memory at "0x00000000". The memory could not be "read".

4:  Application.vshost.exe - Application Error

The instruction at "0x7c910ed4" referenced memory at "0xfffffff8". The memory could not be "read".

Answer 1

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 for my case.

Using process explorer I found that AcroPDF.dll is not released before the last line in the 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.

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.