Develop Reference

How to see friendly .NET call stacks?

I got a memory dump. I can get the normal callstack (with line number)
When I use Debug Diag to analyze the dump I got this callstack on thread 62.
.NET Call Stack
[[HelperMethodFrame_1OBJ] (System.Threading.WaitHandle.WaitOneNative)] System.Threading.WaitHandle.WaitOneNative(System.Runtime.InteropServices.SafeHandle, UInt32, Boolean, Boolean)
mscorlib_ni!System.Threading.WaitHandle.InternalWaitOne(System.Runtime.InteropServices.SafeHandle, Int64, Boolean, Boolean)+21
mscorlib_ni!System.Threading.WaitHandle.WaitOne(Int32, Boolean)+31
CaptureServices.GenericInfrastructure.ExportLogic.ChannelsThread.ChannelsStateThread()+bb
mscorlib_ni!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)+15e
mscorlib_ni!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)+17
mscorlib_ni!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)+52
mscorlib_ni!System.Threading.ThreadHelper.ThreadStart()+52
[[GCFrame]]
[[DebuggerU2MCatchHandlerFrame]]
As I understand .NET has some mechanism to shows human readable names instead of adresses. Now I want this line in WinDbg:
CaptureUtilities.AudioProcessing.APProcessorThread.IterateAPStreamProcessorQueue()+49
I open WinDbg and load the dump. I execute ~62 k and get
Child-SP RetAddr Call Site
00000016`4965e0c8 00007ffc`b59113ed ntdll!NtWaitForMultipleObjects+0xa
00000016`4965e0d0 00007ffc`abde77be KERNELBASE!WaitForMultipleObjectsEx+0xe1
00000016`4965e3b0 00007ffc`abde7658 clr!WaitForMultipleObjectsEx_SO_TOLERANT+0x62
00000016`4965e410 00007ffc`abde7451 clr!Thread::DoAppropriateWaitWorker+0x1e4
00000016`4965e510 00007ffc`abdebd15 clr!Thread::DoAppropriateWait+0x7d
00000016`4965e590 00007ffc`a94ecdf1 clr!WaitHandleNative::CorWaitOneNative+0x165
00000016`4965e7c0 00007ffc`a94ecdc1 mscorlib_ni+0x48cdf1
00000016`4965e7f0 00007ffc`4cf2e97b mscorlib_ni+0x48cdc1
00000016`4965e830 00007ffc`a94e674e 0x00007ffc`4cf2e97b
00000016`4965e890 00007ffc`a94e65e7 mscorlib_ni+0x48674e
00000016`4965e960 00007ffc`a94e65a2 mscorlib_ni+0x4865e7
00000016`4965e990 00007ffc`a94ed1f2 mscorlib_ni+0x4865a2
00000016`4965e9e0 00007ffc`abc36a53 mscorlib_ni+0x48d1f2
00000016`4965ea20 00007ffc`abc36913 clr!CallDescrWorkerInternal+0x83
Ok, as I understand it is the same. Now we have
0x00007ffc`4cf2e97b
instead of
CaptureServices.GenericInfrastructure.ExportLogic.ChannelsThread.ChannelsStateThread()+bb
So I have Microsoft debug symbols, now I need to load my own symbols to see the callstack.
The question is - do I need to load all debug symbols for my projects or I need only debug symbols for dll which contains CaptureServices.GenericInfrastructure.ExportLogic?
Or maybe I need to load only part of my debug symbols to handle this thread?

Try !sosex.mk. It gives a user-friendly stack trace with interleaved managed and native frames. I do not believe that this is a symbol issue. Also, when you have a managed address, you can pass it to !sosex.mln to see what's located there, but I think you're already aware of this command.

The k command as in ~62k is a command for the native call stack. It does dot show any .NET stuff (except the native methods in clr.dll).
To see the .NET stack, you need to load the .NET extension for WinDbg:
.loadby sos clr
And then use a command of that extension to see the .NET call stack. Switch to thread 62 first
~62s
!clrstack
!dumpstack
IMHO those commands will load symbols from PDBs when needed. If you get symbol warnings, see How to fix symbols in WinDbg

You need the debug symbols of whatever library that function belongs to.

Examining a managed exception in an unmanaged thread

I'm looking into a mini-dump file where the main thread (c++) utilized CLR to launch a managed (C#.NET) window, an exception was thrown in the managed portion, and crashed the application. I've been searching around looking at techniques to examine an exception details for clues, however they're mainly for one or the other (an entirely unmanaged stack & thread or an entirely managed stack & thread).
The portion of the managed callstack is below, where I can see an exception was raised inside the .NET portion, but I'm not really sure of a method to digging into viewing the details of what was raised. I'm still fairly new at digging through a .dmp file, so any guidance is greatly appreciated.
001ddb04 68b92a42 KERNELBASE!RaiseException+0x58
001ddba8 68c655ef clr!RaiseTheExceptionInternalOnly+0x276
001ddbd8 68c6de52 clr!UnwindAndContinueRethrowHelperAfterCatch+0x83
001ddc6c 627528df clr!CEEInfo::resolveToken+0x59b
001ddc7c 62778872 clrjit!Compiler::impResolveToken+0x3a
001de3ac 62751d53 clrjit!Compiler::impImportBlockCode+0x29b3
001de42c 62751f48 clrjit!Compiler::impImportBlock+0x5f
001de444 62753405 clrjit!Compiler::impImport+0x235
001de464 62753635 clrjit!Compiler::compCompile+0x63
001de4a0 62753823 clrjit!Compiler::compCompileHelper+0x2fa
001de518 627536f6 clrjit!Compiler::compCompile+0x213
001de608 6275385f clrjit!jitNativeCode+0x1e3
001de62c 68a74710 clrjit!CILJit::compileMethod+0x25
001de67c 68a747a9 clr!invokeCompileMethodHelper+0x41
001de6bc 68a747eb clr!invokeCompileMethod+0x31
001de720 68a73684 clr!CallCompileMethodWithSEHWrapper+0x2a
001deab8 68a73920 clr!UnsafeJitFunction+0x3ca
001deb94 68a81e5e clr!MethodDesc::MakeJitWorker+0x36b
001dec08 68a550b6 clr!MethodDesc::DoPrestub+0x59d
001dec70 68a44279 clr!PreStubWorker+0xed
001deca0 16c5185a clr!ThePreStub+0x16
001deda4 5ae8f887 0x16c5185a
001dedc0 5ae20c9c MYDLL!CLoader::InvokeCSharpControl

0x16c5185a is an address in memory where the .NET code has been compiled by the JIT compiler. Due to the just-in-time compilation, there's no symbol like in C++ and you need different tools (extensions for WinDbg).
First, check if it's a .NET exception with .exr -1. Except for a few exceptions, the code should be 0xE0434F4D (.COM in ASCII characters).
If that's the case, load the SOS extension to analyze the .NET details: .loadby sos clr. Next, run the command !PrintException (!pe in short) to get details about the exception and !ClrStack (casing is not relevant) to get details about the .NET call stack.
There may be more details available if you have a good crash dump for .NET.

Trouble displaying C# stack trace in WinDbg

I have a handle leak in a C# program. I'm trying to diagnose it using WinDbg using !htrace, roughly as presented in this answer, but when I run !htrace -diff in WinDbg I'm presented with stack traces that don't show the names of my C# functions (or even my .net assembly).
I created a small test program to illustrate my difficulty. This program does nothing except "leak" handles.
class Program
{
static List<Semaphore> handles = new List<Semaphore>();
static void Main(string[] args)
{
while (true)
{
Fun1();
Thread.Sleep(100);
}
}
static void Fun1()
{
handles.Add(new Semaphore(0, 10));
}
}
I compiled the assembly, and then in WinDbg I go "File" -> "Open Executable" and select my program (D:\Projects\Sandpit\bin\Debug\Sandpit.exe). I continue program execution, break it, and run "!htrace -enable", then continue for a bit longer, and then break and run "!htrace -diff". This is what I get:
0:004> !htrace -enable
Handle tracing enabled.
Handle tracing information snapshot successfully taken.
0:004> g
(1bd4.1c80): Break instruction exception - code 80000003 (first chance)
eax=7ffda000 ebx=00000000 ecx=00000000 edx=77b2f17d esi=00000000 edi=00000000
eip=77ac410c esp=0403fc20 ebp=0403fc4c iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!DbgBreakPoint:
77ac410c cc int 3
0:004> !htrace -diff
Handle tracing information snapshot successfully taken.
0xd new stack traces since the previous snapshot.
Ignoring handles that were already closed...
Outstanding handles opened since the previous snapshot:
--------------------------------------
Handle = 0x00000250 - OPEN
Thread ID = 0x00001b58, Process ID = 0x00001bd4
0x77ad5704: ntdll!ZwCreateSemaphore+0x0000000c
0x75dcdcf9: KERNELBASE!CreateSemaphoreExW+0x0000005e
0x75f5e359: KERNEL32!CreateSemaphoreW+0x0000001d
*** WARNING: Unable to verify checksum for C:\Windows\assembly\NativeImages_v4.0.30319_32\System\13c079cdc1f4f4cb2f8f1b66c8642faa\System.ni.dll
0x65d7e805: System_ni+0x0020e805
0x65d47843: System_ni+0x001d7843
0x65d477ef: System_ni+0x001d77ef
0x004700c9: +0x004700c9
0x67d73dd2: clr!CallDescrWorkerInternal+0x00000034
0x67d9cf6d: clr!CallDescrWorkerWithHandler+0x0000006b
0x67d9d267: clr!MethodDescCallSite::CallTargetWorker+0x00000152
0x67eb10e0: clr!RunMain+0x000001aa
0x67eb1200: clr!Assembly::ExecuteMainMethod+0x00000124
--------------------------------------
Handle = 0x0000024c - OPEN
Thread ID = 0x00001b58, Process ID = 0x00001bd4
0x77ad5704: ntdll!ZwCreateSemaphore+0x0000000c
0x75dcdcf9: KERNELBASE!CreateSemaphoreExW+0x0000005e
0x75f5e359: KERNEL32!CreateSemaphoreW+0x0000001d
0x65d7e805: System_ni+0x0020e805
0x65d47843: System_ni+0x001d7843
0x65d477ef: System_ni+0x001d77ef
0x004700c9: +0x004700c9
0x67d73dd2: clr!CallDescrWorkerInternal+0x00000034
0x67d9cf6d: clr!CallDescrWorkerWithHandler+0x0000006b
0x67d9d267: clr!MethodDescCallSite::CallTargetWorker+0x00000152
0x67eb10e0: clr!RunMain+0x000001aa
0x67eb1200: clr!Assembly::ExecuteMainMethod+0x00000124
...
--------------------------------------
Displayed 0xd stack traces for outstanding handles opened since the previous snapshot.
As you can see, the stack trace is missing my C# function names "Main" and "Fun1". I believe "System_ni+0x..." frames may be my function frames, but I don't know. My question is, how do I get WinDbg to display function names for my C# functions in the stack trace?
Extra information:
My WinDbg symbol search path is
SRVC:/symbolshttp://msdl.microsoft.com/download/symbols;D:\Projects\Sandpit\bin\Debug;srv*
I don't get any errors when I open the executable in WinDbg. There is a file called "Sandpit.pdb" in the output directory ("D:\Projects\Sandpit\bin\Debug"). The project is built locally so the pdb file should match the exe. I downloaded WinDbg from here. I have "Enable native code debugging" checked in the project settings in Visual Studio.

WinDbg attempts to interpret the native call stack as best it can, however to fully interpret the stack of a CLR application WinDbg needs to use an extension called SOS. This extension has a separate command CLRStack for viewing the stack information of CLR stacks. You will need to load the SOS extension first however using the .loadby sos clr command (or similar, I remember getting the correct version SOS to load could be a bit of a pain)
For more information see
WinDbg 101–A step by step guide to finding a simple memory leak in your .Net application
WinDbg / SOS Cheat Sheet

.NET Activex control access violation in MFC application

Background: I developed an Activex control in .NET, but found it was causing stability issues in various applications that used it. I managed to find a series of steps, from sample applications, similar unstabilities outlined below.
I have a sample Activex control that I've downloaded from the Dev-Center website called 'CSActivex' (http://code.msdn.microsoft.com/windowsdesktop/CSActiveX-b86194f8)
It was fairly easy to build, I just loaded the project up in VS2010 Express (C#) and it compiled into a .dll
I then created a sample MFC application from VS2008 C++ to model a legacy applications (it does not use any .NET). The target is the simple dialog based GUI that has an About box.
I registered the csactivex.dll with regasm and just copied the dll to the VS IDE folder, so I can insert the Activex control at design time, and then to the Debug folder, so it can be found during runtime.
At design time, I insert the CSActivex control onto the About dialog box, it appears with no surprises. After building and copying the dll to the Debug folder and run a debug session, if I continually navigate to the about box, click in various places on the control, close the about dialog and repeat a few times, I start to see messages in the output log about access violations, and it starts to look like this:
'CSActivexMFC.exe': Loaded 'C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\System.Windows.Forms\63406259e94d5c0ff5b79401dfe113ce\System.Windows.Forms.ni.dll'
'CSActivexMFC.exe': Loaded 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorjit.dll'
'CSActivexMFC.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.GdiPlus_6595b64144ccf1df_1.0.2600.5581_x-ww_dfbc4fc4\GdiPlus.dll'
'CSActivexMFC.exe': Loaded 'C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\Accessibility\11eb4f6606ba01e5128805759121ea6c\Accessibility.ni.dll'
First-chance exception at 0x00000000 in CSActivexMFC.exe: 0xC0000005: Access violation reading location 0x00000000.
First-chance exception at 0x00000000 in CSActivexMFC.exe: 0xC0000005: Access violation reading location 0x00000000.
First-chance exception at 0x79f4c2f7 in CSActivexMFC.exe: 0xC0000005: Access violation reading location 0x0000000b.
First-chance exception at 0x79f4c2f7 in CSActivexMFC.exe: 0xC0000005: Access violation reading location 0x0000000b.
While it does not crash in the debugger, I can't help but think this in not good, and I have a feeling that it may be related to the instability of other .NET Activex controls. If I can figure out a way to solve this issue, the same resolution may help the original control.
I tried breaking on the exception, but it appears to happen in a few different places. one stack trace when I closed the applications is below:
mscorwks.dll!79f4c2f7() [Frames below may be incorrect and/or
missing, no symbols loaded for mscorwks.dll]
mscorwks.dll!79f4c370() mscorwks.dll!79faaa91()
mscorwks.dll!79faa858() mscorwks.dll!79faa9ad()
mscorwks.dll!79faa9d9() mscorwks.dll!7a079480()
mscorwks.dll!7a0798e8() mscorwks.dll!7a043f25()
ole32.dll!77525834() rpcrt4.dll!77e799f4()
rpcrt4.dll!77ef421a() ntdll.dll!7c915239()
ntdll.dll!7c91542b() ntdll.dll!7c91534a()
ntdll.dll!7c915239() ntdll.dll!7c91542b()
ntdll.dll!7c91534a() ntdll.dll!7c915f75()
ntdll.dll!7c9155ed() ntdll.dll!7c915ce9()
ntdll.dll!7c96f07c() ole32.dll!77600c15()
ole32.dll!77600bbf() ole32.dll!7752ad31()
ole32.dll!7752ac56() ole32.dll!7752b771()
ole32.dll!77600e1f() ole32.dll!7752b7ab()
ole32.dll!7752b5e1() ole32.dll!7752b54e()
user32.dll!7e418734() ole32.dll!7752b54e()
ole32.dll!7752b54e() ole32.dll!7752b54e()
ole32.dll!7752b54e() ole32.dll!7752f2d0()
ole32.dll!7752f23e() ole32.dll!77557237()
mscorwks.dll!79f9e14d() mscorwks.dll!79f9e0b4()
mscorwks.dll!79f9e018() mscorwks.dll!79f4c879()
mscorwks.dll!79f3bb76() mscoreei.dll!603cc966()
mscoreei.dll!603d1f25() mscoree.dll!790186ad()
msvcr90d.dll!_crtCorExitProcess(int status=2) Line 716 C msvcr90d.dll!_crtExitProcess(int status=2) Line 722 + 0x9 bytes C
msvcr90d.dll!doexit(int code=2, int quick=0, int retcaller=0) Line
644 + 0x9 bytes C msvcr90d.dll!exit(int code=2) Line 412 + 0xd
bytes C CSActivexMFC.exe!__tmainCRTStartup() Line 595 C
CSActivexMFC.exe!wWinMainCRTStartup() Line 399 C
kernel32.dll!7c817077()
I was hoping someone may have run into this before, I'm running into this on mulitple machines (home and at work) and at least have it narrowed down to either a problem with CSActivex not doing something it should, or something in MFC.
so my question is how to get these samples working without the access violations?
Edit:
Just opening the about window and closing it repeatedly eventually results in a crash in the debugger (unhandled exception) with a stack trace below, to me it looks like an object that was destructed is being destroyed again?
First-chance exception at 0x00400003 in CSActivexMFC.exe: 0xC0000005: Access violation writing location 0x00000000.
First-chance exception at 0x00400003 in CSActivexMFC.exe: 0xC0000005: Access violation writing location 0x00000000.
First-chance exception at 0x003a005c in CSActivexMFC.exe: 0xC0000096: Privileged instruction.
First-chance exception at 0x00460020 in CSActivexMFC.exe: 0xC0000005: Access violation reading location 0x00460020.
First-chance exception at 0x78b6ba1d (mfc90ud.dll) in CSActivexMFC.exe: 0xC0000005: Access violation writing location 0x00000018.
Unhandled exception at 0x78b6ba1d (mfc90ud.dll) in CSActivexMFC.exe: 0xC0000005: Access violation writing location 0x00000018.
mfc90ud.dll!CDataSourceControl::~CDataSourceControl() Line 2431 + 0x2d bytes C++
mfc90ud.dll!CDataSourceControl::`scalar deleting destructor'() + 0x11 bytes C++
mfc90ud.dll!COleControlSite::~COleControlSite() Line 77 + 0x22 bytes C++
mfc90ud.dll!COleControlSite::`scalar deleting destructor'() + 0x11 bytes C++
mfc90ud.dll!COleControlSiteOrWnd::~COleControlSiteOrWnd() Line 161 + 0x24 bytes C++
mfc90ud.dll!COleControlSiteOrWnd::`scalar deleting destructor'() + 0x11 bytes C++
mfc90ud.dll!COleControlContainer::~COleControlContainer() Line 199 + 0x1c bytes C++
mfc90ud.dll!COleControlContainer::`scalar deleting destructor'() + 0x11 bytes C++
mfc90ud.dll!CWnd::OnDestroy() Line 786 + 0x24 bytes C++
mfc90ud.dll!CWnd::OnWndMsg(unsigned int message=2, unsigned int wParam=0, long lParam=0, long * pResult=0x0012f510) Line 2042 C++
mfc90ud.dll!CWnd::WindowProc(unsigned int message=2, unsigned int wParam=0, long lParam=0) Line 1755 + 0x20 bytes C++
mfc90ud.dll!AfxCallWndProc(CWnd * pWnd=0x0012f88c, HWND__ * hWnd=0x002c04fc, unsigned int nMsg=2, unsigned int wParam=0, long lParam=0) Line 240 + 0x1c bytes C++
mfc90ud.dll!AfxWndProc(HWND__ * hWnd=0x002c04fc, unsigned int nMsg=2, unsigned int wParam=0, long lParam=0) Line 403 C++
mfc90ud.dll!AfxWndProcBase(HWND__ * hWnd=0x002c04fc, unsigned int nMsg=2, unsigned int wParam=0, long lParam=0) Line 441 + 0x15 bytes C++
user32.dll!7e418734()
[Frames below may be incorrect and/or missing, no symbols loaded for user32.dll]
user32.dll!7e418816()
mfc90ud.dll!CThreadSlotData::GetThreadValue(int nSlot=6623744) Line 268 C++
user32.dll!7e428eec()
ntdll.dll!7c90e473()
user32.dll!7e42b1a8()
mfc90ud.dll!CWnd::DestroyWindow() Line 1007 + 0xd bytes C++
90909090()

Take a look at this MSDN Blog by David Kline on What is a First Chance Exception.
From Blog
Does a first chance exception mean there is a problem in my code?
First chance exception messages most often do not mean there is a problem in the code. For applications / components which handle exceptions gracefully, first chance exception messages let the developer know that an exceptional situation was encountered and was handled.
For code without exception handling, the debugger will receive a second chance exception notification and will stop with a unhandled exception.
And by looking at another MSDN Blog by David Kline it will tell you how to Stop on a First Chance Exception to see what caused it.
And this MSDN Forum Posting

Application that uses WebBrowser control crashes after installing IE9

I've installed IE 9 last week and since, my c# .net application crashes about 20% of times. The debugger is unable to show something useful besides stopping at Program.cs Application.Run(new MyMainForm()); , btw the main form was already shown, so it's not that it's something in construction on main form.
I have Windows7.
The exception thrown is:
"An unhandled exception of type 'System.ArgumentException' occurred in System.Windows.Forms.dll
Additional information: Value does not fall within the expected range.
Screen shot of callstack -> http://img861.imageshack.us/f/ie9v.png/
When running outside of debugger, this info is shown:
Problem signature:
Problem Event Name: APPCRASH
Application Name: myexe.exe
Application Version: 6.7.6.0
Application Timestamp: 4d7fdffd
Fault Module Name: mshtml.dll
Fault Module Version: 9.0.8112.16421
Fault Module Timestamp: 4d76266c
Exception Code: c0000005
Exception Offset: 0012c848
OS Version: 6.1.7600.2.0.0.256.48
Locale ID: 1037
And sometimes instead of mshtml.dll it says StackHash_f09d
Problem Event Name: APPCRASH
Application Name: myexe.exe
Application Version: 6.7.6.0
Application Timestamp: 4d7fdffd
Fault Module Name: StackHash_f09d
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Code: c0000005
Exception Offset: 00000000
OS Version: 6.1.7600.2.0.0.256.48
Locale ID: 1037
Thanks in advance
Edited:
That's what I see in windbg, with symbols:
0:000> kb
ChildEBP RetAddr Args to Child
0020eda4 64d54f83 0566c988 00001012 00000000 mshtml!CDoc::ReduceMemoryPressureTask+0x1a
0020edb4 64d54f2c c6b991e4 0020ee78 00000113 mshtml!GWYieldToMsgOnCurrentThread+0x17b
0020edfc 770086ef 00192392 00000012 0000201b mshtml!GlobalWndProc+0x1f2
0020ee28 77008876 64d54afe 00192392 00000113 USER32!InternalCallWinProc+0x23
0020eea0 770089b5 00000000 64d54afe 00192392 USER32!UserCallWinProcCheckWow+0x14b
0020ef00 77008e9c 64d54afe 00000000 0020ef2c USER32!DispatchMessageWorker+0x35e
0020ef10 03b54726 0020ef9c fa69a961 00000000 USER32!DispatchMessageW+0xf
*** WARNING: Unable to verify checksum for C:\Windows\assembly\NativeImages_v2.0.50727_32\System.Windows.Forms\f92c882fd4e7005c005e208daa04c28d\System.Windows.Forms.ni.dll
WARNING: Frame IP not in any known module. Following frames may be wrong.
0020ef2c 5af78aee 01b743e4 00000001 01ac95cc 0x3b54726
0020efe0 5af78757 00000000 ffffffff 00000000 System_Windows_Forms_ni+0x208aee
0020f038 5af785a1 01b6c610 1f3a000e 00000000 System_Windows_Forms_ni+0x208757
0020f068 5af35911 01bb7d84 0020f10c 003b73d8 System_Windows_Forms_ni+0x2085a1
0020f0e0 6f221b5c 015b1141 00000001 0020f170 System_Windows_Forms_ni+0x1c5911
0020f0f0 6f232209 0020f1c0 00000000 0020f190 mscorwks!CallDescrWorker+0x33
0020f170 6f246511 0020f1c0 00000000 0020f190 mscorwks!CallDescrWorkerWithHandler+0xa3
0020f2b4 6f246544 0032c040 0020f380 0020f34c mscorwks!MethodDesc::CallDescr+0x19c
0020f2d0 6f246562 0032c040 0020f380 0020f34c mscorwks!MethodDesc::CallTargetWorker+0x1f
0020f2e8 6f2b0c45 0020f34c d847bc11 00000000 mscorwks!MethodDescCallSite::CallWithValueTypes+0x1a
0020f44c 6f2b0b65 003239c0 00000001 0020f488 mscorwks!ClassLoader::RunMain+0x223
0020f6b4 6f2b10b5 00000000 d847b3d9 00000001 mscorwks!Assembly::ExecuteMainMethod+0xa6
0020fb84 6f2b129f 013a0000 00000000 d847b389 mscorwks!SystemDomain::ExecuteMainMethod+0x456
=====UPDATE(I'm not sure, if I'm supposed to post it as "Answer your question")============
Thanks to everyone trying to help, I appreciate it.
Being desperate, I started to remove pieces of code to understand which part of my code affects it(we use webrowser control in many forms). After removing call to LoginForm which also uses webrowser control, the problem disappeared.
The login form hosts webrowser control, it navigates to certain url, for example /login.php and if user is already logged-in, method UserLoggedIn inside form is invoked from html using ObjectForScripting. When UserLoggedIn was called, we were calling Close() to close form if the LoginForm was shown. Even though LoginForm was doing all this, we weren't always showing it. We were, showing it only if after X seconds UserLoggedIn() was not called(i.e user needs to login).
For some reason, and thanks to MS for making us able to debug into .net sources, when we were calling Close, and the form was not Visible it was actually disposing the form and all it's children because IsHandleCreated was false. Now, the Close was called from UserLoggedIn(), which is an event fired by the browser control(the callstack shows ieframe.dll, mshtml.dll etc) , so the webbrowser object was being destoyed while being called from.
The hacky way to resolve this, was to call Close, only if form was Visible. BTW, I don't know, why IsHandleCreated is false, if we don't show the form. I tried to reproduce it, by writing a sample that creates a form, which is not shown, but it's IsHandleCreated is true.
---- from Forms.cs -----
public void Close()
{
if (GetState(STATE_CREATINGHANDLE))
throw new InvalidOperationException(SR.GetString(SR.ClosingWhileCreatingHandle, "Close"));
if (IsHandleCreated) {
closeReason = CloseReason.UserClosing;
SendMessage(NativeMethods.WM_CLOSE, 0, 0);
}
else{
// MSDN: When a form is closed, all resources created within the object are closed and the form is disposed.
// For MDI child: MdiChildren collection gets updated (VSWhidbey# 368642 & 93550)
Dispose(); // THIS WAS CALLED WHEN FORM WAS NOT VISIBLE
}
}

Educated speculation to get you started- timers use thread pool threads, which are MTA. If I had to guess I'd say that it could be related to that, since activex controls can only be safely instantiated from STA threads. Perhaps try creating a thread manually rather than using the timer thread?

browser.Navigate("xxx") is called from timer
What kind of timer are you using? If the timer fire callback happens on another thread, and you are calling methods on the browser object, then you are opening yourself up random crash likelyhood. Try setting Control.CheckForIllegalCrossThreadCalls = true; in your Main() method beofre running the Application.Run(...) method and see if when it crashes, you get a more "on point" error message or the same.

This crash happens when jscript.dll is incorrectly registered. The ReduceMemoryPressureTask method expects it to be loaded and causes a null dereference otherwise. A fix is to run regsvr32 jscript.dll on the affected machine. You can check for the error by looking at the loaded module list to see if jscript.dll is missing or not. This can be done either programatically or through Process Explorer.

The exception code c0000005 usually means that is a memory problem. Maybe it has to do with 32 and 64 bits areas of your application getting confused.
I would try to make your app run fully in 64, then fully 32, see what happens.
Try running as admin, see if that changes anything.
Also you should put try catches on the points where it makes sense, and rety whenever the error is found.
Well those are suggestions, so try it out and see if you can get us more info.
Good Luck!

There might be a reason, since the WinForms runs under STA , but the web browser requires MTA. Put a try-catch above the browser control and also check if there is r/w access voilation. As stated by oakcool

I've run in to problems with this, mostly due to privilege violations.
The program was running at administrator level and the browser was running at user level, or visa-versa.
Something to look into

i get the same error/crash since i got the ie9 installed. it only happens whenever there is a youtube movie on the page. than it hangs/crashes with the exact same window you get Jack Juiceson.
but behind the "Fault Module Name" i dont get mshtml.dll, i get a d3d9.dll or something like that. veryyyyy odd.