Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

RE: want to view call stack for threads in a USERDUMP'ed- process

OSR_Community_User-48OSR_Community_User-48 Member Posts: 74
I recommend updating to the most recent Windbg

http://www.microsoft.com/ddk/debugging/

-----Original Message-----
From: Richard J. Pennenga [mailto:xxxxx@avaya.com]
Sent: Tuesday, July 25, 2000 11:49 AM
To: Kernel Debugging Interest List
Cc: Kernel Debugging Interest List
Subject: [windbg] RE: want to view call stack for threads in a
USERDUMP'ed process


Victor -

Dumb question: i'm using WinNT 4.0 SP 4, and the following version
information
came out of windbg:
> version

windbg : 3.5.7, built: Wed Dec 03 23:22:07 1997 [name:
e:\progra~1\windbg\bin\windbg.exe]
shcv.dll : 0.0.0, built: Wed Nov 26 15:30:37 1997 [name:
e:\progra~1\windbg\bin\shcv.dll]
symcvt.dll : 0.0.0, built: Wed Nov 26 15:30:37 1997 [name:
e:\progra~1\windbg\bin\symcvt.dll]
tlloc.dll : 0.0.0, built: Wed Nov 26 15:30:37 1997 [name:
e:\progra~1\windbg\bin\tlloc.dll]
tlpipe.dll : 0.0.0, built: Wed Nov 26 15:30:38 1997 [name:
e:\progra~1\windbg\bin\tlpipe.dll]
tlser.dll : 0.0.0, built: Wed Nov 26 15:30:38 1997 [name:
e:\progra~1\windbg\bin\tlser.dll]
em.dll : 0.0.0, built: Wed Dec 03 23:23:52 1997 [name:
e:\progra~1\windbg\bin\em.dll]
eecxx.dll : 0.0.0, built: Wed Nov 26 15:30:34 1997 [name:
e:\progra~1\windbg\bin\eecxx.dll]
dm.dll : 0.0.0, built: Wed Dec 03 23:22:39 1997 [name:
e:\progra~1\windbg\bin\dm.dll]
dmkdx86.dll : 0.0.0, built: Wed Dec 03 23:22:47 1997 [name:
e:\progra~1\windbg\bin\dmkdx86.dll]
msdbi.dll : 0.0.0, built: Wed Dec 03 16:39:21 1997 [name:
c:\winnt\system32\msdbi.dll]
imagehlp : 4.0.6, built: Thu Oct 01 21:46:49 1998 [name:
c:\winnt\system32\imagehlp.dll]

> !version
Debugger extension library [ntsdexts] loaded
Version 4.0 (Build 1381: Service Pack 4) Uniprocessor Free

It doesn't recognize "strct". Help?



Victor Pittman wrote:
>
> Rich,
> I've been playing around with this kinda stuff for a little while and
you
> could try this...
>
> The primary TEB (Thread Environment Block) is located at 0x7FFDF000
and is
> on page boundaries for each additional thread. So, in the command
window
> load the kernel extension kdex2x86 (it's in the Microsoft OEM toolkit
if you
> don't have it). Use the !strct command to look at the TEB (!strct
nt_tib
> 0x7FFDF000). From this you can see the following :
>
> > !strct nt_tib 0x7ffde000
> struct _NT_TIB (sizeof=28)
> +00 struct _EXCEPTION_REGISTRATION_RECORD *ExceptionList =
0012D674
> +04 void *StackBase = 00130000
> +08 void *StackLimit = 0012C000
> +0c void *SubSystemTib = 00000000
> +10 void *FiberData = 00001E00
> +10 uint32 Version = 00001e00
> +14 void *ArbitraryUserPointer = 00000000
> +18 struct _NT_TIB *Self = 7FFDE000
>
> Now using the k command...
>
> > kvs 00130000
> 000000000012d3f0 0000000077e555e6 rpcrt4!0x0000000077E1FB53 (No FPO)
> 000000000012d684 0000000077dcac41 rpcrt4!0x0000000077E555E6 (No FPO)
> 000000000012d6e8 0000000077dc1974 advapi32!0x0000000077DCAC41 (No
FPO)
> 000000000012d70c 0000000000406aee advapi32!0x0000000077DC1974 (No
FPO)
> 000000000012fad4 000000000041cd4c
NT_SYSTEM!NTEventLogTableCB+0x16e({...},
> {...}, 0x00000000) (No FPO) [ dant_systemucb.cpp @ 1925 ]
> 000000000012fb44 0000000000402c2d NT_SYSTEM!NAdomain::collect+0x7c
(No
> FPO) [ na_domain.cpp @ 94 ]
> 000000000012fba8 000000000040110f
NT_SYSTEM!NT_SystemMainLoop+0x18d({...})
> (No FPO) [ dant_systemucb.cpp @ 254 ]
> 000000000012ff80 0000000000452fa9 NT_SYSTEM!main+0xbf(0x00000002,
> 0x00910E50) (No FPO) [ dant_systemmain.cpp @ 84 ]
> 000000000012ffc0 0000000077f1b9ea NT_SYSTEM!mainCRTStartup+0xe9(...)
(No
> FPO) [ crt0.c @ 206 ]
> 000000000012fff0 0000000000000000 kernel32!0x0000000077F1B9EA (No
FPO)
>
> And there it is... you can then follow the same example with the
additional
> threads (this example is single threaded and an actual crash that I've
been
> playing with).
>
> But, whether this will give you any more information than you already
have,
> I'm not sure...
>
> Good luck and let me know what you find...
>
> Thanks,
> Victor Pittman
> Quest Software
> xxxxx@quest.com
>
> -----Original Message-----
> From: Richard J. Pennenga [mailto:xxxxx@avaya.com]
> Sent: Tuesday, July 25, 2000 6:00 AM
> To: Kernel Debugging Interest List
> Subject: [windbg] want to view call stack for threads in a USERDUMP'ed
> process
>
> My esteemed colleagues -
>
> I used USERDUMP.EXE to snatch a snapshot of a process, and am looking
at the
> resulting DMP file. Problem is, when i look at the call stack window,
it
> always
> looks.. well.. empty. (See shortcallstack.jpg in the ZIP file - it's
one
> line
> with three hex
> numbers on it.)
>
> This is true for all the threads i checked but one. They are all
labelled
> "Stopped" (see threads.jpg in the ZIP file). The one marked Running
gives
> me a
> short
> but in this case not that useful stack backtrace - the one for the
thread
> which
> was called by WinNT to register the service. It just sits and waits
until
> the
> end of time... not interesting.
>
> I don't believe that some 10 threads all have done nothing - this is a
> service
> that's been running long enough to get in trouble! What do i need to
do to
> see
> the correct call stack for these threads?
>
> Note that i tried using the thread dialog, pressing Freeze All,
pressing
> Select
> for one thread, then hitting the Call Stack button. I get the results
you
> see
> attached.
>
> What to do, what to do? Thanks in advance...
> --
> i There's a Cross _|_
> r h to bridge |
> c the Great Divide.. |
>
> Rich Pennenga -- Voice/Fax (732) 817-5927
> Avaya Communication, formerly the Enterprise Networks unit of Lucent
> Technologies
> Rm 2B-530A, 101 Crawfords Corner Road
> Holmdel, NJ 07733 -- http://sjbcs.web.lucent.com/~dween
>
> ---
> You are currently subscribed to windbg as: xxxxx@avaya.com
> To unsubscribe send a blank email to $subst('Email.Unsub')

--
i There's a Cross _|_
r h to bridge |
c the Great Divide.. |

Rich Pennenga -- Voice/Fax (732) 817-5927
Avaya Communication, formerly the Enterprise Networks unit of Lucent
Technologies
Rm 2B-530A, 101 Crawfords Corner Road
Holmdel, NJ 07733 -- http://sjbcs.web.lucent.com/~dween

---
You are currently subscribed to windbg as: xxxxx@microsoft.com
To unsubscribe send a blank email to $subst('Email.Unsub')
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA