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