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_UserOSR_Community_User Member Posts: 110,217
Victor (et. al.) -

Thanks for all the information so far - i'm making progress!

I followed the directions below, and was able to dump some TEBs with the strct
command - problem is, the "k" command uses its argument to figure out how *many*
entries it should print from the callback stack, not *which* call back stack to
use! For example:

> !load kdex2x86
Debugger extension library [kdex2x86] loaded
> !strct nt_tib 0x7fdff000
struct _NT_TIB (sizeof=28)
+00 struct _EXCEPTION_REGISTRATION_RECORD *ExceptionList = 0x7fdff000: Could
not read data for structure member(ExceptionList).
Unable to dump (Address=7FDFF000)

> !strct nt_tib 0x7FFDF000
struct _NT_TIB (sizeof=28)
+00 struct _EXCEPTION_REGISTRATION_RECORD *ExceptionList = 00000000
+04 void *StackBase = FFFFFFFF
+08 void *StackLimit = 00400000
+0c void *SubSystemTib = 00131E90
+10 void *FiberData = 00020000
+10 uint32 Version = 00020000
+14 void *ArbitraryUserPointer = 00000000
+18 struct _NT_TIB *Self = 00130000

> kvs
0012fc80 77dc86d3 0x77f8fb68
0012fcac 77dc9431 0x77dc86d3
0012fd28 77db29f7 0x77dc9431
0012ff64 0040857c 0x77db29f7
0012ff80 00435468 TSRV!main+0x2c(...) [ MAIN.c @ 45 ]
0012ffc0 77e87903 TSRV!mainCRTStartup+0x118(...) [ crt0.c @ 257 ]
0012fff0 00000000 0x77e87903
> kvs 11
0012fc80 77dc86d3 0x77f8fb68
0012fcac 77dc9431 0x77dc86d3
0012fd28 77db29f7 0x77dc9431
0012ff64 0040857c 0x77db29f7
0012ff80 00435468 TSRV!main+0x2c(...) [ MAIN.c @ 45 ]
0012ffc0 77e87903 TSRV!mainCRTStartup+0x118(...) [ crt0.c @ 257 ]
0012fff0 00000000 0x77e87903
> kvs 2
0012fc80 77dc86d3 0x77f8fb68
0012fcac 77dc9431 0x77dc86d3
>

The only way i got "k" to dump a different stack is by selecting a different
thread with the GUI tool. When i selected a different thread, i still got the
now-nearing-famous "empty stack" list. In fact, i went through the first 36 (!)
threads, for each i "Select"-ed it and did "kvs" - i got the following:

>
> kvs
0012fc80 77dc86d3 0x77f8fb68
0012fcac 77dc9431 0x77dc86d3
0012fd28 77db29f7 0x77dc9431
0012ff64 0040857c 0x77db29f7
0012ff80 00435468 TSRV!main+0x2c(...) [ MAIN.c @ 45 ]
0012ffc0 77e87903 TSRV!mainCRTStartup+0x118(...) [ crt0.c @ 257 ]
0012fff0 00000000 0x77e87903
>
> kvs
fffffffc 00000000 0x00000000
>
> kvs
fffffffc 00000000 0x00000000
>
> kvs
0000000e 00000000 0x00000001
>
> kvs
fffffffc 00000000 0x00000000
>
> kvs
fffffffc 00000000 0x00000000
>
> kvs
fffffffc 00000000 0x00000000
>
> kvs
00000000 00000000 0x01d8fcec
>
> kvs
fffffffc 00000000 0x00000000
>
> kvs
fffffffc 00000000 0x00000000
>
> kvs
fffffffc 00000000 0x00000000
>
> kvs
fffffffc 00000000 0x00000000
>
> kvs
fffffffc 00000000 0x00000000
>
> kvs
fffffffc 00000000 0x00000000
>
> kvs
00000017 00000000 TSTRAF!threadstartex [ threadex.c @ 185 ]
>
> kvs
fffffffc 00000000 0x00000000
>
> kvs
fffffffc 00000000 0x00000000
>
> kvs
b000affc 00000000 0x138077f8
>
> kvs
fffffffc 00000000 0x00000000
>
> kvs
fffffffc 00000000 0x00000000
>
> kvs
fffffffc 00000000 0x00000000
>
> kvs
77f8a11e 56000cc2 0x00000000
>
> kvs
fffffffc 00000000 0x00000000
>
> kvs
fffffffc 00000000 0x00000000
>
> kvs
0331fb78 00000000 0xfda80000
>
> kvs
fffffffc 00000000 0x00000000
>
> kvs
fffffffc 00000000 0x00000000
>
> kvs
fffffffc 00000000 0x00000000
>
> kvs
0391fb78 0391ff80 0x00000000
>
> kvs
fffffffc 00000000 0x00000000
>
> kvs
fffffffc 00000000 0x00000000
>
> kvs
0331fdd4 00000000 0x0065fb7c
>
> kvs
fffffffc 00000000 0x00000000
>
> kvs
fffffffc 00000000 0x00000000
>
> kvs
fffffffc 00000000 0x00000000
>
> kvs
fffffffc 00000000 0x00000000
>
> kvs
fffffffc 00000000 0x00000000
>
>

What is going wrong? What does that line mean - does it mean the thread is in
WaitForSingleObject or something analogous?






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 <xxxxx@avaya.com> -- 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 <xxxxx@avaya.com> -- 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
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