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


More Info on Driver Writing and Debugging

The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.

Check out The OSR Learning Library at:

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.


MDHMDH Member Posts: 41

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,210

    !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,210

    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: 41

    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: 41

    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,210

    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. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Internals & Software Drivers 15 November 2021 Live, Online
Writing WDF Drivers TBD Live, Online
Developing Minifilters 7 February 2022 Live, Online
Kernel Debugging 21 March 2022 Live, Online