(I am sorry this question is related to managed code, but from my heart, this list has many gurus so I go here.)
Hello everyone,
I am debugging a crash dump of managed code, when using !threads to show all threads here, a couple of threads has Exception field value with various exceptions.
My question is how to identify which exception is the root exception which causes process crash in a quick way? Any ideas why so many threads are associated with Exception value – I think there should be only one thread (with unhandled exception) which causes process crash, why so many threads shows exception?
I am debugging a crash dump of managed code, when using !threads to show all threads here, a couple of threads has Exception field value with various exceptions.
My question is how to identify which exception is the root exception which causes process crash in a quick way? Any ideas why so many threads are associated with Exception value – I think there should be only one thread (with unhandled exception) which causes process crash, why so many threads shows exception?
The exception field merely shows the last exception that occurred on
that thread. Many exceptions are thrown and caught during normal
operation, and the field is not cleared when an exception is caught.
If you look at the call stacks, you should be able to identify which
thread called the exception thrower.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thanks Tim! I found the result by using analyze -v command.
A further stupid question, if I know the address where I execute and met the exception, any quick way to find the associate source code – sorry my code is written in C#, and I have used u command to diassemble, but not quite clear to match source code.
Any comments or ideas?
regards,
George
----- Original Message ----
From: Tim Roberts To: Kernel Debugging Interest List Sent: Wednesday, February 25, 2009 1:39:57 AM Subject: Re: [windbg] Windbg stack trace issue
Lin George wrote: > I am debugging a crash dump of managed code, when using !threads to show all threads here, a couple of threads has Exception field value with various exceptions. > My question is how to identify which exception is the root exception which causes process crash in a quick way? Any ideas why so many threads are associated with Exception value – I think there should be only one thread (with unhandled exception) which causes process crash, why so many threads shows exception? >?
The exception field merely shows the last exception that occurred on that thread.? Many exceptions are thrown and caught during normal operation, and the field is not cleared when an exception is caught.
If you look at the call stacks, you should be able to identify which thread called the exception thrower.
– Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
Thanks Tim! I found the result by using analyze -v command.
A further stupid question, if I know the address where I execute and met the exception, any quick way to find the associate source code – sorry my code is written in C#, and I have used u command to diassemble, but not quite clear to match source code.
Sorry, I have never had to do managed debugging in Windbg. So far, all
of my managed work has been as “glue” for unmanaged components, and
debugging unmanaged components “just works”, as long as you have the
symbol files.
Thanks all the same, let us see if others could have experience.
Actually, I doubt whether Windbg has ability to decode assembly code/address into C# source code, since the code is JITed.
regards,
George
----- Original Message ----
From: Tim Roberts <>
To: Kernel Debugging Interest List Sent: Wednesday, February 25, 2009 2:10:23 AM Subject: Re: [windbg] Windbg stack trace issue
Lin George wrote: > Thanks Tim! I found the result by using analyze -v command. > > A further stupid question, if I know the address where I execute and met the exception, any quick way to find the associate source code – sorry my code is written in C#, and I have used u command to diassemble, but not quite clear to match source code. >?
Sorry, I have never had to do managed debugging in Windbg.? So far, all of my managed work has been as “glue” for unmanaged components, and debugging unmanaged components “just works”, as long as you have the symbol files.
I am debugging a crash dump of managed code, when using !threads to show all threads here,
a couple of threads has Exception field value with various exceptions.
My question is how to identify which exception is the root exception which causes
process crash in a quick way? Any ideas why so many threads are associated with Exception
value – I think there should be only one thread (with unhandled exception) which
causes process crash, why so many threads shows exception?
When you load the Dump into windbg, the faulting thread is pre-selected. Just type !clrstack and see what is presented to you.
GP
powered by Exchange 2007 - hosted by a Microsoft Gold Partner - visit us www.world-direct.at
A further stupid question, if I know the address where I execute and met the exception,
any quick way to find the associate source code – sorry my code is written in C#,
and I have used u command to diassemble, but not quite clear to match source code.
First you obviously need to load sos:
.loadby sos mscorwks
Then you get the MD (method-description) from a valid IP:
!ip2md
If this is in a valid JIT-range, you get a result like this:
