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

OSR_Community_User · July 25, 2000, 5:04pm

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 – 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