Windbg stack trace issue

(I am sorry this question is related to managed code, but from my heart, this list has many gurus so I go here.) :slight_smile:

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? :slight_smile:

thanks in advance,
George

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? :slight_smile:

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. :slight_smile:

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? :slight_smile:
>?

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.


WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Lin George wrote:

Thanks Tim! I found the result by using analyze -v command. :slight_smile:

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.

My understanding is that there is a windbg extension called “sos” that
lets you dig in to managed code, but as I said, I’ve never used it.
http://msdn.microsoft.com/en-us/library/bb190764.aspx
http://msdn.microsoft.com/en-us/magazine/cc164138.aspx


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Thanks all the same, let us see if others could have experience. :slight_smile:

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. :slight_smile:
>
> 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.

My understanding is that there is a windbg extension called “sos” that
lets you dig in to managed code, but as I said, I’ve never used it.
? ? http://msdn.microsoft.com/en-us/library/bb190764.aspx
? ? http://msdn.microsoft.com/en-us/magazine/cc164138.aspx


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.


WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Hello!

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? :slight_smile:

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

Hello!

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:

MethodDesc: 015232c0
Method Name: TestApp.Program.Main(System.String)
Class: 015213c8
MethodTable: 015232e0
mdToken: 06000001
Module: 01522f2c
IsJitted: yes
CodeAddr: 01e10070

With the MethodDesc (015232c0) you can do further things in SOS (like dumping the IL-Code):

!dumpil 015232c0

GP

powered by Exchange 2007 - hosted by a Microsoft Gold Partner - visit us www.world-direct.at