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 < something went awry trying to use the zeroed memory, fault occurred again, this time a bugcheck.
fffff880`03a4f5e0 fffff800`028f43d2 : 00000000`00000001 fffff8a0`1376a000 fffff880`03a4f940 fffff6fc`5009bb50 : nt! ?? ::FNODOBFM::`string'+0x29ac2 < Actually nt!MiResolveDemandZeroFault; the memory requested to be used for the buffer was zeroed memory, attempting to use it
fffff880`03a4f6d0 fffff800`028f2421 : 00000000`00000000 fffff880`03a4f880 00000000`00000000 00000000`00000001 : nt!MiDispatchFault+0x8c2 < Part of the page fault handling
fffff880`03a4f7e0 fffff800`028d612e : 00000000`00000001 fffff8a0`06d00038 ffffffff`f35d8f00 00000000`00000020 : nt!MmAccessFault+0x8f1 < Memory manager kicks in, attempts to handle page fault
fffff880`03a4f940 fffff800`028cef5b : fffff800`02cf63f3 fffff8a0`06d00028 00000000`00000001 fffff8a0`13769fe8 : nt!KiPageFault+0x16e < a page fault occurred from the memmove function
fffff880`03a4fad8 fffff800`02cf63f3 : fffff8a0`06d00028 00000000`00000001 fffff8a0`13769fe8 fffff800`02c65225 : nt!memmove+0x20b < function moves buffer contents to other buffer.
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 < Performance trace logging
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.
