Whenever I get a BSOD during testing I just assume it’s caused by my driver. I got this crash today though on a Win10 x64 box when restarting the system. My minifilter was already unloaded at the time. I looked at nt!KiPreBugcheckStackSaveArea and my driver isn’t listed so, is there any other way to verify if my minifilter had any part in this? If it matters, DV is enabled for fltmgr.sys.
DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL (d5)
Memory was referenced after it was freed.
This cannot be protected by try-except.
When possible, the guilty driver’s name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: ffffff0a3be90f90, memory referenced
Arg2: 0000000000000000, value 0 = read operation, 1 = write operation
Arg3: fffff80fd80615f7, if non-zero, the address which referenced memory.
Arg4: 000000000000000c, (reserved)
!verifier 80 ffffff0a3be90f90 will tell you a lot.
You might still be to blame if for instance you freed up something but it was still in a system list (an ERESOURCE is often a good candidate, but that doesn’t seem likely from the stack)
Also worth pointing out that d46f66fc luafv!LuafvPreWrite+0x47 is early enough in the code that you’ll be able to tell which parameter is causing the problem.
Thanks Rod. Unfortunately !verifier doesn’t provide anything.
6: kd> !verifier 80 ffffff0a3be90f90
Log of recent kernel pool Allocate and Free operations:
There are up to 0x10000 entries in the log.
Parsing 0x0000000000010000 log entries, searching for address 0xffffff0a3be90f90.
Finished parsing all pool tracking information.
No entries matching address ffffff0a3be90f90 have been found.
When the dump loads, it prints a whole bunch of “Page XXX too large to be in the dump file” so not sure if any useful data is lost.
Page 2001b2926 too large to be in the dump file.
.Page 20012d5c4 too large to be in the dump file.
Page 20019f6ad too large to be in the dump file.
.Page 20017efd8 too large to be in the dump file.
Page 200682e8d too large to be in the dump file.
.Page 2001b80dc too large to be in the dump file.
…
I’ll try to dig into the parameters to see if that points to anything.
Turns out it is pointing to the FsContext of the FileObject which happens to be one of my isolation filter objects. However, my filter had unloaded already so I’m a bit confused how it could unload fine but luafv is still holding on to a FO reference. Is there anyway to prevent this situation or just not unload the driver? This was during shutdown though so even that doesn’t seem a foolproof solution to prevent this kind of crash if it really is hanging on to a reference for some reason.