And just to add to your information, I’ve seen it not only with stack
based events but also with other types of variables like an
IO_STATUS_BLOCK that is used for an asynchronous request. If the
variable is allocated on the stack and the routine returns back then
later the status is set you get similar types of results. But in the
end, any sort of stack based variable used in this way where the stack
is unwound then later the variable is modified can result in this
behavior.
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
------ Original Message ------
From: “Scott Noone”
To: “Windows File Systems Devs Interest List”
Sent: 12/2/2016 8:29:17 AM
Subject: Re:[ntfsd] RE:Can filter manager APIs crash due to parallel
execution
>This crash is damn cool.
>
>All looks good except the CPU plucked a NULL pointer off the stack
>where a return address should be.
>
>I would really like to see the corrupted stack BEFORE the exception
>happened. Unfortunately the page fault handler ran and pushed all sorts
>of stuff onto the stack, losing the corrupted values:
>
>ffffd00184146a98 fffff801
fea1330d fltmgr!FltpGetStreamListCtrl+0x4d
>ffffd00184146aa0 ffffe001
01cba010
>ffffd00184146aa8 ffffe001
01cba010
>ffffd00184146ab0 6d83bfc6
6d83bfc6
>ffffd00184146ab8 6d83bfc6
6d83bfc6
>ffffd00184146ac0 96177a9c
b0036100
>ffffd00184146ac8 00000000
00000167
>ffffd00184146ad0 00000000
00000000
>ffffd00184146ad8 00000000
00000080
>ffffd00184146ae0 00000000
00000010
>ffffd00184146ae8 00000000
00000000
>ffffd00184146af0 00000000
00000010
>ffffd00184146af8 00000000
00010282
>ffffd00184146b00 ffffd001
84146b10
>ffffd00184146b08 00000000
00000018 << Bad RIP was here!
>ffffd00184146b10 ffffe000
fe70e010
>ffffd00184146b18 ffffe001
01cba010
>ffffd00184146b20 00000000
00000000
>ffffd00184146b28 ffffe001
01cba018
>ffffd00184146b30 ffff2800
7b17530b
>ffffd00184146b38 00000000
00000000
>ffffd00184146b40 ffffe000
fde24040
>ffffd00184146b48 fffff801
ff02d6a2
>HPEDpHsmX64!HpArcHsmDeferredReadWriteCompletion+0x112
>ffffd00184146b50 ffffe001
01cba010
>ffffd00184146b58 ffffe000
fe9b2040
>ffffd00184146b60 ffffe001
01a92070
>
>The sort of thing that you expect to see if someone has a calling
>convention wrong, but that’s highly unlikely to be the case here. Do
>you ever use stack based events? I think someone already mentioned this
>but it’s a common way create a stack corruption bug (i.e. you put the
>event on the stack and then leave without waiting, at some point in the
>future someone sets the event).
>
>-scott
>OSR
>@OSRDrivers
>
>
>“Anatoly Mikhailov” wrote in message
>news:xxxxx@ntfsd…
>
>One my previous post is one separate patch.
>
>
>—
>NTFSD is sponsored by OSR
>
>
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at http:
>
>To unsubscribe, visit the List Server section of OSR Online at
>http:</http:></http:>