Hi,
My user process raised an exeception and crashed. The DrWatson generated a
user mode crash for it. I can see the stack for the thread that raised
the
exception.But the stack has completely unwound. So I cannot determine
which function actually generated the exception. How do I go about finding
which function caused the problem in windbg. I have faced this problem
before and got stuck. Souce debugging is not possible as the problem is
occuring intermittenly at remote site.
Any help would be useful.
Thanks,
Amit
Hi,
My user process raised an exeception and crashed. The
DrWatson generated a user mode crash for it. I can
see the stack for the thread that raised the
exception. But the stack has completely unwound. So I cannot determine
which function actually generated the exception. How do I go
about finding
which function caused the problem in windbg.
I assume you got a mini crash dump of your application from DrWatson. This
dump contains no executable images to keep the size small. But windbg needs
the images to get the correct symbols. Set the executable image path and
symbol path in windbg. If you have installed the same OS as your customer,
simply use a path to your system32 as image path. Otherwise you have to set
up a system with the same OS and version as your customer and refer to the
system32 folder on that system. As symbol path it’s the easiest to use the
Microsoft symbol server (see the windbg help file or
http://www.microsoft.com/ddk/debugging/symbols.asp for details). Don’t
forget to add the path to your own application’s symbols to the path,too 
If you’ve set up everything correctly, type !analyze -v to let windbg
analyse the exception or use the call stack to analyse it by yourself.
Regards,
Martin
What does .exr -1 show?
When you say the thread has completely unwound, do you mean that the
only thing left on the thread stack is BaseThreadStart or
SystemCallStub?
You might consider asking the customer to enable launching your app
under a live debugger and ask them when it traps to do a .dump /ma
save1.dmp and .dump /f save2.dmp. I don’t know if there are
possibilities for the customer to setup a debugger remote for you so you
can actually debug the problem remotely. Or perhaps they can allow you
to logon to their network or TS in or use XP’s Remote Assistance or
something.
-----Original Message-----
From: xxxxx@hotmail.com [mailto:xxxxx@hotmail.com]
Sent: Friday, March 07, 2003 12:44 AM
To: Kernel Debugging Interest List
Subject: [windbg] Exception debugging
Hi,
My user process raised an exeception and crashed. The DrWatson generated
a user mode crash for it. I can see the stack for the thread that
raised the exception.But the stack has completely unwound. So I cannot
determine which function actually generated the exception. How do I go
about finding which function caused the problem in windbg. I have faced
this problem before and got stuck. Souce debugging is not possible as
the problem is occuring intermittenly at remote site. Any help would be
useful.
Thanks,
Amit
You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
Definitely using !analyze -v to let the debugger tell you where it
thinks the problem occurred is a good one.
I am pretty sure in all cases Dr. Watson always generates a full user
dump, not a minidump. So pointing to images in your .sympath or
.exepath should not be necessary. It is definitely always necessary for
minidumps.
-----Original Message-----
From: Hueser, Martin [mailto:xxxxx@swyx.com]
Sent: Friday, March 07, 2003 2:04 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Exception debugging
Hi,
My user process raised an exeception and crashed. The
DrWatson generated a user mode crash for it. I can
see the stack for the thread that raised the
exception. But the stack has completely unwound. So I cannot determine
which function actually generated the exception. How do I go
about finding
which function caused the problem in windbg.
I assume you got a mini crash dump of your application from DrWatson.
This dump contains no executable images to keep the size small. But
windbg needs the images to get the correct symbols. Set the executable
image path and symbol path in windbg. If you have installed the same OS
as your customer, simply use a path to your system32 as image path.
Otherwise you have to set up a system with the same OS and version as
your customer and refer to the system32 folder on that system. As symbol
path it’s the easiest to use the Microsoft symbol server (see the windbg
help file or http://www.microsoft.com/ddk/debugging/symbols.asp for
details). Don’t forget to add the path to your own application’s symbols
to the path,too
If you’ve set up everything correctly, type !analyze -v to let windbg
analyse the exception or use the call stack to analyse it by yourself.
Regards,
Martin
You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
Your executable module typically lives at 0x00400000 and up
(if memory serves). Thus, you can start looking through the
stack for dwords that look like return addresses into your
executable; especially if they point at the instruction after
a CALL instruction. From that point, you have an ESP and a
program counter, and can un-wind the stack manually by
following pushes/pops and adjusts to ESP within your program,
with no actuall process necessary. All that’s needed is the
knowledge where your module loaded, and a few pages of stack.
Cheers,
/ h+
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of xxxxx@hotmail.com
Sent: Friday, March 07, 2003 12:44 AM
To: Kernel Debugging Interest List
Subject: [windbg] Exception debugging
Hi,
My user process raised an exeception and crashed. The DrWatson generated a
user mode crash for it. I can see the stack for the thread that raised
the
exception.But the stack has completely unwound. So I cannot determine
which function actually generated the exception. How do I go about finding
which function caused the problem in windbg. I have faced this problem
before and got stuck. Souce debugging is not possible as the problem is
occuring intermittenly at remote site.
Any help would be useful.
Thanks,
Amit
You are currently subscribed to windbg as: xxxxx@mindcontrol.org
To unsubscribe send a blank email to xxxxx@lists.osr.com