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:
fffff800090620f0 4883c108 add rcx,8 fffff800090620f4 48ff25fd950200 jmp qword ptr [FLTMGR!_imp_ExReleaseRundownProtection (fffff8000908b6f8)] fffff800090620fb 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 0xffffe00053b87230 _FLT_INSTANCE FLTMGR!_FLT_INSTANCE +0x000 Base : _FLT_OBJECT +0x030 OperationRundownRef : (null) +0x038 Volume : 0xffffe00053a3c7e0 _FLT_VOLUME
+0x040 Filter : (null)
+0x048 Flags : 2 ( INSFL_DELETING )
+0x050 Altitude : _UNICODE_STRING “260620”
+0x060 Name : _UNICODE_STRING “mydriver”
+0x070 FilterLink : _LIST_ENTRY [0x0000000000000000 - 0xffffe0005397ec40]
+0x080 ContextLock : _EX_PUSH_LOCK
+0x088 Context : (null)
+0x090 TransactionContexts : _CONTEXT_LIST_CTRL
+0x098 TrackCompletionNodes : (null)
+0x0a0 CallbackNodes : [50] (null)

kd> dt 0xffffe00053b87230 _FLT_OBJECT FLTMGR!_FLT_OBJECT +0x000 Flags : 0x1000003 (No matching name) +0x004 PointerCount : 2 +0x008 RundownRef : _EX_RUNDOWN_REF +0x010 PrimaryLink : _LIST_ENTRY [0xffffe00053b8a5f0 - 0xffffe000`53b83b10]
+0x020 UniqueIdentifier : _GUID {00000000-0000-0000-0000-000000000000}

kd> dt 0xffffe00053b87230+8 _EX_RUNDOWN_REF FLTMGR!_EX_RUNDOWN_REF +0x000 Count : 1 +0x000 Ptr : 0x0000000000000001 Void

kd> u nt!ExfReleaseRundownProtection nt!ExfReleaseRundownProtection+2f
nt!ExfReleaseRundownProtection:
fffff80198b07fe0 4883ec28 sub rsp,28h fffff80198b07fe4 0f0d09 prefetchw [rcx]
fffff80198b07fe7 4c8b01 mov r8,qword ptr [rcx] fffff80198b07fea 41f6c001 test r8b,1
fffff80198b07fee 7516 jne nt!ExfReleaseRundownProtection+0x26 (fffff80198b08006)
fffff80198b07ff0 498d50fe lea rdx,[r8-2] fffff80198b07ff4 498bc0 mov rax,r8
fffff80198b07ff7 f0480fb111 lock cmpxchg qword ptr [rcx],rdx fffff80198b07ffc 4c8bc0 mov r8,rax
fffff80198b07fff 7531 jne nt!ExfReleaseRundownProtection+0x52 (fffff80198b08032)
fffff80198b08001 4883c428 add rsp,28h fffff80198b08005 c3 ret
fffff80198b08006 4983e0fe and r8,0FFFFFFFFFFFFFFFEh fffff80198b0800a 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:
fffff80198b0800e f0490fc100 lock xadd qword ptr [r8],rax ds:002b:0000000000000000=???

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:xxxxx@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:
fffff800090620f0 4883c108 add rcx,8 fffff800090620f4 48ff25fd950200 jmp qword ptr
[FLTMGR!_imp_ExReleaseRundownProtection (fffff8000908b6f8)] fffff800090620fb 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 0xffffe00053b87230 _FLT_INSTANCE FLTMGR!_FLT_INSTANCE +0x000 Base : _FLT_OBJECT +0x030 OperationRundownRef : (null) +0x038 Volume : 0xffffe00053a3c7e0 _FLT_VOLUME
+0x040 Filter : (null)
+0x048 Flags : 2 ( INSFL_DELETING )
+0x050 Altitude : _UNICODE_STRING “260620”
+0x060 Name : _UNICODE_STRING “mydriver”
+0x070 FilterLink : _LIST_ENTRY [ 0x0000000000000000 - 0xffffe0005397ec40 ]
+0x080 ContextLock : _EX_PUSH_LOCK
+0x088 Context : (null)
+0x090 TransactionContexts : _CONTEXT_LIST_CTRL
+0x098 TrackCompletionNodes : (null)
+0x0a0 CallbackNodes : [50] (null)

kd> dt 0xffffe00053b87230 _FLT_OBJECT FLTMGR!_FLT_OBJECT +0x000 Flags : 0x1000003 (No matching name) +0x004 PointerCount : 2 +0x008 RundownRef : _EX_RUNDOWN_REF +0x010 PrimaryLink : _LIST_ENTRY [ 0xffffe00053b8a5f0 -
0xffffe000`53b83b10 ]
+0x020 UniqueIdentifier : _GUID {00000000-0000-0000-0000-000000000000}

kd> dt 0xffffe00053b87230+8 _EX_RUNDOWN_REF FLTMGR!_EX_RUNDOWN_REF +0x000 Count : 1 +0x000 Ptr : 0x0000000000000001 Void

kd> u nt!ExfReleaseRundownProtection nt!ExfReleaseRundownProtection+2f
nt!ExfReleaseRundownProtection:
fffff80198b07fe0 4883ec28 sub rsp,28h fffff80198b07fe4 0f0d09 prefetchw [rcx]
fffff80198b07fe7 4c8b01 mov r8,qword ptr [rcx] fffff80198b07fea 41f6c001 test r8b,1
fffff80198b07fee 7516 jne nt!ExfReleaseRundownProtection+0x26 (fffff80198b08006)
fffff80198b07ff0 498d50fe lea rdx,[r8-2] fffff80198b07ff4 498bc0 mov rax,r8
fffff80198b07ff7 f0480fb111 lock cmpxchg qword ptr [rcx],rdx fffff80198b07ffc 4c8bc0 mov r8,rax
fffff80198b07fff 7531 jne nt!ExfReleaseRundownProtection+0x52 (fffff80198b08032)
fffff80198b08001 4883c428 add rsp,28h fffff80198b08005 c3 ret
fffff80198b08006 4983e0fe and r8,0FFFFFFFFFFFFFFFEh fffff80198b0800a 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:
fffff80198b0800e f0490fc100 lock xadd qword ptr [r8],rax ds:002b:0000000000000000=???

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 ??

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, 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
> crash ??
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
>


Bercea. G.</http:>