hung in nt!NtQueryDirectoryFile

Wang_Xin · May 10, 2013, 6:47am

Hi, I have a driver. It caused the the software autocad to hung when opening a file from network disk. If my driver ignore IRP_MJ_DIRECTORY_CONTROL, then no hung happens.

I did some debugging, but still no clue about it. what I understand are:

it seems no deadlock
it seems the software is waiting for completion of cancel operation. but it never happen.

Could you kindly give me some help?

Thanks,
Xin

1: kd> !THREAD 895f3020
THREAD 895f3020 Cid 08e4.081c Teb: 7ffdd000 Win32Thread: e45cdc60 WAIT: (Executive) KernelMode Non-Alertable
895df524 NotificationEvent
IRP List:
8963d400: (0006,01d8) Flags: 00000800 Mdl: 89604b80
Not impersonating
DeviceMap e6d69bb0
Owning Process 0 Image:
Attached Process 895bc900 Image: acad.exe
Wait Start TickCount 323078 Ticks: 28836 (0:00:07:30.562)
Context Switch Count 8941 IdealProcessor: 0 LargeStack
UserTime 00:00:00.812
KernelTime 00:00:01.203
Win32 Start Address 0x00a89e50
Start Address 0x7c8106b5
Stack Init b553c000 Current b553bc78 Base b553c000 Limit b5539000 Call 0
Priority 10 BasePriority 8 PriorityDecrement 0 DecrementCount 16
ChildEBP RetAddr Args to Child
b553bc90 8050480e 895f3090 895f3020 804fc042 nt!KiSwapContext+0x2f (FPO: [Uses EBP] [0,0,4])
b553bcc4 8057db0a 00000000 00000000 00000000 nt!KiSwapThread+0x8a (FPO: [0,0,0])
b553bcf0 8057f8b3 005df524 8963d400 b553bd64 nt!IopCancelAlertedRequest+0x68 (FPO: [Non-Fpo])
b553bd0c 80579dcb 89f822e0 00000103 895df4c8 nt!IopSynchronousServiceTail+0x103 (FPO: [Non-Fpo])
b553bd30 805423fc 00000518 00000000 00000000 nt!NtQueryDirectoryFile+0x5d (FPO: [Non-Fpo])
b553bd30 7c92eb94 00000518 00000000 00000000 nt!KiFastCallEntry+0xfc (FPO: [0,0] TrapFrame @ b553bd64)
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012e8f4 00000000 00000000 00000000 00000000 0x7c92eb94

1: kd> .thread 895f3020
Implicit thread is now 895f3020

1: kd> kv
Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr Args to Child
b553bc90 8050480e 895f3090 895f3020 804fc042 nt!KiSwapContext+0x2f (FPO: [Uses EBP] [0,0,4])
b553bcc4 8057db0a 00000000 00000000 00000000 nt!KiSwapThread+0x8a (FPO: [0,0,0])
b553bcf0 8057f8b3 005df524 8963d400 b553bd64 nt!IopCancelAlertedRequest+0x68 (FPO: [Non-Fpo])
b553bd0c 80579dcb 89f822e0 00000103 895df4c8 nt!IopSynchronousServiceTail+0x103 (FPO: [Non-Fpo])
b553bd30 805423fc 00000518 00000000 00000000 nt!NtQueryDirectoryFile+0x5d (FPO: [Non-Fpo])
b553bd30 7c92eb94 00000518 00000000 00000000 nt!KiFastCallEntry+0xfc (FPO: [0,0] TrapFrame @ b553bd64)
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012e8f4 00000000 00000000 00000000 00000000 0x7c92eb94
1: kd> !irp 895df4c8
IRP signature does not match, probably not an IRP. Use any flag to force.
1: kd> !irp b553bd64
IRP signature does not match, probably not an IRP. Use any flag to force.
1: kd> !irp 8963d400
Irp is active with 5 stacks 7 is current (= 0x8963d548)
Mdl=89604b80: No System Buffer: Thread 895f3020: Irp is completed.
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[c, 0] 0 0 8a6593b8 00000000 ba5d97de-89ab7ad8
\FileSystem\MRxSmb fltMgr!FltpPassThroughCompletion
Args: 00000000 00000000 00000000 00000000
[c, 0] 0 0 8a810820 00000000 ba57c77a-b553bc7c
\FileSystem\FltMgr twayblade
Args: 00000000 00000000 00000000 00000000
[c, 0] 0 0 89fa3e80 00000000 00000000-00000000
\FileSystem\twayblade
Args: 00000000 00000000 00000000 00000000
1: kd> !irp 8963d400 1
Irp is active with 5 stacks 7 is current (= 0x8963d548)
Mdl=89604b80: No System Buffer: Thread 895f3020: Irp is completed.
Flags = 00000800
ThreadListEntry.Flink = 895f3230
ThreadListEntry.Blink = 895f3230
IoStatus.Status = 00000000
IoStatus.Information = 00000098
RequestorMode = 00000001
Cancel = 01
CancelIrql = 0
ApcEnvironment = 00
UserIosb = 0012e658
UserEvent = 00000000
Overlay.AsynchronousParameters.UserApcRoutine = 00000000
Overlay.AsynchronousParameters.UserApcContext = 00000000
Overlay.AllocationSize = 00000000 - 00000000
CancelRoutine = 00000000
UserBuffer = 0012e688
&Tail.Overlay.DeviceQueueEntry = 8963d440
Tail.Overlay.Thread = 895f3020
Tail.Overlay.AuxiliaryBuffer = 00000000
Tail.Overlay.ListEntry.Flink = 00000000
Tail.Overlay.ListEntry.Blink = 00000000
Tail.Overlay.CurrentStackLocation = 8963d548
Tail.Overlay.OriginalFileObject = 895df4c8
Tail.Apc = 00000000
Tail.CompletionKey = 00000000
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[c, 0] 0 0 8a6593b8 00000000 ba5d97de-89ab7ad8
\FileSystem\MRxSmb fltMgr!FltpPassThroughCompletion
Args: 00000000 00000000 00000000 00000000
[c, 0] 0 0 8a810820 00000000 ba57c77a-b553bc7c
\FileSystem\FltMgr twayblade
Args: 00000000 00000000 00000000 00000000
[c, 0] 0 0 89fa3e80 00000000 00000000-00000000
\FileSystem\twayblade
Args: 00000000 00000000 00000000 00000000

1: kd> !locks
* DUMP OF ALL RESOURCE OBJECTS
KD: Scanning for held locks…

Resource @ 0x899a0278 Shared 1 owning threads
Threads: 8a888833-01<> Actual Thread 8a888830

Resource @ 0x8998b7d0 Shared 1 owning threads
Threads: 8a888833-01<> Actual Thread 8a888830
KD: Scanning for held locks…

Resource @ 0x89c7d7e8 Shared 1 owning threads
Threads: 8a888d23-01<> Actual Thread 8a888d20
KD: Scanning for held locks…

Resource @ 0x89b17588 Shared 1 owning threads
Threads: 8a888aab-01<> Actual Thread 8a888aa8
KD: Scanning for held locks.

Resource @ 0x89a1b8e0 Shared 1 owning threads
Threads: 89c665c3-01<> Actual Thread 89c665c0
KD: Scanning for held locks.
23292 total locks, 5 locks currently held
1: kd> !locks -v 0x899a0278

Resource @ 0x899a0278 Shared 1 owning threads
Threads: 8a888833-01<*> *** Actual Thread 8a888830

THREAD 8a888830 Cid 0004.0018 Teb: 00000000 Win32Thread: 00000000 WAIT: (WrQueue) UserMode Non-Alertable
80564820 Unknown
Not impersonating
DeviceMap e1000130
Owning Process 0 Image:
Attached Process 8a8899c8 Image: System
Wait Start TickCount 351908 Ticks: 6 (0:00:00:00.093)
Context Switch Count 14118 IdealProcessor: 0
UserTime 00:00:00.000
KernelTime 00:00:00.109
Start Address nt!ExpWorkerThread (0x80539458)
Stack Init bace4000 Current bace3d24 Base bace4000 Limit bace1000 Call 0
Priority 13 BasePriority 13 PriorityDecrement 0 DecrementCount 16
ChildEBP RetAddr
bace3d3c 8050480e nt!KiSwapContext+0x2f (FPO: [Uses EBP] [0,0,4])
bace3d74 80539524 nt!KiSwapThread+0x8a (FPO: [0,0,0])
bace3dac 805cfc9e nt!ExpWorkerThread+0xcc (FPO: [Non-Fpo])
bace3ddc 80546ebe nt!PspSystemThreadStartup+0x34 (FPO: [Non-Fpo])
00000000 00000000 nt!KiThreadStartup+0x16

1 total locks, 1 locks currently held

Amritanshu_Johri · May 10, 2013, 8:48am

What do you mean by ignoring IRP_MJ_DIRECTORY_CONTROL? On what platform are
you seeing this problem?

You can try playing around with DirectoryCache of SMB to bypass any
headaches there.

rod_widdowson · May 11, 2013, 4:56am

Some random thoughts:

What does your completion routine for IRP_MJ_DIRECTORY_CONTROL do? Is it
returning the correct status? Are you obeying all the rules about
IoMarkIrpPending (there is an excellent article on OsrOnline which should be
read at least once a year)? Do you do anything with cancel processing if so
you *are* using Cancel safe queues aren’t you?

Wang_Xin · May 12, 2013, 11:32am

Hi Amritanshu,

The problem is seen in XP SP2. In the IRP_MJ_DIRECTORY_CONTROL handler, my driver monitors the file names from the returned buffer (post callback). If the a name is in the list open file list, it will manipulate the file size field in the buffer. My driver added a trailer in the encrypted file. The list is guarded with lock carefully.

Could you please kindly introduce some links about the “DirectoryCache of SMB”?

Thanks,
Xin

00000423 13.10819435 PreDirCtrl: streamh:89B35248, class: 3. Flag:8040, ;Z:0000000000018238\172.16.100.221\share\cgkfb\ITEM\02
00000424 13.10846615 [DocCrypto]!PostDirCtrl:infoClass=3,context=89B35248 , status=0, info=98, Irql=0, ctxFlag=8040
00000425 13.10846996 [DocCrypto]: Enter Post-DirCtrlWhenSafe(Cbd = 89C3FF5C, FileObject = 89B96B00)
00000426 13.10847569 [DocCrypto]!ScanDirInfo2, dir: \Device\LanmanRedirector\172.16.100.221\share\cgkfb\ITEM\02
00000427 24.20255280 PreDirCtrl: streamh:897138F8, class: 3. Flag:8040, \
00000428 24.20256996 [DocCrypto]!PostDirCtrl:infoClass=3,context=897138F8 , status=0, info=8a, Irql=0, ctxFlag=8040
00000429 24.20257378 [DocCrypto]: Enter Post-DirCtrlWhenSafe(Cbd = 89B15F5C, FileObject = 8A044B88)
00000430 24.20258141 [DocCrypto]!ScanDirInfo2, dir: \Device\HarddiskVolume1\
00000431 24.20273209 PreDirCtrl: streamh:89713898, class: 3. Flag:8040, \Documents and Settings
00000432 24.20274734 [DocCrypto]!PostDirCtrl:infoClass=3,context=89713898 , status=0, info=72, Irql=0, ctxFlag=8040
…
…
00000527 31.63788986 PreDirCtrl: streamh:89CA32C0, class: 3. Flag:8040, \WINDOWS\Fonts
00000528 31.63790703 [DocCrypto]!PostDirCtrl:C: newB=8968C000 No data read, status=80000006, info=0, class=3
00000529 31.63790703 [DocCrypto]!PostDirCtrl:C: newB=8968C000 info=0 Freeing (Here is the last line of log.)

Wang_Xin · May 12, 2013, 11:38am

Hi rod,

I explained what my driver do with IRP_MJ_DIRECTORY_CONTROL in the last post. It doesn’t initiate any cancel operation. However I am not sure if I did some thing wrong with calling FltDoCompletionProcessingWhenSafe().

Since disabling my code will make the problem disappear. I am going to try set some switches for finding out which code piece is relevant with this issue.

Thanks,
Xin

OSR_Community_User · May 12, 2013, 4:00pm

What does the debugger command"!apc" show?

Tony
OSR

Amritanshu_Johri · May 13, 2013, 12:33am

Xin,
you can have a look here, http://support.microsoft.com/kb/811169 , but I
guess you are getting the IRP back from SMB(?)

I noticed that the IRP in question at your end got completed and is not
really active right now so it seems Tony or Rod might be on mark here.

Regards,
Amritanshu

On Mon, May 13, 2013 at 1:28 AM, Tony Mason wrote:

> What does the debugger command"!apc" show?
>
> Tony
> OSR
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Wang_Xin · May 13, 2013, 3:21am

Hi Tony,

I pasted the result of executing “!apc” as below. It looks the problem is related with APCs. Any comments for helping the debugging going further?

1: kd> !APC
*** Enumerating APCs in all processes
Process 8a8899c8 System
Process 8a5185a0 smss.exe
Process 8a5acda0 csrss.exe
Process 8a709c08 winlogon.exe
Process 8a0392b8 services.exe
Process 8a02ba70 lsass.exe
Process 89fa2da0 svchost.exe
Process 89fd5498 svchost.exe
Process 89fa0020 svchost.exe
Process 89f7b020 svchost.exe
Process 89fd35c8 svchost.exe
Process 89f815c0 spoolsv.exe
Process 89f45020 CATSysDemon.exe
Process 89f453c8 stormliv.exe
Process 89f625c0 FileBackService
Process 89f46da0 DWRCS.EXE
Process 89ef4020 MDM.EXE
Process 89f0fb50 NTRtScan.exe
Process 89edada0 nvsvc32.exe
Process 89ecc6b0 svchost.exe
Process 89ecf020 svchost.exe
Process 89ed25d0 wdfmgr.exe
Process 89eb5b50 TmListen.exe
Process 89d9b928 alg.exe
Process 89cc85e8 DWRCST.EXE
Process 89d1d6b8 CNTAoSMgr.exe
Process 89e945b0 TMBMSRV.exe
Process 89b35338 DocService.exe
Process 895ba7c8 explorer.exe
Process 895bc900 acad.exe
Thread 895f3020 ApcStateIndex 0 ApcListHead 895f305c [USER]
KAPC @ 89bb4478
Type 12
KernelRoutine 805d24a2 nt!PsExitSpecialApc+0
RundownRoutine 805e7d0a nt!ExFreeCallBack+0
Process 899a5da0 AdskScSrv.exe
Process 89b1eba0 explorer.exe
Process 89a382a8 ??FeiQ.exe
Process 8960a020 SysTray2.exe
Process 895d4c58 MyFiles.exe
Process 899a88b8 PccNTMon.exe
Process 89e80020 ctfmon.exe
Process 8999d020 wmiprvse.exe
Process 89942020 NotMyfault.exe

1: kd> !thread 895f3020
THREAD 895f3020 Cid 08e4.081c Teb: 7ffdd000 Win32Thread: e45cdc60 WAIT: (Executive) KernelMode Non-Alertable
895df524 NotificationEvent
IRP List:
8963d400: (0006,01d8) Flags: 00000800 Mdl: 89604b80
Not impersonating
DeviceMap e6d69bb0
Owning Process 0 Image:
Attached Process 895bc900 Image: acad.exe
Wait Start TickCount 323078 Ticks: 28836 (0:00:07:30.562)
Context Switch Count 8941 IdealProcessor: 0 LargeStack
UserTime 00:00:00.812
KernelTime 00:00:01.203
Win32 Start Address 0x00a89e50
Start Address 0x7c8106b5
Stack Init b553c000 Current b553bc78 Base b553c000 Limit b5539000 Call 0
Priority 10 BasePriority 8 PriorityDecrement 0 DecrementCount 16
ChildEBP RetAddr Args to Child
b553bc90 8050480e 895f3090 895f3020 804fc042 nt!KiSwapContext+0x2f (FPO: [Uses EBP] [0,0,4])
b553bcc4 8057db0a 00000000 00000000 00000000 nt!KiSwapThread+0x8a (FPO: [0,0,0])
b553bcf0 8057f8b3 005df524 8963d400 b553bd64 nt!IopCancelAlertedRequest+0x68 (FPO: [Non-Fpo])
b553bd0c 80579dcb 89f822e0 00000103 895df4c8 nt!IopSynchronousServiceTail+0x103 (FPO: [Non-Fpo])
b553bd30 805423fc 00000518 00000000 00000000 nt!NtQueryDirectoryFile+0x5d (FPO: [Non-Fpo])
b553bd30 7c92eb94 00000518 00000000 00000000 nt!KiFastCallEntry+0xfc (FPO: [0,0] TrapFrame @ b553bd64)
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012e8f4 00000000 00000000 00000000 00000000 0x7c92eb94

1: kd> !APC thre 895f3020
Thread 895f3020 ApcStateIndex 0 ApcListHead 895f3054 [KERNEL]
Thread 895f3020 ApcStateIndex 0 ApcListHead 895f305c [USER]
KAPC @ 89bb4478
Type 12
KernelRoutine 805d24a2 nt!PsExitSpecialApc+0
RundownRoutine 805e7d0a nt!ExFreeCallBack+0

OSR_Community_User · May 13, 2013, 10:02am

Can you then look at the KTHREAD structure here? It will show you two vital things:

(1) The apc disable values (special kernel APC disable is of interest here); and
(2) The wait IRQL (specifically , if it is APC_LEVEL)

My best guess is that you have disabled APCs and either failed to re-enable them or issued this I/O operation with them disabled and that has in turn led to the stuck APC.

So something like “dt nt!_KTHREAD 895f3020” would do it.

But it sure looks like you have an APC management issue here (e.g., elevated IRQL or disabled special kernel APCs). And indeed going back to your original post, the suspicious bit is:

“Irp is completed”

Whenever you see a completed IRP where something is still blocked waiting for completion you should suspect an APC issue.

Do you use Fast Mutexes? Do you ever call KeEnterCriticalRegion (or FsRtlEnterFileSystem)?

If the wait IRQL is APC_LEVEL, look for a path where you don’t drop the fast mutex. If the special kernel APC disable field is non-zero, review your calls to KeEnterCriticalRegion/FsRtlEnterFileSystem - or rather, look for a missing KeLeaveCriticalRegion/FsRtlExitFileSystem call.

Tony
OSR

Wang_Xin · May 13, 2013, 9:14pm

Hi Tony,

Here is the status of the kernel thread. My code does call KeEnterCriticalRegion() in the path for checking whether file names in returned buffer in the open list, but it looks no way to miss calling KeLeaveCriticalRegion(). From the log, the IRQL is 0 every time.

1: kd> dt nt!_KTHREAD 895f3020
+0x000 Header : _DISPATCHER_HEADER
+0x010 MutantListHead : _LIST_ENTRY [0x895f3030 - 0x895f3030]
+0x018 InitialStack : 0xb553c000 Void
+0x01c StackLimit : 0xb5539000 Void
+0x020 Teb : 0x7ffdd000 Void
+0x024 TlsArray : (null)
+0x028 KernelStack : 0xb553bc78 Void
+0x02c DebugActive : 0 ‘’
+0x02d State : 0x5 ‘’
+0x02e Alerted : [2] “”
+0x030 Iopl : 0 ‘’
+0x031 NpxState : 0xa ‘’
+0x032 Saturation : 0 ‘’
+0x033 Priority : 10 ‘’
+0x034 ApcState : _KAPC_STATE
+0x04c ContextSwitches : 0x22ed
+0x050 IdleSwapBlock : 0 ‘’
+0x051 Spare0 : [3] “”
+0x054 WaitStatus : 0n0
+0x058 WaitIrql : 0 ‘’
+0x059 WaitMode : 0 ‘’
+0x05a WaitNext : 0 ‘’
+0x05b WaitReason : 0 ‘’
+0x05c WaitBlockList : 0x895f3090 _KWAIT_BLOCK
+0x060 WaitListEntry : _LIST_ENTRY [0x0 - 0x89b09080]
+0x060 SwapListEntry : _SINGLE_LIST_ENTRY
+0x068 WaitTime : 0x4ee06
+0x06c BasePriority : 8 ‘’
+0x06d DecrementCount : 0x10 ‘’
+0x06e PriorityDecrement : 0 ‘’
+0x06f Quantum : 4 ‘’
+0x070 WaitBlock : [4] _KWAIT_BLOCK
+0x0d0 LegoData : (null)
+0x0d4 KernelApcDisable : 0
+0x0d8 UserAffinity : 3
+0x0dc SystemAffinityActive : 0 ‘’
+0x0dd PowerState : 0 ‘’
+0x0de NpxIrql : 0 ‘’
+0x0df InitialNode : 0 ‘’
+0x0e0 ServiceTable : 0x8055c6c0 Void
+0x0e4 Queue : (null)
+0x0e8 ApcQueueLock : 0
+0x0f0 Timer : _KTIMER
+0x118 QueueListEntry : _LIST_ENTRY [0x0 - 0x0]
+0x120 SoftAffinity : 3
+0x124 Affinity : 3
+0x128 Preempted : 0 ‘’
+0x129 ProcessReadyQueue : 0 ‘’
+0x12a KernelStackResident : 0x1 ‘’
+0x12b NextProcessor : 0 ‘’
+0x12c CallbackStack : (null)
+0x130 Win32Thread : 0xe45cdc60 Void
+0x134 TrapFrame : 0xb553bd64 _KTRAP_FRAME
+0x138 ApcStatePointer : [2] 0x895f3054 _KAPC_STATE
+0x140 PreviousMode : 1 ‘’
+0x141 EnableStackSwap : 0x1 ‘’
+0x142 LargeStack : 0x1 ‘’
+0x143 ResourceIndex : 0x1 ‘’
+0x144 KernelTime : 0x4d
+0x148 UserTime : 0x34
+0x14c SavedApcState : _KAPC_STATE
+0x164 Alertable : 0 ‘’
+0x165 ApcStateIndex : 0 ‘’
+0x166 ApcQueueable : 0x1 ‘’
+0x167 AutoAlignment : 0 ‘’
+0x168 StackBase : 0xb553c000 Void
+0x16c SuspendApc : _KAPC
+0x19c SuspendSemaphore : _KSEMAPHORE
+0x1b0 ThreadListEntry : _LIST_ENTRY [0x895bc950 - 0x895bc950]
+0x1b8 FreezeCount : 0 ‘’
+0x1b9 SuspendCount : 0 ‘’
+0x1ba IdealProcessor : 0 ‘’
+0x1bb DisableBoost : 0 ‘’

BOOLEAN IsFileOpened(UNICODE_STRING * fileName, LARGE_INTEGER * pLen)
{
BOOLEAN bFoundDocOpen = FALSE;
PSTREAM_CTX_ENTRY pSCtxEntry = NULL;
LIST_ENTRY *pList = NULL;

if(fileName->Length == 0)
return FALSE;

KeEnterCriticalRegion();
if(!ExAcquireResourceSharedLite(&GblStreamCtxListResource, FALSE))
{
KeLeaveCriticalRegion();
return FALSE;;
}
if((!IsListEmpty(&GblStreamCtxList)))
{
pList = GblStreamCtxList.Flink;
while(pList != NULL && pList != (&GblStreamCtxList))
{
pSCtxEntry = CONTAINING_RECORD( pList, STREAM_CTX_ENTRY, ListEntry );
if(CompareStringFromEnd( fileName, &pSCtxEntry->pStreamCtx->FileName))
{
bFoundDocOpen = TRUE;

break;
}
pList = pList->Flink;
}
}
ExReleaseResourceLite(&GblStreamCtxListResource);
KeLeaveCriticalRegion();

return bFoundDocOpen;
}

1: kd> dt docCrypto!GblStreamCtxListResource
+0x000 SystemResourcesList : _LIST_ENTRY [0xb3e954a0 - 0x89b37b68]
+0x008 OwnerTable : (null)
+0x00c ActiveCount : 0n0
+0x00e Flag : 0
+0x010 SharedWaiters : (null)
+0x014 ExclusiveWaiters : (null)
+0x018 OwnerEntry : _OWNER_ENTRY
+0x020 ActiveEntries : 0
+0x024 ContentionCount : 0
+0x028 NumberOfSharedWaiters : 0
+0x02c NumberOfExclusiveWaiters : 0
+0x030 Address : (null)
+0x030 CreatorBackTraceIndex : 0
+0x034 SpinLock : 0

FLT_POSTOP_CALLBACK_STATUS
CryptoPostDirCtrlBuffersWhenSafe (
__inout PFLT_CALLBACK_DATA Data,
__in PCFLT_RELATED_OBJECTS FltObjects,
__in PVOID CompletionContext,
__in FLT_POST_OPERATION_FLAGS Flags
)
{
PFLT_IO_PARAMETER_BLOCK iopb = Data->Iopb;
PPRE_2_POST_CONTEXT p2pCtx = CompletionContext;
PVOID origBuf;
NTSTATUS status;

UNREFERENCED_PARAMETER( FltObjects );
UNREFERENCED_PARAMETER( Flags );
ASSERT(Data->IoStatus.Information != 0);

//
// This is some sort of user buffer without a MDL, lock the
// user buffer so we can access it
//

Trace( DEBUG_TRACE_DIRCTRL, L3,
(“[DocCrypto]: Enter Post-DirCtrlWhenSafe(Cbd = %p, FileObject = %p)\n”,
Data,
FltObjects->FileObject) );

status = FltLockUserBuffer( Data );

if (!NT_SUCCESS(status)) {

Trace( DEBUG_TRACE_DIRCTRL, L1,
(“[DocCrypto]!PostDirCtrlWhenSafe: %wZ Could not lock user buffer, oldB=%p, status=%x\n”,
&p2pCtx->VolCtx->Name,
iopb->Parameters.DirectoryControl.QueryDirectory.DirectoryBuffer,
status) );

//
// If we can’t lock the buffer, fail the operation
//

Data->IoStatus.Status = status;
Data->IoStatus.Information = 0;

} else {

//
// Get a system address for this buffer.
//

origBuf = MmGetSystemAddressForMdlSafe( iopb->Parameters.DirectoryControl.QueryDirectory.MdlAddress,
NormalPagePriority );

if (origBuf == NULL) {

Trace( DEBUG_TRACE_DIRCTRL,L1,
(“***[DocCrypto]!PostDirCtrlWhenSafe: %wZ Failed to get System address for MDL: %p\n”,
&p2pCtx->VolCtx->Name,
iopb->Parameters.DirectoryControl.QueryDirectory.MdlAddress) );

//
// If we couldn’t get a SYSTEM buffer address, fail the operation
//

Data->IoStatus.Status = STATUS_INSUFFICIENT_RESOURCES;
Data->IoStatus.Information = 0;

} else {

// this function calls IsFileOpen() for checking if any name in the open list
ScanDirInfo(Data,
FltObjects,
CompletionContext);

//
// Copy the data back to the original buffer
//
// NOTE: Due to a bug in FASTFAT where it is returning the wrong
// length in the information field (it is short) we are
// always going to copy the original buffer length.
//

RtlCopyMemory( origBuf,
p2pCtx->SwappedBuffer,
/*Data->IoStatus.Information*/
iopb->Parameters.DirectoryControl.QueryDirectory.Length );
}
}

//
// Free the memory we allocated and return
//

Trace( DEBUG_TRACE_SWAP_BUFFER,L3,
(“[DocCrypto]!PostDirCtrlWhenSafe: %wZ newB=%p info=%d Freeing\n”,
&p2pCtx->VolCtx->Name,
p2pCtx->SwappedBuffer,
Data->IoStatus.Information) );

ExFreePoolWithTag( p2pCtx->SwappedBuffer, BUFFER_SWAP_TAG );
FltReleaseContext( p2pCtx->VolCtx );
if(p2pCtx->Contex)
FltReleaseContext(p2pCtx->Contex);

ExFreeToNPagedLookasideList( &Pre2PostContextList,
p2pCtx );

return FLT_POSTOP_FINISHED_PROCESSING;
}

Wang_Xin · May 14, 2013, 7:35am

When I masked the function IsFileOpened(), the problem disappear. So it proved IsFileOpened() is problematic. However I don’t understand how it is causing problem yet. Any comments about it?