Debugging winform crash - C# [ADPlus + Windbg]

Question

 System.AccessViolationException was unhandled
  Message=Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
  Source=System.Windows.Forms
  StackTrace:
       at System.Windows.Forms.UnsafeNativeMethods.PeekMessage(MSG& msg, HandleRef hwnd, Int32 msgMin, Int32 msgMax, Int32 remove)
       at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
       at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
       at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
       at System.Windows.Forms.Application.Run(Form mainForm)
       at ABC.Program.Main() in C:\Documents and Settings\...\Program.cs:line 17
  InnerException: 

This, hard to reproduce exception, is very unpredictable. I attached my visual studio debugger and ran the test 7-10 times and was able to successfully capture this stack trace. Notice that none of this is my code, so something spooky happening at windows level. BTW we use PInvoke to open / close windows like iexplore, notepad etc.

After some - search - and based upon the advice give by that guy from Microsoft I tried ADPlus to get the memory dump & Windbg to analyse, but the information I get from the windbg is even more cryptic than the exception itself.

This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(904.1cf4): Access violation - code c0000005 (first/second chance not available)
eax=003c4d10 ebx=00000000 ecx=00000000 edx=00000000 esi=003c4d2a edi=0012f1a0
eip=003c4b64 esp=0012f11c ebp=0012f138 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246
003c4b64 8b410c          mov     eax,dword ptr [ecx+0Ch] ds:0023:0000000c=????????
0:000> .ecxr
eax=003c4d10 ebx=00000000 ecx=00000000 edx=00000000 esi=003c4d2a edi=0012f1a0
eip=003c4b64 esp=0012f11c ebp=0012f138 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246
003c4b64 8b410c          mov     eax,dword ptr [ecx+0Ch] ds:0023:0000000c=????????

There can be some experts which can make sence of this information, I cannot.

So, what do you guys do to analyse thse kind of problems? Anything like a "heap dump analyser for JVM" for .Net ?

Environment: Windows XP SP3 [full access, admin]

Answer 1

In Visual Studio, go to project properties and enable "unmanaged code degubbing" then start the debugger.

[not sure if below step is required but I just did it] execute .load SOS.dll in Immediate Window of visual studio

I was able find the root cause of the problem: A callback was made on a garbage collected delegate of type 'ABC.Form1+SendMessageDelegate::Invoke'. This may cause application crashes, corruption and data loss. When passing delegates to unmanaged code, they must be kept alive by the managed application until it is guaranteed that they will never be called.

Thanks everyone who posted a reply or comments.