Hello,
We had a technical support call describing a BSOD occurring in the
field when my file system filter driver was installed on a server. Looking
at the list of loaded drivers revealed that there was at least one other
file system filter running in the environment (this was an educated guess
based on the name of the driver’s binary: *fltr.sys). This other file
system filter is from 1998, so I suspected maybe there was an
incompatibility between this driver and mine. Unfortuneately, the customer
did not record a copy of the blue screen and could not provide us with a
crash dump, so I’ve had little to go on.
The customer sent us a copy of the product in question. I installed
the product on clean NT4 SP5 checked build machine. The system crashed
during the next boot. I hooked up my debugger and saw that the crash was
due to ntfs asserting:
*** Assertion failed: Irp->CurrentLocation >= Irp->StackCount
*** Source File: W:\NT\PRIVATE\NTOS\io\mp..\iosubs.c, line 5759
here is a stack dump after one of the assertions:
kv
fffffffff3def418 ffffffff8011d0e6 NT!MmDeleteProcessAddressSpace+0x1b4
(EBP)
fffffffff3def438 ffffffff801c3a9c NT!FsRtlTruncateLargeMcb+0x94 (No FPO)
fffffffff3def538 ffffffff801f4fab NT!0xFFFFFFFF801C3A9C (No FPO)
fffffffff3def5c4 ffffffff801ee014 NT!0xFFFFFFFF801F4FAB (EBP)
fffffffff3def6d8 ffffffff801b861b NT!0xFFFFFFFF801EE014 (No FPO)
fffffffff3def840 ffffffff801776ba NT!0xFFFFFFFF801B861B (No FPO)
fffffffff3def85c 000000006720b103 NT!MiResetVirtualMemory+0x376 (EBP)
0000000000e8f838 0000000077f08606 NTDLL!LdrShutdownProcess+0xa4 (EBP)
0000000000e8f868 000000004d51ead2
KERNEL32!??xxxxx@xxxxx@xxxxx@RasGetConnectStatusW?$AA@+0xa (No FPO)
0000000000e8f8a0 000000004d51e2f1 GDI32!StretchBlt+0x13a (EBP)
0000000000e8ff08 000000004d51eef4 GDI32!Escape+0x266 (EBP)
0000000000e8ff3c 0000000066e36e6a GDI32!iAnsiCallback+0x7f (EBP)
0000000000e8ff5c 000000006722aa57 USER32!GetActiveKeyboardName+0x2a4 (EBP)
0000000000e8ffec 0000000000000000 NTDLL!RtlpRemoveHeapFromProcessList+0xc3
(EBP)
This assertion happens continuously.
So, to me, it *looks* like the product in question was not handling
initialization of the stack size in their device properly, or is not
handling the stack location pointer properly. Can someone smarter than me
think of any cause to this assertion other than a serious logic error in the
file system filter in question? Also, how can this device live in the real
world? If the driver in question is mishandling stack locations or stack
size initialization, it seems that that would be incompatible with life!
The customer claims he is successfully running this filter on
several of his servers. He also claims he is running my filter + this
filter on several of these servers successfully. Given this assertion, does
this seem possible? The crash, according to the customer, occurs only on
one server. Any tips or info would be greatly appreciated!
Thanks,
Joel