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.

Access Violation Exception in SqlCeConnection dispose

Application/Code description:
My application is based on c# and uses SQL Server CE and iv'e got this exception only twice at the same code location. the crash with this exception was not introduced till this version. the only change in this version was changing the .net framework to 4.5.2.
I'm getting access violation exception on the dispose of an SqlCeConnection with the following error:
Attempted to read or write protected memory. This is often an
indication that other memory is corrupt.
This exception is not intercepted by the try catch clause of .net- it causes a crash.
In my code I use the following to run
try
{
var connectionString = string.Format("{0}{1}{2}", "Data Source=", _localDB, ";File Mode=Read Write;Max Database Size=4000;Persist Security Info=False;");
using (var sqlCeConnection = new SqlCeConnection(connectionString))
{
using (var sqlCeCommand = new SqlCeCommand())
{
sqlCeCommand.Connection = sqlCeConnection;
sqlCeCommand.CommandText = "SELECT * FROM Application";
sqlCeConnection.Open();
var result = (string)sqlCeCommand.ExecuteScalar();
isValid = !IsValid(result);
}
}
}
catch (Exception ex)
{
_log.Error("exception", ex);
}
call stack for the first crash:
ntdll!ZwWaitForMultipleObjects+a
KERNELBASE!WaitForMultipleObjectsEx+e8
kernel32!WaitForMultipleObjectsExImplementation+b3
kernel32!WerpReportFaultInternal+215
kernel32!WerpReportFault+77
kernel32!BasepReportFault+1f
kernel32!UnhandledExceptionFilter+1fc
ntdll! ?? ::FNODOBFM::`string'+2365
ntdll!_C_specific_handler+8c
ntdll!RtlpExecuteHandlerForException+d
ntdll!RtlDispatchException+45a
ntdll!KiUserExceptionDispatcher+2e
sqlcese35!__SafeRelease+c
sqlcese35!Column::`vector deleting destructor'+5c
sqlcese35!Object::DeleteObjects+39
sqlcese35!Table::`vector deleting destructor'+45
sqlcese35!Table::Release+27
sqlcese35!HashTable::~HashTable+2a
sqlcese35!Store::~Store+12b
sqlcese35!Store::Release+2a
sqlceme35!ME_SafeRelease+17
DomainBoundILStubClass.IL_STUB_PInvoke(IntPtr ByRef)+78
[[InlinedCallFrame] (System.Data.SqlServerCe.NativeMethods.SafeRelease)] System.Data.SqlServerCe.NativeMethods.SafeRelease(IntPtrByRef)
System.Data.SqlServerCe.SqlCeConnection.ReleaseNativeInterfaces()+147
System.Data.SqlServerCe.SqlCeConnection.Dispose(Boolean)+f1
System_ni!System.ComponentModel.Component.Dispose()+18
call stack for the second crash:
ntdll!NtWaitForMultipleObjects+a
KERNELBASE!WaitForMultipleObjectsEx+e8
kernel32!WaitForMultipleObjectsExImplementation+b3
kernel32!WerpReportFaultInternal+215
kernel32!WerpReportFault+77
kernel32!BasepReportFault+1f
kernel32!UnhandledExceptionFilter+1fc
ntdll! ?? ::FNODOBFM::`string'+2335
ntdll!_C_specific_handler+8c
ntdll!RtlpExecuteHandlerForException+d
ntdll!RtlDispatchException+45a
ntdll!KiUserExceptionDispatcher+2e
<Unloaded_sqlcese35.dll>+7c88c
<Unloaded_sqlceqp35.dll>+102790
0x06ccc898
0x06f9efc8
0x1eca8018
0x1f207400
<Unloaded_sqlcese35.dll>+228dc
0x00000004
0x2edff008
0x00000002
0x00000003
0x00000004
<Unloaded_sqlcese35.dll>+3fbd9
0x06ccc898
DomainBoundILStubClass.IL_STUB_PInvoke(IntPtr ByRef)+78
[[InlinedCallFrame] (System.Data.SqlServerCe.NativeMethods.SafeRelease)] System.Data.SqlServerCe.NativeMethods.SafeRelease(IntPtrByRef)
System.Data.SqlServerCe.SqlCeConnection.ReleaseNativeInterfaces()+147
System.Data.SqlServerCe.SqlCeConnection.Dispose(Boolean)+f1
System_ni!System.ComponentModel.Component.Dispose()+1b
I found some references on the internet that suggests some solutions:
Probable solution: check multithreading issue on the same connection (attempted to read write protected memory. this is often an indication that other memory is corrupt)
Rejection:
a. the connection is created in the using brackets and doesn't get reused.
b. the calling method is called every 5 minutes and verified via the dump file that it was not called simultaneously.
Probable solution: sql ce version mismatch (http://blogs.msdn.com/b/sqlservercompact/archive/2009/05/06/troubleshooting-access-violation-exception-while-using-sql-server-compact-database-with-ado-net-provider.aspx)
Probable Rejection: I can see in the version installed is 3.5 SP2 (3.5.8080.0) and from the modules located in the dump I can see the sqlceme35.dll, System.Data.SqlServerCe.dll DLL's are with version 3.05.8080.0
Probable solution which is in question is the following:
https://stackoverflow.com/a/20492181/1447518
Probable Rejection: it doesn't sound right from a statistical perspective- the code crashed twice in the same place although there another place in the application code which writes and read to a different DB and the application didn't crash there.
The last thing I was thinking about, may suggest a unload problem of DLLs (take a look at the second call stack). My guess is that the dll's are unloaded from the application while the application needed them in order to do a dispose, but it seams a bit blurry and a 'long shot'
My question is: what may cause the problem, and what is a probable solution?

Although this solution is not yet verified, the solution is as follows:
From the second call stack i can see there is unload of native DLL's, my guess was that the dispose method of the SQL connection was using one of the methods it currently disposed.
I verified thorough the Process dump that all the SqlCeConnection types were in the process of dispose.
Seeing ErikEj comment made me realize it's will be better if i will take a look in the code differences that was made between SQL-CE 3.5 to 4.0 (System.Data.SqlServerCe.dll).
after viewing the code, i could see that the method of the release was moved to a later position inside the dispose method.
In addition i could see that before calling SafeRelease there was another check that checks if the native DLLs that were needed for safe release was released already- and throw an exception.
bottom line, SQL-CE 4.0 has 2 solutions for the same issue.
my guess is that this issue was caused because of this.
the solution for now was to keep a connection during all the application life-cycle (which has no connection string), this cause the pointer pool to keep the native Dlls in the memory for all the application life-cycle.
the better solution is to move to SQL-CE 4.0 .

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

How to fix this exception shown in windbg execution?

after running the .exe thought WinDBG, this was the exception information provided by pressing "k" when the exception occured:
ChildEBP RetAddr
0012e2f4 6f9fbb1c KERNELBASE!RaiseException+0x58
0012e354 6fba88f4 mscorwks!RaiseTheExceptionInternalOnly+0x2a8
0012e36c 6fba8966 mscorwks!RaiseTheException+0x4e
0012e394 6fba8997 mscorwks!RaiseTheException+0xc0
0012e3c0 6fba89a5 mscorwks!RealCOMPlusThrow+0x30
0012e3d0 6fac7ffe mscorwks!RealCOMPlusThrow+0xd
0012e8c8 6fa9d308 mscorwks!MethodTable::DoRunClassInitThrowing+0x44c
0012e914 6f9f8b9b mscorwks!DomainFile::Activate+0x226
0012e920 6f9cc537 mscorwks!DomainFile::DoIncrementalLoad+0xb4
0012e9a4 6f9cc43e mscorwks!AppDomain::TryIncrementalLoad+0x97
0012e9f4 6f9cd449 mscorwks!AppDomain::LoadDomainFile+0x19d
0012ea6c 6fb40e1a mscorwks!AppDomain::LoadDomainAssembly+0x116
0012eab0 6fb148c4 mscorwks!AppDomain::LoadExplicitAssembly+0x43
0012ed24 6fb167be mscorwks!ExecuteDLLForAttach+0x109
0012edd4 6fb16e9b mscorwks!ExecuteDLL+0x197
0012ee20 704c71f8 mscorwks!CorDllMainForThunk+0x8d
0012ee38 704ca1fe MSCOREE!CorDllMainWorkerForThunk+0x50
0012ee48 704bb2dc MSCOREE!VTableBootstrapThunkInitHelper+0x1b
0012eec8 7726519a MSCOREE!VTableBootstrapThunkInitHelperStub+0xc
WARNING: Stack unwind information not available. Following frames may be wrong.
0012eed0 7726517e ntdll!RtlpNtMakeTemporaryKey+0x43d6
0012eed4 770116fc ntdll!RtlpNtMakeTemporaryKey+0x43ba
0012ef10 77227d96 RPCRT4!DG_CCALL::DispatchPacket+0x1e3
0012ef14 014b1628 ntdll!RtlTimeToElapsedTimeFields+0xe902
0012ef18 00000000 0x14b1628
Does anyone knows what does this mean? And how can I solve it?

If it is a 3.5 or lower .NET then you have to load sos by calling ".loadby sos mscorwks". If it is a 4.0 then you have to use ".loadby sos clr".

What you're seeing is the unmanaged stack that's handling a managed exception. I suggest you do the following:
.load sos
!CLRStack
The first line will load SOS.dll, which allows for debugging of managed code. The second will print the managed stack trace. You can also use !help to see what other commands are available. For more information, see this MSDN article: http://msdn.microsoft.com/en-us/library/yy6d2sxs.aspx.