Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Sept/Oct 2019 Issue of The NT Insider available

Download PDF here:

It’s a particularly BIG issue, too: 40 pages of technical goodness, ranging from WDF to Minifilters. Check it out.
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.


MDHMDH Member Posts: 16

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


  • rod_widdowsonrod_widdowson Member - All Emails Posts: 1,067

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

  • rod_widdowsonrod_widdowson Member - All Emails Posts: 1,067

    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.

  • MDHMDH Member Posts: 16

    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.

  • MDHMDH Member Posts: 16

    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.

  • rod_widdowsonrod_widdowson Member - All Emails Posts: 1,067

    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

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 21 Oct 2019 OSR Seminar Space & ONLINE
Internals & Software Drivers 18 Nov 2019 Dulles, VA
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 27 Apr 2020 OSR Seminar Space & ONLINE