Stack Text Commands

Stack Text Commands

The stack text is one of the most fundamental elements of a dump file, and shouldn’t be overlooked. the stack text will contain all the saved function calls used by drivers and kernel modules at the time of the crash. There are a few different commands which can be used to produce a stack unwind.

The three main stack unwind commands I tend to use are listed as follows:

kv: This will produce a stack unwind with all the symbols, module names, and memory addresses.

k: This will produce a stack unwind with only the module name and the memory addresses.


kb: This is the stack text backtrace, and will provide similar information to the kv command, this is useful when needing to check the call stack within a particular context, such as a context switch.


Note: The stack text is produced in reverse order, the first call is at the bottom of the stack, whereas, the last call usually KeBugCheckEx (when the BSOD was produced) is at the top of the stack text.

The Raw Stack Text:

The stack text will usually set to the context of the crash, and may not always contain all the information which could assist us in our debugging efforts, therefore we need to gather a raw stack text.

Firstly, we need to set the context of the dump file to the crashing thread, we can use the !thread extension in order to do this.

0: kd> !thread
GetPointerFromAddress: unable to read from fffff80004abd000
THREAD fffff80004a0ecc0 Cid 0000.0000 Teb: 0000000000000000 Win32Thread: 0000000000000000 RUNNING on processor 0
Not impersonating
GetUlongFromAddress: unable to read from fffff800049fcba4
Owning Process fffff80004a0f180 Image:
Attached Process fffffa80052059e0 Image: System
fffff78000000000: Unable to get shared data
Wait Start TickCount 17103124
Context Switch Count 11139370 IdealProcessor: 0
ReadMemory error: Cannot get nt!KeMaximumIncrement value.
UserTime 00:00:00.000
KernelTime 00:00:00.000
Win32 Start Address nt!KiIdleLoop (0xfffff8000487c8f0)
Stack Init fffff80000b9cc70 Current fffff80000b9cc00
Base fffff80000b9d000 Limit fffff80000b97000 Call 0
Priority 16 BasePriority 0 UnusualBoost 0 ForegroundBoost 0 IoPriority 0 PagePriority 0

Notice the two highlighted values, this is the size of our current thread, this will be the entire size of our thread and more importantly raw stack text.

So, let’s go and get our raw stack:

dps fffff80000b97000 fffff80000b9d000 

Press Enter, and you will receive a very large stack text for the entire context of the crashing thread.

fffff800`00b9c588 fffff880`102924cbUnable to load image \SystemRoot\system32\DRIVERS\nvlddmkm.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for nvlddmkm.sys
*** ERROR: Module load completed but symbols could not be loaded for nvlddmkm.sys
nvlddmkm+0x1fb4cb 

You will notice, certain modules will have symbol problems, don’t worry if you have set-up your symbol server correctly then this should appear only for third-party driver modules, which do not have their symbols made publicly available. The nvlddmkm.sys seems to be a possible cause for the crash, and therefore we should use some of other commands to investigate further.





Advertisements

About 0x14c

I'm a Computer Science student and writer. My primary interests are Graph Theory, Number Theory, Programming Language Theory, Logic and Windows Debugging.
This entry was posted in Debugging, WinDbg. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s