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: 682
FltUnregisterFilter->NtfsDecodeFileObject->Boom

Correct, you have taken ownership of a file object and it has not been closed. Later when it is closed, or whatever the next request is for it, NTFS doesn't like it. It can definitely be tricky to unload a layered FS. What I've done, for debug builds only and not for a release driver, is when you get the unload callback, check a list you maintain of your Fcbs. Purge the SOP if it is there, being careful since it can be issued a close request inline to the purge. Then return do_not_unload ... and then try again to unload, doing the same again. As long as there are no actively open 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. >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 <...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 08:30.


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