CreateFile call hangs?

Rajesh_Gupta · February 7, 2011, 4:38pm

Hi All,

In my driver, i have register a callback for “LoadImage”. When my callback is called, i spawn a worker thread and try to open the file using “IoCreateFileSpecifyDeviceObjectHint” function call, as i don’t want this request to go up the stack. When this call goes down the stack this thread swaps out and. When i dumped the stack and event details, its waiting for the event which never gets signaled.

System Info. Windows 7 x64 bit system. This works fine on most of the systems, but on one particular Windows 7 system its causing issues. Any help would be greatly appreciated.

thanks

Here is the stack trace and event details.

*** Stack trace for last set context - .thread/.cxr resets it
Child-SP RetAddr Call Site
fffff88006344de0 fffff80002aa7ba2 nt!KiSwapContext+0x7a
fffff88006344f20 fffff80002aaa1ce nt!KiCommitThreadWait+0x1d2
fffff88006344fb0 fffff88001485149 nt!KeWaitForSingleObject+0x18e
fffff88006345050 fffff880014bdd8b Ntfs!NtfsWaitForCreateEvent+0x49
fffff88006345090 fffff88000e037df Ntfs!NtfsFsdCreate+0x43b
fffff88006345240 fffff88000e222b9 fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
fffff880063452d0 fffff80002d92dd7 fltmgr!FltpCreate+0x2a9
fffff88006345380 fffff80002d908f5 nt!IopParseDevice+0x5a7
fffff88006345510 fffff80002d91486 nt!ObpLookupObjectName+0x565
fffff88006345610 fffff80002d91e24 nt!ObOpenObjectByName+0x306
fffff880063456e0 fffff80002d3e3b7 nt!IopCreateFile+0x1f4
fffff88006345780 fffff80002d145c5 nt!IoCreateFileEx+0xe7
fffff88006345810 fffff88001221dd9 nt!IoCreateFileSpecifyDeviceObjectHint+0xe5
fffff880063458c0 fffff880012338d7 vgmt!CreateFile+0xe9 [f:\scratch\vor_4.4.1_dse_rel_4_4_1_branch_2011.01.31.10.06.46\fspem\vss\windows\lib\srvc\vsfile.cpp @ 370]
fffff880063459a0 fffff8800124ad3d vgmt!vm_os_open_file+0xbf [f:\scratch\vor_4.4.1_dse_rel_4_4_1_branch_2011.01.31.10.06.46\fspem\vmcore\os\vm_os_windows_file.c @ 250]
fffff880063459e0 fffff8800124bafb vgmt!vm_sign_file+0x51 [f:\scratch\vor_4.4.1_dse_rel_4_4_1_branch_2011.01.31.10.06.46\fspem\vmcore\sig\vm_sign.c @ 426]
fffff88006345a40 fffff8800121ac71 vgmt!vmfs_sigcache_sign+0xbb [f:\scratch\vor_4.4.1_dse_rel_4_4_1_branch_2011.01.31.10.06.46\fspem\vmcore\sig\vm_sigcache.c @ 130]
fffff88006345ac0 fffff8800121b0cb vgmt!VmLoadImage+0x23d [f:\scratch\vor_4.4.1_dse_rel_4_4_1_branch_2011.01.31.10.06.46\fspem\vss\windows\drv\src\vmprocess.cpp @ 210]
fffff88006345bd0 fffff80002d8252b vgmt!VmLoadImageCallbackAtPassiveLevel+0xab [f:\scratch\vor_4.4.1_dse_rel_4_4_1_branch_2011.01.31.10.06.46\fspem\vss\windows\drv\src\vmprocess.cpp @ 362]
fffff88006345c80 fffff80002aa93b1 nt!IopProcessWorkItem+0x23

Thread is waiting for the following event to be signaled, which never gets signaled.

dt nt!_DISPATCHER_HEADER fffff88003d6e1b8
+0x000 Type : 0 ‘’
+0x001 TimerControlFlags : 0 ‘’
+0x001 Absolute : 0y0
+0x001 Coalescable : 0y0
+0x001 KeepShifting : 0y0
+0x001 EncodedTolerableDelay : 0y00000 (0)
+0x001 Abandoned : 0 ‘’
+0x001 Signalling : 0 ‘’
+0x002 ThreadControlFlags : 0x6 ‘’
+0x002 CpuThrottled : 0y0
+0x002 CycleProfiling : 0y1
+0x002 CounterProfiling : 0y1
+0x002 Reserved : 0y00000 (0)
+0x002 Hand : 0x6 ‘’
+0x002 Size : 0x6 ‘’
+0x003 TimerMiscFlags : 0x1c ‘’
+0x003 Index : 0y011100 (0x1c)
+0x003 Inserted : 0y0
+0x003 Expired : 0y0
+0x003 DebugActive : 0x1c ‘’
+0x003 ActiveDR7 : 0y0
+0x003 Instrumented : 0y0
+0x003 Reserved2 : 0y0111
+0x003 UmsScheduled : 0y0
+0x003 UmsPrimary : 0y0
+0x003 DpcActive : 0x1c ‘’
+0x000 Lock : 0x1c060000
+0x004 SignalState : 0
+0x008 WaitListHead : _LIST_ENTRY [0xfffffa800ce24c68 - 0xfffffa800ce24c68]

Here are the thread details

THREAD fffffa800ce24b60 Cid 0004.0018 Teb: 0000000000000000 Win32Thread: 0000000000000000 WAIT: (Executive) UserMode Non-Alertable
fffff88003d6e1b8 NotificationEvent
IRP List:
fffffa800ecd6880: (0006,03a0) Flags: 00000884 Mdl: 00000000
Impersonation token: fffff8a000004b40 (Level Impersonation)
Owning Process fffffa800cd97190 Image: System
Attached Process N/A Image: N/A
Wait Start TickCount 62752 Ticks: 5734603 (1:00:51:00.380)
Context Switch Count 683 NoStackSwap
UserTime 00:00:00.000
KernelTime 00:00:00.046
Win32 Start Address nt!ExpWorkerThread (0xfffff80002aa92a0)
Stack Init fffff88003d6edb0 Current fffff88003d6dda0
Base fffff88003d6f000 Limit fffff88003d69000 Call 0
Priority 14 BasePriority 13 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
Child-SP RetAddr : Args to Child : Call Site
fffff88003d6dde0 fffff80002aa7ba2 : fffff80002a1d000 fffffa800ce24b60 fffffa8000000001 fffff880025e5000 : nt!KiSwapContext+0x7a
fffff88003d6df20 fffff80002aaa1ce : 0000000000000001 fffff6fc40012ef0 fffffa8000000000 80000004211b7963 : nt!KiCommitThreadWait+0x1d2
fffff88003d6dfb0 fffff88001485149 : 0000000000000000 0000000000000000 fffffa800ec84501 fffffa800ecd6800 : nt!KeWaitForSingleObject+0x18e
fffff88003d6e050 fffff880014bdd8b : 0000000000000103 fffff88003d6e280 fffffa800ecd6880 fffffa800ecd6880 : Ntfs!NtfsWaitForCreateEvent+0x49
fffff88003d6e090 fffff88000e037df : fffffa800e191030 fffffa800ecd6880 fffff88003d6e400 fffffa800e172501 : Ntfs!NtfsFsdCreate+0x43b
fffff88003d6e240 fffff88000e222b9 : fffffa800ecd6880 fffffa800e18e550 fffffa800ecd6800 fffffa800e172510 : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
fffff88003d6e2d0 fffff80002d92dd7 : 0000000000000004 fffff80002d92830 fffffa801c99c010 0000000000000000 : fltmgr!FltpCreate+0x2a9
fffff88003d6e380 fffff80002d908f5 : fffffa800de51940 0000000000000000 fffffa800e15eb10 000000001d060000 : nt!IopParseDevice+0x5a7
fffff88003d6e510 fffff80002d91486 : 0000000000000000 fffff88003d6e690 fffffa800e15eb10 fffffa800cdb74b0 : nt!ObpLookupObjectName+0x565
fffff88003d6e610 fffff80002d91e24 : fffffa800ce24b60 0000000000000001 fffffa800ce24b00 fffff80002d85800 : nt!ObOpenObjectByName+0x306
fffff88003d6e6e0 fffff80002d3e3b7 : fffff88003d6ea10 fffffa8080000000 0000000000000000 fffff88003d6e940 : nt!IopCreateFile+0x1f4
fffff88003d6e780 fffff80002d145c5 : 0000000080000000 fffff88003d6e960 0000000000000000 0000000000000000 : nt!IoCreateFileEx+0xe7
fffff88003d6e810 fffff88001221dd9 : 0000000000000001 0000000000000000 0000000080000000 fffff88003d6ea10 : nt!IoCreateFileSpecifyDeviceObjectHint+0xe5
fffff88003d6e8c0 fffff880012338d7 : fffffa801c9c1be0 00000000ffffffff fffffa801d247f20 fffffa801c9c1be0 : vgmt!CreateFile+0xe9 [f:\scratch\vor_4.4.1_dse_rel_4_4_1_branch_2011.01.31.10.06.46\fspem\vss\windows\lib\srvc\vsfile.cpp @ 370]
fffff88003d6e9a0 fffff8800124ad3d : 0000000000000000 fffff88003d6ea60 00000000ffffffff 0000000000000000 : vgmt!vm_os_open_file+0xbf [f:\scratch\vor_4.4.1_dse_rel_4_4_1_branch_2011.01.31.10.06.46\fspem\vmcore\os\vm_os_windows_file.c @ 250]
fffff88003d6e9e0 fffff8800124bafb : fffffa801c9c1be0 0000000000000000 0000000000000029 00000000000007ff : vgmt!vm_sign_file+0x51 [f:\scratch\vor_4.4.1_dse_rel_4_4_1_branch_2011.01.31.10.06.46\fspem\vmcore\sig\vm_sign.c @ 426]
fffff88003d6ea40 fffff8800121ac71 : fffffa800ee2eb20 fffff88001280d90 fffffa800ee2eb20 0000000000000000 : vgmt!vmfs_sigcache_sign+0xbb [f:\scratch\vor_4.4.1_dse_rel_4_4_1_branch_2011.01.31.10.06.46\fspem\vmcore\sig\vm_sigcache.c @ 130]
fffff88003d6eac0 fffff8800121b0cb : fffffa800ee2eb20 fffff80002c35600 fffff80002c35600 000000000000064c : vgmt!VmLoadImage+0x23d [f:\scratch\vor_4.4.1_dse_rel_4_4_1_branch_2011.01.31.10.06.46\fspem\vss\windows\drv\src\vmprocess.cpp @ 210]
fffff88003d6ebd0 fffff80002d8252b : fffffa800cdde360 0000000000000001 fffffa800ce24b60 fffffa800ce24b60 : vgmt!VmLoadImageCallbackAtPassiveLevel+0xab [f:\scratch\vor_4.4.1_dse_rel_4_4_1_branch_2011.01.31.10.06.46\fspem\vss\windows\drv\src\vmprocess.cpp @ 362]
fffff88003d6ec80 fffff80002aa93b1 : fffff80002c35600 fffff80002d82501 fffffa800ce24b00 0000000000000000 : nt!IopProcessWorkItem+0x23
fffff88003d6ecb0 fffff80002d37512 : 0000000000000000 fffffa800ce24b60 0000000000000080 fffffa800cd97190 : nt!ExpWorkerThread+0x111
fffff88003d6ed40 fffff80002a8fae6 : fffff880036b1180 fffffa800ce24b60 fffff880036bc4c0 0000000000000000 : nt!PspSystemThreadStartup+0x5a
fffff88003d6ed80 0000000000000000 : fffff88003d6f000 fffff88003d69000 fffff88003d6dc60 0000000000000000 : nt!KxStartSystemThread+0x16

I have seen few thread regarding this issue and they have the similar stack trace. But no one posted the solution. They discussed that thread i waiting for the oplock to get released which never gets released.

Its a worked thread and not blocking the “LoadImage” callback function call.

What is the issue here? Am i breaking any FileSystem rule here which opening this file?

Don_Burn_1 · February 7, 2011, 5:15pm

Congratulations, you are trying to open a file that is already open to
be mapped, so yes you are going to hang.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“xxxxx@gmail.com” wrote in message news:xxxxx@ntfsd:

> Hi All,
>
> In my driver, i have register a callback for “LoadImage”. When my callback is called, i spawn a worker thread and try to open the file using “IoCreateFileSpecifyDeviceObjectHint” function call, as i don’t want this request to go up the stack. When this call goes down the stack this thread swaps out and. When i dumped the stack and event details, its waiting for the event which never gets signaled.
>
> System Info. Windows 7 x64 bit system. This works fine on most of the systems, but on one particular Windows 7 system its causing issues. Any help would be greatly appreciated.
>
> thanks
>
>
> Here is the stack trace and event details.
>
>
> *** Stack trace for last set context - .thread/.cxr resets it
> Child-SP RetAddr Call Site
> fffff88006344de0 fffff80002aa7ba2 nt!KiSwapContext+0x7a
> fffff88006344f20 fffff80002aaa1ce nt!KiCommitThreadWait+0x1d2
> fffff88006344fb0 fffff88001485149 nt!KeWaitForSingleObject+0x18e
> fffff88006345050 fffff880014bdd8b Ntfs!NtfsWaitForCreateEvent+0x49
> fffff88006345090 fffff88000e037df Ntfs!NtfsFsdCreate+0x43b
> fffff88006345240 fffff88000e222b9 fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
> fffff880063452d0 fffff80002d92dd7 fltmgr!FltpCreate+0x2a9
> fffff88006345380 fffff80002d908f5 nt!IopParseDevice+0x5a7
> fffff88006345510 fffff80002d91486 nt!ObpLookupObjectName+0x565
> fffff88006345610 fffff80002d91e24 nt!ObOpenObjectByName+0x306
> fffff880063456e0 fffff80002d3e3b7 nt!IopCreateFile+0x1f4
> fffff88006345780 fffff80002d145c5 nt!IoCreateFileEx+0xe7
> fffff88006345810 fffff88001221dd9 nt!IoCreateFileSpecifyDeviceObjectHint+0xe5
> fffff880063458c0 fffff880012338d7 vgmt!CreateFile+0xe9 [f:\scratch\vor_4.4.1_dse_rel_4_4_1_branch_2011.01.31.10.06.46\fspem\vss\windows\lib\srvc\vsfile.cpp @ 370]
> fffff880063459a0 fffff8800124ad3d vgmt!vm_os_open_file+0xbf [f:\scratch\vor_4.4.1_dse_rel_4_4_1_branch_2011.01.31.10.06.46\fspem\vmcore\os\vm_os_windows_file.c @ 250]
> fffff880063459e0 fffff8800124bafb vgmt!vm_sign_file+0x51 [f:\scratch\vor_4.4.1_dse_rel_4_4_1_branch_2011.01.31.10.06.46\fspem\vmcore\sig\vm_sign.c @ 426]
> fffff88006345a40 fffff8800121ac71 vgmt!vmfs_sigcache_sign+0xbb [f:\scratch\vor_4.4.1_dse_rel_4_4_1_branch_2011.01.31.10.06.46\fspem\vmcore\sig\vm_sigcache.c @ 130]
> fffff88006345ac0 fffff8800121b0cb vgmt!VmLoadImage+0x23d [f:\scratch\vor_4.4.1_dse_rel_4_4_1_branch_2011.01.31.10.06.46\fspem\vss\windows\drv\src\vmprocess.cpp @ 210]
> fffff88006345bd0 fffff80002d8252b vgmt!VmLoadImageCallbackAtPassiveLevel+0xab [f:\scratch\vor_4.4.1_dse_rel_4_4_1_branch_2011.01.31.10.06.46\fspem\vss\windows\drv\src\vmprocess.cpp @ 362]
> fffff88006345c80 fffff80002aa93b1 nt!IopProcessWorkItem+0x23
>
>
> Thread is waiting for the following event to be signaled, which never gets signaled.
>
> dt nt!_DISPATCHER_HEADER fffff88003d6e1b8
> +0x000 Type : 0 ‘’
> +0x001 TimerControlFlags : 0 ‘’
> +0x001 Absolute : 0y0
> +0x001 Coalescable : 0y0
> +0x001 KeepShifting : 0y0
> +0x001 EncodedTolerableDelay : 0y00000 (0)
> +0x001 Abandoned : 0 ‘’
> +0x001 Signalling : 0 ‘’
> +0x002 ThreadControlFlags : 0x6 ‘’
> +0x002 CpuThrottled : 0y0
> +0x002 CycleProfiling : 0y1
> +0x002 CounterProfiling : 0y1
> +0x002 Reserved : 0y00000 (0)
> +0x002 Hand : 0x6 ‘’
> +0x002 Size : 0x6 ‘’
> +0x003 TimerMiscFlags : 0x1c ‘’
> +0x003 Index : 0y011100 (0x1c)
> +0x003 Inserted : 0y0
> +0x003 Expired : 0y0
> +0x003 DebugActive : 0x1c ‘’
> +0x003 ActiveDR7 : 0y0
> +0x003 Instrumented : 0y0
> +0x003 Reserved2 : 0y0111
> +0x003 UmsScheduled : 0y0
> +0x003 UmsPrimary : 0y0
> +0x003 DpcActive : 0x1c ‘’
> +0x000 Lock : 0x1c060000
> +0x004 SignalState : 0
> +0x008 WaitListHead : _LIST_ENTRY [0xfffffa800ce24c68 - 0xfffffa800ce24c68]
>
>
> Here are the thread details
>
> THREAD fffffa800ce24b60 Cid 0004.0018 Teb: 0000000000000000 Win32Thread: 0000000000000000 WAIT: (Executive) UserMode Non-Alertable
> fffff88003d6e1b8 NotificationEvent
> IRP List:
> fffffa800ecd6880: (0006,03a0) Flags: 00000884 Mdl: 00000000
> Impersonation token: fffff8a000004b40 (Level Impersonation)
> Owning Process fffffa800cd97190 Image: System
> Attached Process N/A Image: N/A
> Wait Start TickCount 62752 Ticks: 5734603 (1:00:51:00.380)
> Context Switch Count 683 NoStackSwap
> UserTime 00:00:00.000
> KernelTime 00:00:00.046
> Win32 Start Address nt!ExpWorkerThread (0xfffff80002aa92a0)
> Stack Init fffff88003d6edb0 Current fffff88003d6dda0
> Base fffff88003d6f000 Limit fffff88003d69000 Call 0
> Priority 14 BasePriority 13 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
> Child-SP RetAddr : Args to Child : Call Site
> fffff88003d6dde0 fffff80002aa7ba2 : fffff80002a1d000 fffffa800ce24b60 fffffa8000000001 fffff880025e5000 : nt!KiSwapContext+0x7a
> fffff88003d6df20 fffff80002aaa1ce : 0000000000000001 fffff6fc40012ef0 fffffa8000000000 80000004211b7963 : nt!KiCommitThreadWait+0x1d2
> fffff88003d6dfb0 fffff88001485149 : 0000000000000000 0000000000000000 fffffa800ec84501 fffffa800ecd6800 : nt!KeWaitForSingleObject+0x18e
> fffff88003d6e050 fffff880014bdd8b : 0000000000000103 fffff88003d6e280 fffffa800ecd6880 fffffa800ecd6880 : Ntfs!NtfsWaitForCreateEvent+0x49
> fffff88003d6e090 fffff88000e037df : fffffa800e191030 fffffa800ecd6880 fffff88003d6e400 fffffa800e172501 : Ntfs!NtfsFsdCreate+0x43b
> fffff88003d6e240 fffff88000e222b9 : fffffa800ecd6880 fffffa800e18e550 fffffa800ecd6800 fffffa800e172510 : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
> fffff88003d6e2d0 fffff80002d92dd7 : 0000000000000004 fffff80002d92830 fffffa801c99c010 0000000000000000 : fltmgr!FltpCreate+0x2a9
> fffff88003d6e380 fffff80002d908f5 : fffffa800de51940 0000000000000000 fffffa800e15eb10 000000001d060000 : nt!IopParseDevice+0x5a7
> fffff88003d6e510 fffff80002d91486 : 0000000000000000 fffff88003d6e690 fffffa800e15eb10 fffffa800cdb74b0 : nt!ObpLookupObjectName+0x565
> fffff88003d6e610 fffff80002d91e24 : fffffa800ce24b60 0000000000000001 fffffa800ce24b00 fffff80002d85800 : nt!ObOpenObjectByName+0x306
> fffff88003d6e6e0 fffff80002d3e3b7 : fffff88003d6ea10 fffffa8080000000 0000000000000000 fffff88003d6e940 : nt!IopCreateFile+0x1f4
> fffff88003d6e780 fffff80002d145c5 : 0000000080000000 fffff88003d6e960 0000000000000000 0000000000000000 : nt!IoCreateFileEx+0xe7
> fffff88003d6e810 fffff88001221dd9 : 0000000000000001 0000000000000000 0000000080000000 fffff88003d6ea10 : nt!IoCreateFileSpecifyDeviceObjectHint+0xe5
> fffff88003d6e8c0 fffff880012338d7 : fffffa801c9c1be0 00000000ffffffff fffffa801d247f20 fffffa801c9c1be0 : vgmt!CreateFile+0xe9 [f:\scratch\vor_4.4.1_dse_rel_4_4_1_branch_2011.01.31.10.06.46\fspem\vss\windows\lib\srvc\vsfile.cpp @ 370]
> fffff88003d6e9a0 fffff8800124ad3d : 0000000000000000 fffff88003d6ea60 00000000ffffffff 0000000000000000 : vgmt!vm_os_open_file+0xbf [f:\scratch\vor_4.4.1_dse_rel_4_4_1_branch_2011.01.31.10.06.46\fspem\vmcore\os\vm_os_windows_file.c @ 250]
> fffff88003d6e9e0 fffff8800124bafb : fffffa801c9c1be0 0000000000000000 0000000000000029 00000000000007ff : vgmt!vm_sign_file+0x51 [f:\scratch\vor_4.4.1_dse_rel_4_4_1_branch_2011.01.31.10.06.46\fspem\vmcore\sig\vm_sign.c @ 426]
> fffff88003d6ea40 fffff8800121ac71 : fffffa800ee2eb20 fffff88001280d90 fffffa800ee2eb20 0000000000000000 : vgmt!vmfs_sigcache_sign+0xbb [f:\scratch\vor_4.4.1_dse_rel_4_4_1_branch_2011.01.31.10.06.46\fspem\vmcore\sig\vm_sigcache.c @ 130]
> fffff88003d6eac0 fffff8800121b0cb : fffffa800ee2eb20 fffff80002c35600 fffff80002c35600 000000000000064c : vgmt!VmLoadImage+0x23d [f:\scratch\vor_4.4.1_dse_rel_4_4_1_branch_2011.01.31.10.06.46\fspem\vss\windows\drv\src\vmprocess.cpp @ 210]
> fffff88003d6ebd0 fffff80002d8252b : fffffa800cdde360 0000000000000001 fffffa800ce24b60 fffffa800ce24b60 : vgmt!VmLoadImageCallbackAtPassiveLevel+0xab [f:\scratch\vor_4.4.1_dse_rel_4_4_1_branch_2011.01.31.10.06.46\fspem\vss\windows\drv\src\vmprocess.cpp @ 362]
> fffff88003d6ec80 fffff80002aa93b1 : fffff80002c35600 fffff80002d82501 fffffa800ce24b00 0000000000000000 : nt!IopProcessWorkItem+0x23
> fffff88003d6ecb0 fffff80002d37512 : 0000000000000000 fffffa800ce24b60 0000000000000080 fffffa800cd97190 : nt!ExpWorkerThread+0x111
> fffff88003d6ed40 fffff80002a8fae6 : fffff880036b1180 fffffa800ce24b60 fffff880036bc4c0 0000000000000000 : nt!PspSystemThreadStartup+0x5a
> fffff88003d6ed80 0000000000000000 : fffff88003d6f000 fffff88003d69000 fffff88003d6dc60 0000000000000000 : nt!KxStartSystemThread+0x16
>
>
> I have seen few thread regarding this issue and they have the similar stack trace. But no one posted the solution. They discussed that thread i waiting for the oplock to get released which never gets released.
>
> Its a worked thread and not blocking the “LoadImage” callback function call.
>
> What is the issue here? Am i breaking any FileSystem rule here which opening this file?

Rajesh_Gupta · February 7, 2011, 5:53pm

Don,

Thanks a lot for quick reply.

Don, Would you mind explaining it in more details? Sorry i didn’t get why this would hang the thread?

Just for curiosity, how did you find out from the stack that the file is mapped and How can we handle this scenario, if we need to open the file?

thanks

Don_Burn_1 · February 7, 2011, 7:04pm

I did not find from the stack, I’ve answered questions about the
callback before using the shared source access that DDK MVP’s have, so I
know that the callback is well into the steps for loading the module.
There are techniques for opening the file with
IoCreateFileSpecifyDeviceObjectHint you need to use minimal rights and
IO_IGNORE_SHARE_ACCESS_CHECK.

Don

“xxxxx@gmail.com” wrote in message news:xxxxx@ntfsd:

> Don,
>
> Thanks a lot for quick reply.
>
> Don, Would you mind explaining it in more details? Sorry i didn’t get why this would hang the thread?
>
> Just for curiosity, how did you find out from the stack that the file is mapped and How can we handle this scenario, if we need to open the file?
>
> thanks

Rajesh_Gupta · February 7, 2011, 7:30pm

Thanks Don.

This is exactly what i am doing. These are my parameters to open the
file and i have min rights.

Status = IoCreateFileSpecifyDeviceObjectHint(fhandle,DesiredAccess,
&initializedAttributes,&ioSB,NULL,FILE_ATTRIBUTE_NORMAL,
ShareAccess, disposition,CreateOptions | FILE_SYNCHRONOUS_IO_NONALERT,
NULL,0,CreateFileTypeNone,NULL,IO_IGNORE_SHARE_ACCESS_CHECK,
NULL);

There are the parameters to
DesiredAccess = GENERIC_READ
ShareAccess = FILE_SHARE_READ
disposition = FILE_OPEN

I am also specifying IO_IGNORE_SHARE_ACCESS_CHECK.

thanks

On 2/7/2011 4:03 PM, Don Burn wrote:

I did not find from the stack, I’ve answered questions about the
callback before using the shared source access that DDK MVP’s have, so I
know that the callback is well into the steps for loading the module.
There are techniques for opening the file with
IoCreateFileSpecifyDeviceObjectHint you need to use minimal rights and
IO_IGNORE_SHARE_ACCESS_CHECK.

Don

Rajesh_Gupta · February 11, 2011, 8:22pm

Hi Don,

Sorry to open this thread again. I was trying out few things before asking new question, so i will have the better understanding. This is what i understood so far from your comments above.

The file is already open to be mapped by the system and i am trying to issue another CreateFile. This is the reason my thread hangs. Even though i am launching the another worker thread and issuing the “CreateFile” from that worker thread. The system didn’t close the file yet.

It seems file is opened exclusively by system during LoadImage. if i understood correctly from name of the function name on the stack “NtfsWaitForCreateEvent”, that it is blocking this thread till Create/LoadImage is finished? Once the System Loads the image or closes the file why it doesn’t signal the event and let my thread open the file? Is this some Windows bug or this is the restriction they have?
If multiple threads are are launching the same process at the same time, so seems like system protects it. User/another thread can launch the same process during this Windows again, isn’t it?

I gave min access (“read_data” only) and “IO_IGNORE_SHARE_ACCESS_CHECK”, but it didn’t help.

One of the solution i was thinking about it, if i track close and open of the file and don’t issue the “CreateFile” from the worker thread if file is already open.

I am just trying to understand what exactly is happening in the system so i can look for the correct solution.

I really appreciate it.
thanks