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.

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.
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)

00 ffff920abae772d0 fffff80fd46f66fc luafv!LuafvPreWrite+0x47
01 ffff920abae77300 fffff80fd46f4cca FLTMGR!FltpPerformPreCallbacks+0x2dc
02 ffff920abae77420 fffff8019a33c972 FLTMGR!FltpPreFsFilterOperation+0x12a
03 ffff920abae774b0 fffff8019a7970b0 nt!FsFilterPerformCallbacks+0xd2
04 ffff920abae77510 fffff8019a468e64 nt!FsRtlAcquireFileForCcFlushEx+0xec
05 ffff920abae777c0 fffff8019a46882a nt!MiFlushControlArea+0xa4
06 ffff920abae77890 fffff8019a434f9d nt!MiDeleteCachedSegment+0xf2
07 ffff920abae778e0 fffff8019a23ee27 nt!MiDereferenceSegmentThread+0x9e29d
08 ffff920abae77b10 fffff8019a3cbf66 nt!PspSystemThreadStartup+0x47

!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.

You cannot close until all your file objects have seen an IRP_MJ_CLOSE, at that stage noone cares any more.

If you own the cache this means that in general you cannot ever unload from the boot drive and you’ll manage about one time in ten on other drives