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 4  
03 Mar 17 22:16
Takin Nili-Esfahani
xxxxxx@hotmail.com
Join Date: 17 Oct 2005
Posts To This List: 2
FltObjectDereference crash

I have an object CFile that abstracts a FILE_OBJECT. When CFile is being initialized I store a pointer to PFLT_INSTANCE in a member of CFile and use FltObjectReference on it. In CFile::~CFile() I use PFLT_INSTANCE to make some filter manager calls and then before exiting call FltObjectDereference. Every once in a while I get a crash dump where RundownRef is 1. Based on observation FltObjectReference increments this member by 2 and FltObjectDereference decrements it by 2. So the fact that it is 1 at this point is unexpected. Maybe I am calling Deref one too many times by why is the count odd? What is ExfReleaseRundownProtection trying to do there? It checks to see if the RundownRef is odd then it jumps down and does another bit-wise operation and stores the result in r8. Then it tries to read the memory at the that location and crashes. How would this ever not cause a crash? Even if the count were, say 3 it would do the same. kd> u fltmgr!FltObjectDereference FLTMGR!FltObjectDereference: fffff800`090620f0 4883c108 add rcx,8 fffff800`090620f4 48ff25fd950200 jmp qword ptr [FLTMGR!_imp_ExReleaseRundownProtection (fffff800`0908b6f8)] fffff800`090620fb cc int 3 kd> !fltkd.instance 0xffffe000`53b87230 FLT_INSTANCE: ffffe00053b87230 "mydriver" "260620" FLT_OBJECT: ffffe00053b87230 [01000003] Instance DRAINING ZOMBIED RundownRef : 0x0000000000000001 (0) drained PointerCount : 0x00000002 PrimaryLink : [ffffe00053b8a5f0-ffffe00053b83b10] OperationRundownRef : 0000000000000000 Flags : [00000002] Deleting Volume : ffffe00053a3c7e0 "\Device\HarddiskVolume2" Filter : 0000000000000000 TrackCompletionNodes : 0000000000000000 ContextLock : (ffffe00053b872b0) Context : 0000000000000000 CallbackNodes : (ffffe00053b872d0) VolumeLink : [ffffe00053b8a5f0-ffffe00053b83b10] FilterLink : [0000000000000000-ffffe0005397ec40] kd> dt 0xffffe000`53b87230 _FLT_INSTANCE FLTMGR!_FLT_INSTANCE +0x000 Base : _FLT_OBJECT +0x030 OperationRundownRef : (null) +0x038 Volume : 0xffffe000`53a3c7e0 _FLT_VOLUME +0x040 Filter : (null) +0x048 Flags : 2 ( INSFL_DELETING ) +0x050 Altitude : _UNICODE_STRING "260620" +0x060 Name : _UNICODE_STRING "mydriver" +0x070 FilterLink : _LIST_ENTRY [ 0x00000000`00000000 - 0xffffe000`5397ec40 ] +0x080 ContextLock : _EX_PUSH_LOCK +0x088 Context : (null) +0x090 TransactionContexts : _CONTEXT_LIST_CTRL +0x098 TrackCompletionNodes : (null) +0x0a0 CallbackNodes : [50] (null) kd> dt 0xffffe000`53b87230 _FLT_OBJECT FLTMGR!_FLT_OBJECT +0x000 Flags : 0x1000003 (No matching name) +0x004 PointerCount : 2 +0x008 RundownRef : _EX_RUNDOWN_REF +0x010 PrimaryLink : _LIST_ENTRY [ 0xffffe000`53b8a5f0 - 0xffffe000`53b83b10 ] +0x020 UniqueIdentifier : _GUID {00000000-0000-0000-0000-000000000000} kd> dt 0xffffe000`53b87230+8 _EX_RUNDOWN_REF FLTMGR!_EX_RUNDOWN_REF +0x000 Count : 1 +0x000 Ptr : 0x00000000`00000001 Void kd> u nt!ExfReleaseRundownProtection nt!ExfReleaseRundownProtection+2f nt!ExfReleaseRundownProtection: fffff801`98b07fe0 4883ec28 sub rsp,28h fffff801`98b07fe4 0f0d09 prefetchw [rcx] fffff801`98b07fe7 4c8b01 mov r8,qword ptr [rcx] fffff801`98b07fea 41f6c001 test r8b,1 fffff801`98b07fee 7516 jne nt!ExfReleaseRundownProtection+0x26 (fffff801`98b08006) fffff801`98b07ff0 498d50fe lea rdx,[r8-2] fffff801`98b07ff4 498bc0 mov rax,r8 fffff801`98b07ff7 f0480fb111 lock cmpxchg qword ptr [rcx],rdx fffff801`98b07ffc 4c8bc0 mov r8,rax fffff801`98b07fff 7531 jne nt!ExfReleaseRundownProtection+0x52 (fffff801`98b08032) fffff801`98b08001 4883c428 add rsp,28h fffff801`98b08005 c3 ret fffff801`98b08006 4983e0fe and r8,0FFFFFFFFFFFFFFFEh fffff801`98b0800a 4883c8ff or rax,0FFFFFFFFFFFFFFFFh fffff801`98b0800e f0490fc100 lock xadd qword ptr [r8],rax kd> r Last set context: rax=ffffffffffffffff rbx=ffffc0007bcd3e30 rcx=ffffe00053b87238 rdx=ffffe00056830090 rsi=ffffc0007bcd3e30 rdi=ffffc0007bcd3e30 rip=fffff80198b0800e rsp=ffffd001b3d7e0c0 rbp=ffffc0007899fb10 r8=0000000000000000 r9=ffffd001b3d7e5e0 r10=0000000000000785 r11=fffff8000b6521c0 r12=0000000000000000 r13=ffffe00053da6a08 r14=fffff8000b674548 r15=ffffe0005484d780 iopl=0 nv up ei ng nz na po nc cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010286 nt!ExfReleaseRundownProtection+0x2e: fffff801`98b0800e f0490fc100 lock xadd qword ptr [r8],rax ds:002b:00000000`00000000=????????????????
  Message 2 of 4  
06 Mar 17 11:54
Scott Noone
xxxxxx@osr.com
Join Date: 10 Jul 2002
Posts To This List: 951
List Moderator
FltObjectDereference crash

Your instance structure looks a little off, like it might already be freed. What does "!pool 0xffffe000`53b87230 2" say? Have you tried enabling Verifier on your driver and FltMgr.sys? If the structure is being freed out from underneath it should show up pretty quickly with Verifier. -scott OSR @OSRDrivers wrote in message news:102271@ntfsd... I have an object CFile that abstracts a FILE_OBJECT. When CFile is being initialized I store a pointer to PFLT_INSTANCE in a member of CFile and use FltObjectReference on it. In CFile::~CFile() I use PFLT_INSTANCE to make some filter manager calls and then before exiting call FltObjectDereference. Every once in a while I get a crash dump where RundownRef is 1. Based on observation FltObjectReference increments this member by 2 and FltObjectDereference decrements it by 2. So the fact that it is 1 at this point is unexpected. Maybe I am calling Deref one too many times by why is the count odd? What is ExfReleaseRundownProtection trying to do there? It checks to see if the RundownRef is odd then it jumps down and does another bit-wise operation and stores the result in r8. Then it tries to read the memory at the that location and crashes. How would this ever not cause a crash? Even if the count were, say 3 it would do the same. kd> u fltmgr!FltObjectDereference FLTMGR!FltObjectDereference: fffff800`090620f0 4883c108 add rcx,8 fffff800`090620f4 48ff25fd950200 jmp qword ptr [FLTMGR!_imp_ExReleaseRundownProtection (fffff800`0908b6f8)] fffff800`090620fb cc int 3 kd> !fltkd.instance 0xffffe000`53b87230 FLT_INSTANCE: ffffe00053b87230 "mydriver" "260620" FLT_OBJECT: ffffe00053b87230 [01000003] Instance DRAINING ZOMBIED RundownRef : 0x0000000000000001 (0) drained PointerCount : 0x00000002 PrimaryLink : [ffffe00053b8a5f0-ffffe00053b83b10] OperationRundownRef : 0000000000000000 Flags : [00000002] Deleting Volume : ffffe00053a3c7e0 "\Device\HarddiskVolume2" Filter : 0000000000000000 TrackCompletionNodes : 0000000000000000 ContextLock : (ffffe00053b872b0) Context : 0000000000000000 CallbackNodes : (ffffe00053b872d0) VolumeLink : [ffffe00053b8a5f0-ffffe00053b83b10] FilterLink : [0000000000000000-ffffe0005397ec40] kd> dt 0xffffe000`53b87230 _FLT_INSTANCE FLTMGR!_FLT_INSTANCE +0x000 Base : _FLT_OBJECT +0x030 OperationRundownRef : (null) +0x038 Volume : 0xffffe000`53a3c7e0 _FLT_VOLUME +0x040 Filter : (null) +0x048 Flags : 2 ( INSFL_DELETING ) +0x050 Altitude : _UNICODE_STRING "260620" +0x060 Name : _UNICODE_STRING "mydriver" +0x070 FilterLink : _LIST_ENTRY [ 0x00000000`00000000 - 0xffffe000`5397ec40 ] +0x080 ContextLock : _EX_PUSH_LOCK +0x088 Context : (null) +0x090 TransactionContexts : _CONTEXT_LIST_CTRL +0x098 TrackCompletionNodes : (null) +0x0a0 CallbackNodes : [50] (null) kd> dt 0xffffe000`53b87230 _FLT_OBJECT FLTMGR!_FLT_OBJECT +0x000 Flags : 0x1000003 (No matching name) +0x004 PointerCount : 2 +0x008 RundownRef : _EX_RUNDOWN_REF +0x010 PrimaryLink : _LIST_ENTRY [ 0xffffe000`53b8a5f0 - 0xffffe000`53b83b10 ] +0x020 UniqueIdentifier : _GUID {00000000-0000-0000-0000-000000000000} kd> dt 0xffffe000`53b87230+8 _EX_RUNDOWN_REF FLTMGR!_EX_RUNDOWN_REF +0x000 Count : 1 +0x000 Ptr : 0x00000000`00000001 Void kd> u nt!ExfReleaseRundownProtection nt!ExfReleaseRundownProtection+2f nt!ExfReleaseRundownProtection: fffff801`98b07fe0 4883ec28 sub rsp,28h fffff801`98b07fe4 0f0d09 prefetchw [rcx] fffff801`98b07fe7 4c8b01 mov r8,qword ptr [rcx] fffff801`98b07fea 41f6c001 test r8b,1 fffff801`98b07fee 7516 jne nt!ExfReleaseRundownProtection+0x26 (fffff801`98b08006) fffff801`98b07ff0 498d50fe lea rdx,[r8-2] fffff801`98b07ff4 498bc0 mov rax,r8 fffff801`98b07ff7 f0480fb111 lock cmpxchg qword ptr [rcx],rdx fffff801`98b07ffc 4c8bc0 mov r8,rax fffff801`98b07fff 7531 jne nt!ExfReleaseRundownProtection+0x52 (fffff801`98b08032) fffff801`98b08001 4883c428 add rsp,28h fffff801`98b08005 c3 ret fffff801`98b08006 4983e0fe and r8,0FFFFFFFFFFFFFFFEh fffff801`98b0800a 4883c8ff or rax,0FFFFFFFFFFFFFFFFh fffff801`98b0800e f0490fc100 lock xadd qword ptr [r8],rax kd> r Last set context: rax=ffffffffffffffff rbx=ffffc0007bcd3e30 rcx=ffffe00053b87238 rdx=ffffe00056830090 rsi=ffffc0007bcd3e30 rdi=ffffc0007bcd3e30 rip=fffff80198b0800e rsp=ffffd001b3d7e0c0 rbp=ffffc0007899fb10 r8=0000000000000000 r9=ffffd001b3d7e5e0 r10=0000000000000785 r11=fffff8000b6521c0 r12=0000000000000000 r13=ffffe00053da6a08 r14=fffff8000b674548 r15=ffffe0005484d780 iopl=0 nv up ei ng nz na po nc cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010286 nt!ExfReleaseRundownProtection+0x2e: fffff801`98b0800e f0490fc100 lock xadd qword ptr [r8],rax ds:002b:00000000`00000000=????????????????
  Message 3 of 4  
08 Mar 17 03:57
mark
xxxxxx@gmail.com
Join Date: 02 Aug 2012
Posts To This List: 54
FltObjectDereference crash

Looking at the disassembly you provided for ExfReleaseRundownProtection, it seems perhaps it is using the LSB as a flag to indicate whether or not the object is in the process of being run down in which case a value of one would presumably indicate that the rundown has been completed for this instance since the flag is set and the reference count is zero. Furthermore it would seem reasonable to assume that the "Zombied" state with a pointercount of 2 suggests that the rundown has completed but there are still 2 outstanding pointer references to the instance? Might be helpful if you provided a stack trace/analysis trace from the crash ??
  Message 4 of 4  
16 Mar 17 08:18
Gabriel Bercea
xxxxxx@gmail.com
Join Date: 03 Mar 2008
Posts To This List: 293
FltObjectDereference crash

Sure, dump the stack trace. Also maybe your constructor and destructor code of the CFile class could help. Cheers, Gabriel. www.kasardia.com On Wed, Mar 8, 2017 at 9:58 AM, <xxxxx@gmail.com> wrote: > Looking at the disassembly you provided for ExfReleaseRundownProtection, > it seems perhaps it is using the LSB as a flag to indicate whether or not > the object is in the process of being run down in which case a value of one > would presumably indicate that the rundown has been completed for this > instance since the flag is set and the reference count is zero. Furthermore > it would seem reasonable to assume that the "Zombied" state with a > pointercount of 2 suggests that the rundown has completed but there are > still 2 outstanding pointer references to the instance? > > Might be helpful if you provided a stack trace/analysis trace from the <...excess quoted lines suppressed...> -- Bercea. G. --
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 10:17.


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