Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

On-Access, Transparent, Per-File Data Encryption:

OSR's File Encryption Solution Framework (FESF) provides all the infrastructure you need to build a transparent file encryption product REALLY FAST.

Super flexible policy determination and customization, all done in user-mode. Extensive starter/sample code provided.

Proven, robust, flexible. In use in multiple commercial products.

Currently available on Windows. FESF for Linux will ship in 2018.

For more info: https://www.osr.com/fesf

Go Back   OSR Online Lists > ntfsd
Welcome, Guest
You must login to post to this list
  Message 1 of 2  
06 Sep 17 19:13
John
xxxxxx@gmail.com
Join Date: 10 May 2014
Posts To This List: 35
FltUnregisterFilter->NtfsDecodeFileObject->Boom

I'm getting a BSOD in my isolation filter during FltUnregisterFilter. Most of the stacks have been pretty consistent with the crash occurring in NtfsDecodeFileObject. I know what a crash there means when the filter is running however I'm unsure about why that's happening once FltUnregisterFilter is called. Is this just a reference counting issue thats causing a FILE_OBJECT to stick around longer than it should or something else? I can post stacks or analyze -v output as this is 100% reproducible but I figured the file system gurus might have some ideas to look at before getting too deep into debug output.
  Message 2 of 2  
06 Sep 17 19:40
Peter Scott
xxxxxx@kerneldrivers.com
Join Date: 17 Feb 2012
Posts To This List: 669
FltUnregisterFilter->NtfsDecodeFileObject->Boom

Correct, you have taken ownership of a file object and it has not been=20 closed. Later when it is closed, or whatever the next request is for it,=20 NTFS doesn't like it. It can definitely be tricky to unload a layered FS. What I've done, for=20 debug builds only and not for a release driver, is when you get the=20 unload callback, check a list you maintain of your Fcbs. Purge the SOP=20 if it is there, being careful since it can be issued a close request=20 inline to the purge. Then return do_not_unload ... and then try again to=20 unload, doing the same again. As long as there are no actively open=20 files, eventually you'll get to an empty list and can unload. Pete -- Kernel Drivers Windows File System and Device Driver Consulting www.KernelDrivers.com 866.263.9295 ------ Original Message ------ From: xxxxx@gmail.com To: "Windows File Systems Devs Interest List" <xxxxx@lists.osr.com> Sent: 9/6/2017 5:10:59 PM Subject: [ntfsd] FltUnregisterFilter->NtfsDecodeFileObject->Boom >I'm getting a BSOD in my isolation filter during FltUnregisterFilter. =20 >Most of the stacks have been pretty consistent with the crash occurring=20 >in NtfsDecodeFileObject. I know what a crash there means when the=20 >filter is running however I'm unsure about why that's happening once=20 >FltUnregisterFilter is called. Is this just a reference counting issue=20 >thats causing a FILE_OBJECT to stick around longer than it should or=20 >something else? > >I can post stacks or analyze -v output as this is 100% reproducible but=20 >I figured the file system gurus might have some ideas to look at before=20 <...excess quoted lines suppressed...>
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntfsd list to be able to post.

All times are GMT -5. The time now is 03:09.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license