Hi,
In the IRP_MJ_WRITE distpatch routine of my FSD, I call CcSetFileSizes to notify the CM that the file sizes are being changed.
Before calling CcSetFileSizes I already lock the main resource exclusively. However CcSetFileSizes made a call resulting in calling back to the FSD’s IRP_MJ_CLOSE on the same file as the write request. The close distpatch also tries to acquire the main resource exclusively: a deadlock is encountered even the second attempt is in the same thread context as the first one.
Any means to avoid this deadlock situation other than use ExIsResourceAcquiredExclusiveLite check before actual lock?
Am I doing anything wrong to make CM to close the file reference during a write request?
Following is the stack track:
f58bf6d8 8011750b 80953840 8095367c 00000000 nt!KiSwapThread+0xc5
f58bf6fc 8010906d 80954e08 00000000 00000000 nt!KeWaitForSingleObject+0x1b3
f58bf72c 801086f4 8095367c 80954e08 f58bf7b4 nt!ExpWaitForResource+0x29
f58bf748 80108739 f3c87c9c 8095367c 80953601 nt!ExpAcquireResourceExclusiveLite+0x5e
f58bf74c f3c87c9c 8095367c 80953601 8095a508 nt!ExAcquireResourceExclusiveLite+0x35
f58bf7b4 f3c92c1f 00000001 00000001 00000001 lilyfs!LLFsd_File::Lock+0x4c
f58bf84c f3c849b5 80953648 8095a508 80991d30 lilyfs!LLFsd_Workspace::CloseFile+0x8f
f58bf900 f3c825e1 80954c68 8095a508 80991d30 lilyfs!LLFsd_Driver::CloseFile+0x155
f58bf964 80111b3f 80991d30 8095a508 8095a508 lilyfs!LLFsdClose+0xb1
f58bf978 801152f8 80b27f40 8096a284 00000000 nt!IofCallDriver+0x37
f58bf9c4 8018de22 8096a288 f58bfa24 8096a270 nt!IopDeleteFile+0x164
f58bf9dc 80134ceb 8096a288 e140d06c e140d008 nt!ObpRemoveObjectRoutine+0xcc
f58bf9f4 8011fbd4 00000000 80953aa8 00000001 nt!ObfDereferenceObject+0xa5
f58bfa24 801207ad e140d008 80953ae0 e140d16c nt!MiSegmentDelete+0x146
f58bfa40 80123a78 80953aa8 00000000 8bfaec00 nt!MiCheckControlArea+0x1d7
f58bfa94 80105e4c 80953670 f58bfb28 00000000 nt!MmPurgeSection+0x3ac
f58bfaec 80105bfe 80953670 f58bfb28 00000000 nt!CcPurgeCacheSection+0x112
f58bfb70 f3c8832c 80954168 80953658 8096baa8 nt!CcSetFileSizes+0x3c0
f58bfcb8 f3c85396 80954168 00136700 00000001 lilyfs!LLFsd_File::Write+0x5dc
f58bfda0 f3c9180a 80954ca8 8096baa8 80991d30 lilyfs!LLFsd_Driver::Write+0x176
f58bfe08 80111b3f 80991d30 8096baa8 8095322c lilyfs!LLFsdWrite+0xda
f58bfe1c 8016f67c 8096bab0 001367d0 00000000 nt!IofCallDriver+0x37
f58bfe38 8016dfae 80991d30 8096baa8 80954168 nt!IopSynchronousServiceTail+0x6a
f58bfed8 8013e394 00000064 00000000 00000000 nt!NtWriteFile+0x720
f58bfed8 77f6830b 00000064 00000000 00000000 nt!KiSystemService+0xc4
0012fbc8 00000000 00000000 00000000 00000000 NTDLL!NtWriteFile+0xb
Thanks a lot.
Lijun
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
There is a bug in my code that the write distpatch did not lock the resource exclusively. I guess the same thread can lock the resource multiple times as long as it try to lock it in the same mode…
Happy new year.
Thanks.
Lijun Wang wrote:
Hi,
In the IRP_MJ_WRITE distpatch routine of my FSD, I call CcSetFileSizes to notify the CM that the file sizes are being changed.
Before calling CcSetFileSizes I already lock the main resource exclusively. However CcSetFileSizes made a call resulting in calling back to the FSD’s IRP_MJ_CLOSE on the same file as the write request. The close distpatch also tries to acquire the main resource exclusively: a deadlock is encountered even the second attempt is in the same thread context as the first one.
Any means to avoid this deadlock situation other than use ExIsResourceAcquiredExclusiveLite check before actual lock?
Am I doing anything wrong to make CM to close the file reference during a write request?
Following is the stack track:
f58bf6d8 8011750b 80953840 8095367c 00000000 nt!KiSwapThread+0xc5
f58bf6fc 8010906d 80954e08 00000000 00000000 nt!KeWaitForSingleObject+0x1b3
f58bf72c 801086f4 8095367c 80954e08 f58bf7b4 nt!ExpWaitForResource+0x29
f58bf748 80108739 f3c87c9c 8095367c 80953601 nt!ExpAcquireResourceExclusiveLite+0x5e
f58bf74c f3c87c9c 8095367c 80953601 8095a508 nt!ExAcquireResourceExclusiveLite+0x35
f58bf7b4 f3c92c1f 00000001 00000001 00000001 lilyfs!LLFsd_File::Lock+0x4c
f58bf84c f3c849b5 80953648 8095a508 80991d30 lilyfs!LLFsd_Workspace::CloseFile+0x8f
f58bf900 f3c825e1 80954c68 8095a508 80991d30 lilyfs!LLFsd_Driver::CloseFile+0x155
f58bf964 80111b3f 80991d30 8095a508 8095a508 lilyfs!LLFsdClose+0xb1
f58bf978 801152f8 80b27f40 8096a284 00000000 nt!IofCallDriver+0x37
f58bf9c4 8018de22 8096a288 f58bfa24 8096a270 nt!IopDeleteFile+0x164
f58bf9dc 80134ceb 8096a288 e140d06c e140d008 nt!ObpRemoveObjectRoutine+0xcc
f58bf9f4 8011fbd4 00000000 80953aa8 00000001 nt!ObfDereferenceObject+0xa5
f58ba24 801207ad e140d008 80953ae0 e140d16c nt!MiSegmentDelete+0x146
f58bfa40 80123a78 80953aa8 00000000 8bfaec00 nt!MiCheckControlArea+0x1d7
f58bfa94 80105e4c 80953670 f58bfb28 00000000 nt!MmPurgeSection+0x3ac
f58bfaec 80105bfe 80953670 f58bfb28 00000000 nt!CcPurgeCacheSection+0x112
f58bfb70 f3c8832c 80954168 80953658 8096baa8 nt!CcSetFileSizes+0x3c0
f58bfcb8 f3c85396 80954168 00136700 00000001 lilyfs!LLFsd_File::Write+0x5dc
f58bfda0 f3c9180a 80954ca8 8096baa8 80991d30 lilyfs!LLFsd_Driver::Write+0x176
f58bfe08 80111b3f 80991d30 8096baa8 8095322c lilyfs!LLFsdWrite+0xda
f58bfe1c 8016f67c 8096bab0 001367d0 00000000 nt!IofCallDriver+0x37
f58bfe38 8016dfae 80991d30 8096baa8 80954168 nt!IopSynchronousServiceTail+0x6a
f58bfed8 8013e394 00000064 00000000 00000000 nt!NtWriteFile+0x720
f58bfed8 77f6830b 00000064 00000000 00000000 nt!KiSystemService+0xc4
0012fbc8 00000000 00000000 00000000 00000000 NTDLL!NtWriteFile+0xb
Thanks a lot.
Lijun
---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now — You are currently subscribed to ntfsd as: xxxxx@yahoo.com To unsubscribe send a blank email to xxxxx@lists.osr.com
---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
Curious: do you use C++ to write your FSD? What did you use as the
C++ run-time wrapper?
–
Kind regards, Dejan M. www.alfasp.com
E-mail: xxxxx@alfasp.com ICQ#: 56570367
Alfa File Monitor - File monitoring library for Win32 developers.
Alfa File Protector - File protection and hiding library for Win32
developers.
Yes, I am using C++ in the FSD. Actually Micrsoft has a page on how to use C++ with driver development:
http://msdn.microsoft.com/archive/en-us/dnardevice/html/msdn_ntcpp.asp?frame=true
OSR has a similar page
http://www.osr.com/ntinsider/1999/global.htm
It does not support regular C++ exception though. One has to use SEH.
Lijun
Dejan Maksimovic wrote:
Curious: do you use C++ to write your FSD? What did you use as the
C++ run-time wrapper?
–
Kind regards, Dejan M. www.alfasp.com
E-mail: xxxxx@alfasp.com ICQ#: 56570367
Alfa File Monitor - File monitoring library for Win32 developers.
Alfa File Protector - File protection and hiding library for Win32
developers.
—
You are currently subscribed to ntfsd as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now