Finding Stack Trace information

G

Gator

Active member
Joined
Aug 16, 2014
Posts
35
Location
Ft. Myers
I have seen a few of these lately usually attached to a the machines processor driver intelppd!ReadIoMemRaw

In all cases, !errrec shows Fatal cache errors but this may be coincidental. My question is, where do I find specific information about !ReadIoMemRaw. Not only for just this instance, but in the future. I'd like to find the documentation for these calls so that I could reference them from time to time. I tried to google it but I only get hits leading to specific BSODs but I can't find documentation.

Any information will be much appreciated. Thanks!
 
You won't find the documentation for this function because it's private, therefore publicly undocumented.
 
Thanks for the quick response. Is there anywhere to find similar documentation for functions that show up on the stack or are they all pretty much undocumented?

Do you have any idea as to what that function actually does? Its seems slightly straight forward but the memraw part is throwing me off.
 
I mean, anything can show up on a stack. It all depends what the context of the stack is.

If your context is a trapframe regarding an exception from a bug check caused by an avast! kernel firewall driver, you're going to probably see some network functions in the stack among other things (whatever it's doing at the time), and avast's! stuff. A lot of kernel network functions (NETIO, etc) are documented publicly by Microsoft, but you'll come to find a lot of undocumented kernel and user-mode functions. There are many user undocumented functions that you may see in your analysis over time, like NtRaiseHardError.

For example, this is a user-mode bug check function (sort of) from ntdll, which will throw a blue screen if its ResponseOption parameter = OptionShutdownSystem so long as the SeRemoteShutdownPrivilege constant is enabled and met regarding the application. You can't just call that function from user-mode directly with an application, so you have to instead develop a kernel-mode driver that will expose NtRaiseHardError, and then inevitably call that from user-mode.

How do you come to find these things? Lots of ways, mostly reversing in the most extreme, but the more common are accidentally during development, and just dumping things like export tables. In most cases though, 9/10 times the functions you'll be dealing with in a debugging scenario are public. I've never really had to deal with too many undocumented functions, especially if it was the sole reason for a crash and I absolutely needed to know what it meant.

Edit: A lot of words, should never post before bedtime.
 
Last edited:
Well here is one specific stack

Code: 
: nt!KeBugCheckEx
: hal!HalBugCheckSystem+0x1e3
: nt!WheaReportHwError+0x263
 hal!HalpMcaReportError+0x4c
 hal!HalpMceHandler+0x9e
hal!HalpMceHandlerWithRendezvous+0x55
 hal!HalHandleMcheck+0x40
 nt!KxMcheckAbort+0x6c
nt!KiMcheckAbort+0x153 (TrapFrame @ fffff880`0317b030)
intelppm!ReadIoMemRaw+0x30

Thanks for your wisdom ;)
 
Is that an 0x124 dump?

The first call in the stack is the Intel Processor function, and since it's undocumented, we can only take a guess as to what ReadIoMemRaw is. Since this probably isn't a complete dump since we're starting literally at that function and no earlier, we don't know if it's waking from sleep, etc (or you just switched context to the core that was the sole reason for the bug check), we can assume the processor is reading raw memory from input/output, maybe some memory-mapped I/O or port-mapped I/O stuff. Overall, CPU was reading raw peripheral memory/data (whatever the peripheral were).

Overall, this is assembly and instruction stuff, so the fact that the processor goes from that to directly aborting and bug checking due to a failure is likely a CPU problem for sure, especially failing on something like an I/O function.
 
Yes this was a 124 dump and errrec showed cache errors which (from reading your posts) seems to almost always be a bad CPU. I really appreciate your information, thank you.
 
Patrick said:
Is that an 0x124 dump?

The first call in the stack is the Intel Processor function, and since it's undocumented, we can only take a guess as to what ReadIoMemRaw is. <...>, we can assume the processor is reading raw memory from input/output, maybe some memory-mapped I/O or port-mapped I/O stuff. Overall, CPU was reading raw peripheral memory/data (whatever the peripheral were).
Click to expand...


I think, depending on the parameters passed to the function, it either reads from memory (e.g. register) or IO port.
 
Last edited:

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top