Some Windbg questions.

Shintaro

Shintaro

Well-known member
Joined
Jun 12, 2012
Posts
206
Location
Brisbane, Australia
So I was thinking that I would like to start digging deeper and (try!) understanding the causes of crashes. I know that some times it is not possible to find the cause.

Debug trace 1 attachment.

So given the kp command:

Code: 
0: kd> kp
Child-SP          RetAddr           Call Site
fffff880`03a4f5d8 fffff800`02946a23 nt!KeBugCheckEx
fffff880`03a4f5e0 fffff800`028f43d2  nt! ?? ::FNODOBFM::`string'+0x29ac2
fffff880`03a4f6d0 fffff800`028f2421  nt!MiDispatchFault+0x8c2
fffff880`03a4f7e0 fffff800`028d612e  nt!MmAccessFault+0x8f1
fffff880`03a4f940 fffff800`028cef5b   nt!KiPageFault+0x16e
fffff880`03a4fad8 fffff800`02cf63f3    nt!memcpy+0x20b
fffff880`03a4fae0 fffff800`02d44810  nt!PfTCreateTraceDump+0x2e3
fffff880`03a4fbe0 fffff800`02d4a403   nt!PfTGenerateTrace+0x10
fffff880`03a4fc10 fffff800`02b776e6   nt!PfTLoggingWorker+0x113
fffff880`03a4fd40 fffff800`028b6566   nt!PspSystemThreadStartup+0x5a
fffff880`03a4fd80 00000000`00000000 nt!KiStartSystemThread+0x16

So what I understand is that they are Native API calls as apposed to User API (Win32K) calls.

1/ How do I locate the meaning of PfTLoggingWorker in Microsoft documentation? I can't find it.

2/ How do I trace it back off the stack in to memory? Is that possible with kernel dump?


Debug trace 2 attachment.

What does the following mean and what impact does it have on the crash dump file?

Code: 
DbsSplayTreeRangeMap::Add: ignoring zero-sized range at ?fffff8a0`00225382?
DbsSplayTreeRangeMap::Add: ignoring zero-sized range at ?fffff8a0`02dfbc32?
DbsSplayTreeRangeMap::Add: ignoring zero-sized range at ?fffff800`00b9c3c0?

Any help would be greatly appreciated.
 

Attachments

Shintaro said:
What does the following mean and what impact does it have on the crash dump file?

Code: 
DbsSplayTreeRangeMap::Add: ignoring zero-sized range at ?fffff8a0`00225382?
DbsSplayTreeRangeMap::Add: ignoring zero-sized range at ?fffff8a0`02dfbc32?
DbsSplayTreeRangeMap::Add: ignoring zero-sized range at ?fffff800`00b9c3c0?

Any help would be greatly appreciated.
Click to expand...


Please keep in mind that I made this post 2.5 years ago..... I was a pup then!

jcgriff2 said:
Hi -

The lone dump bugcheck -

0x9f (0x3,,,) = driver in an incosistant state of power and blocking an IRP (I/O Request Packet) for too long a time.

Probable cause listed as "89e66000 disk" - relating in some manner to hard drive and/or its drivers.

Further confirmation of such as this was found in the dump -

Code: 
[FONT=Lucida Console]Dbs[COLOR=red]SplayTree[/COLOR]RangeMap::Add: ignoring zero-sized range at ?ffffffff`82d5ead4?
[/FONT]

A splay tree involves binary searches - http://digital.cs.usu.edu/~allan/DS/Notes/Ch22.pdf
Read More:
Click to expand...


http://www.techsupportforum.com/forums/f15/ibm-z-pro-workstation-asr-service-469274.html#post2644007





The 2 dumps:

Intel wifi named in the latest w/ 0x9f (0x3,,,)

The prior dump was build 7600 and had a 2005 version ATK0110, so 0x1a bugcheck is plausable. I didn't find ASACPI.sys in the most recent dump, so I don't know if OP updated it or not -
Code: 
[FONT=lucida console]
ASACPI.sys                Sun Mar 27 22:30:36 [COLOR="#FF0000"]2005[/COLOR] (42476C4C) - 
NETwNs64.sys              Mon Dec 12 11:19:10 2011 (4EE6297E)
[/FONT]
http://www.sysnative.com/drivers/driver.php?id=ASACPI.sys

Dec 2011 is rather old for an Intel wifi driver -
http://www.sysnative.com/drivers/driver.php?id=NETwNs64.sys


Regards. . .

John


EDIT: Sorry I couldn't specifically answer your questions about digging deeper.

p.s. I would suggest to OP to ditch NIS/N360 until BSOD epidemic is over; actually get rid of it for good. :)


BSOD SUMMARY
Code: 
[FONT=lucida console]
Loading Dump File [C:\Users\PalmDesert\SysnativeBSODApps\Debug2.dmp]
Built by: 7601.17835.amd64fre.win7sp1_gdr.120503-2030
Debug session time: Sun Aug 12 15:32:41.340 2012 (GMT-4)
System Uptime: 0 days 3:20:13.230
BugCheck 9F, {3, fffffa80049ada10, fffff80000b9c3d8, fffffa80096d3880}
*** WARNING: Unable to verify timestamp for NETwNs64.sys
*** ERROR: Module load completed but symbols could not be loaded for NETwNs64.sys
Probably caused by : NETwNs64.sys
DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT
BUGCHECK_STR:  0x9F
PROCESS_NAME:  System
FAILURE_BUCKET_ID:  X64_0x9F_IMAGE_NETwNs64.sys
Bugcheck code 0000009F
Arguments 00000000`00000003 fffffa80`049ada10 fffff800`00b9c3d8 fffffa80`096d3880

¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``

Loading Dump File [C:\Users\PalmDesert\SysnativeBSODApps\Debug1.dmp]
Built by: 7600.17017.amd64fre.win7_gdr.120503-2030
Debug session time: Wed Jul 25 17:17:45.886 2012 (GMT-4)
System Uptime: 0 days 3:43:58.008
BugCheck 1A, {5002, fffff781c0000000, b4d6, ffb4d5fffffffe}
*** WARNING: Unable to verify timestamp for win32k.sys
*** ERROR: Module load completed but symbols could not be loaded for win32k.sys
Probably caused by : ntkrnlmp.exe ( nt! ?? ::FNODOBFM::`string'+29ac2 )
DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT
BUGCHECK_STR:  0x1a_5002
PROCESS_NAME:  System
FAILURE_BUCKET_ID:  X64_0x1a_5002_nt!_??_::FNODOBFM::_string_+29ac2
Bugcheck code 0000001A
Arguments 00000000`00005002 fffff781`c0000000 00000000`0000b4d6 00ffb4d5`fffffffe
BiosVersion = 0406   
BiosReleaseDate = 09/10/2009
SystemManufacturer = System manufacturer
SystemProductName = System Product Name
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``

         


       [COLOR=#000033]J. C. Griffith, Microsoft MVP (jcgriff2)[/COLOR]   
             
           [URL="http://mvp.microsoft.com/profiles/Griffith"][COLOR=#000055][U][url]https://mvp.support.microsoft.com/profile/Griffith[/url][/U][/COLOR][/URL]   
           [URL="https://www.sysnative.com"][COLOR=#000033][U][url]www.sysnative.com[/url][/U][/COLOR][/URL]
             
           [URL="http://jcgriff2.com"][COLOR=#000055][U][url]www.jcgriff2.com[/url][/U][/COLOR][/URL] 

¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨[/FONT]
 
Last edited:
These are internal Windows calls, and are most likely classified. Yes, I believe they're Native API calls.

The reason you can't find MS documentation is because they're internal Windows stuff and are not publicly documented nor accessible. However you can kinda get a good idea what they're responsible for by the acronym at the front of the symbol name (PfTLoggingWorker) and the actual activity being done (logging and tracing in this case). I'm thinking we're dealing with performance monitoring/event tracing here.

As for the second question, I'm not sure what you're asking for. I'm assuming you mean the log/trace information that it's writing. Without prior knowledge of the function or any documentation on it, your venture will be quite murky, and it'll require you to start sifting through raw data to see anything of relevance. Of course, this probably won't be happening since we're dealing with a minidump. But we can at least start off by figuring out the flow. This is what I personally figure is what's happening:

Code: 
STACK_TEXT:  
fffff880`03a4f5d8 fffff800`02946a23 : 00000000`0000001a 00000000`00005002 fffff781`c0000000 00000000`0000b4d6 : nt!KeBugCheckEx     [COLOR=#008000]< something went awry trying to use the zeroed memory, fault occurred again, this time a bugcheck.[/COLOR]
fffff880`03a4f5e0 fffff800`028f43d2 : 00000000`00000001 fffff8a0`1376a000 fffff880`03a4f940 fffff6fc`5009bb50 : nt! ?? ::FNODOBFM::`string'+0x29ac2    [COLOR=#008000] < Actually nt!MiResolveDemandZeroFault; the memory requested to be used for the buffer was zeroed memory, attempting to use it[/COLOR]
fffff880`03a4f6d0 fffff800`028f2421 : 00000000`00000000 fffff880`03a4f880 00000000`00000000 00000000`00000001 : nt!MiDispatchFault+0x8c2     [COLOR=#008000]< Part of the page fault handling[/COLOR]
fffff880`03a4f7e0 fffff800`028d612e : 00000000`00000001 fffff8a0`06d00038 ffffffff`f35d8f00 00000000`00000020 : nt!MmAccessFault+0x8f1     [COLOR=#008000]< Memory manager kicks in, attempts to handle page fault[/COLOR]
fffff880`03a4f940 fffff800`028cef5b : fffff800`02cf63f3 fffff8a0`06d00028 00000000`00000001 fffff8a0`13769fe8 : nt!KiPageFault+0x16e     [COLOR=#008000]< a page fault occurred from the memmove function[/COLOR]
fffff880`03a4fad8 fffff800`02cf63f3 : fffff8a0`06d00028 00000000`00000001 fffff8a0`13769fe8 fffff800`02c65225 : nt!memmove+0x20b   [COLOR=#008000]  < function moves buffer contents to other buffer.[/COLOR]
fffff880`03a4fae0 fffff800`02d44810 : fffff880`03a4fc10 fffff8a0`06d00018 fffff8a0`13752000 fffff8a0`0a4d9000 : nt!PfTCreateTraceDump+0x2e3
fffff880`03a4fbe0 fffff800`02d4a403 : fffffa80`05ebd501 00000000`00000080 fffffa80`039cc040 fffff800`02a65568 : nt!PfTGenerateTrace+0x10
fffff880`03a4fc10 fffff800`02b776e6 : ffffffff`ff676980 fffffa80`05ebd510 fffff880`03a4fdb0 fffffa80`05ebd510 : nt!PfTLoggingWorker+0x113     [COLOR=#008000]< Performance trace logging[/COLOR]
fffff880`03a4fd40 fffff800`028b6566 : fffff880`02f63180 fffffa80`05ebd510 fffff880`02f6dfc0 fffff880`014242b4 : nt!PspSystemThreadStartup+0x5a
fffff880`03a4fd80 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KxStartSystemThread+0x16

Take this all with a grain of salt, this is just my interpretation from some basic understanding of memory management. You may wanna look up Windows Internals book on it to get a grasp of it. Also Mark Russinovich's Mysteries of Memory Management Revealed will give you a good understanding of the various memory types for Windows and how they're all used.

Btw, in case you're curious, I believe I figured out the oddball symbol in the stack by using the return address for the frame it's on (fffff800`028f43d2). This shows me what nt!MiDispatchFault actually called into. The oddball symbol is caused by symbol confusion due to optimized code. There's a way to verify this is the correct function, but I can't recall it at the moment.

So what happened, if I'm correct, is that a trace dump needed to be made, a page fault occurred on the buffer (I assume the one containing the dump or the one it's going too), which then ended up being zeroed memory, and something went awry with that and bugchecked. Either way, it just sounds to me like the damage has already been done, and either no trace, or there's a very difficult trace back to the culprit.
 
Back
Top