You are doing USER level debugging! The !process command is kernel
level. I don’t have any idea how you would do this at user process
level.
Sorry!
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Burg
Sent: Thursday, July 29, 2004 7:56 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging user-mode events
Hello Tony,
What you said sounds very helpful. However, I have windbg 6.3.0017.0 and
when I type !process 0 0 it tells me:
No export process found
:-? Do I need to get a windbg update from somewhere?
Best regards,
David Burg
David Burg
Software Development,
InCD Project Leader
Ahead Software AG phone: +49 (0)7248 911 862 (direct line)
Im Stoeckmaedle 18 fax: +49 (0)7248 911 888
76307 Karlsbad email: xxxxx@nero.com
Germany http://www.nero.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Thursday, July 29, 2004 12:36 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging user-mode events
!locks only works with ERESOURCES. It is quite likely that the debugger
guys have added some new commands (functionality is showing up at a
furious rate) but I’ve always just looked from the thread side. The
!thread command will list - for each thread - the objects on which it is
waiting (mutant, event, semaphore, etc).
The important thing to remember is that user mode synchronization
objects are wrapped around OS level synchronization objects. So a user
mode event is a KEVENT with an object header on it (for example). This
doesn’t just tell you where the deadlock is, but it gives you the basic
tools that you need to find it. For example, if I have a system where I
think process X is deadlocked, I’ll find it (!process 0 0) and then I’ll
look at the threads for that process, trying to find the objects on
which they are waiting. It takes a little time to do this, but it
doesn’t require anything other than very basic debugger operations.
If you have a dispatcher object and want to know what is waiting, walk
the wait list (last field in the dispatcher header. All dispatcher
objects have a dispatcher header.)
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Burg
Sent: Thursday, July 29, 2004 4:39 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging user-mode events
Hello,
Thanks, I do have the symbols and properly see call stacks, threads,
etc…
But how do I get debug information on the events? For instance, can I
get the thread id waiting on a given event? Can windbg tell me something
like “Deadlock between thread x and y, because x is waiting on a event
that y has to set and y is waiting on an event that x has to set.”?
Best regards,
David Burg
David Burg
Software Development,
InCD Project Leader
Ahead Software AG phone: +49 (0)7248 911 862 (direct line)
Im Stoeckmaedle 18 fax: +49 (0)7248 911 888
76307 Karlsbad email: xxxxx@nero.com
Germany http://www.nero.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Primoz Beltram
Sent: Thursday, July 29, 2004 10:29 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging user-mode events
I can tell you my experience. To debug up to user space calls on our
product, I must have all correct .PDB files for all components (e.g. for
msvcp71.dll, GDI32.dll, …) listed on the call stack.
You can also check articles on OSR (NTINSIDER). Tony wrote several of
them related in un-screwing the call stacks.
WBR Primoz
-----Original Message-----
From: David Burg [mailto:xxxxx@nero.com]
Sent: Thursday, July 29, 2004 10:09 AM
To: Kernel Debugging Interest List
Subject: [windbg] Debugging user-mode events
Hello,
I browse the windbg help for deadlock debugging, but the two !lock
extension seems not related to the user mode events I would like to
debug (these events are accessed through
SetEvent/CreateEvent/OpenEvent/(unsafe)PulseEvent). Does someone knows
an windbg extension or mechanism to debug these events (…and the
deadlock you will potentially create with them)?
Best regards,
David Burg
Small and motivated,
Active and Reactive,
Welcome to the InCD Team.
David Burg
Software Development,
InCD Project Leader
Ahead Software AG phone: +49 (0)7248 911 862 (direct line)
Im Stoeckmaedle 18 fax: +49 (0)7248 911 888
76307 Karlsbad email: xxxxx@nero.com
Germany http://www.nero.com
You are currently subscribed to windbg as: xxxxx@hermes.si To
unsubscribe send a blank email to xxxxx@lists.osr.com
You are currently subscribed to windbg as: xxxxx@nero.com To unsubscribe
send a blank email to xxxxx@lists.osr.com
You are currently subscribed to windbg as: xxxxx@osr.com To unsubscribe
send a blank email to xxxxx@lists.osr.com
You are currently subscribed to windbg as: xxxxx@nero.com To unsubscribe
send a blank email to xxxxx@lists.osr.com
You are currently subscribed to windbg as: xxxxx@osr.com To unsubscribe
send a blank email to xxxxx@lists.osr.com