Anyway calling ZwCreateFile from under a mutex is not so good a design. The
mutex is locked for a long time, which lovers the scalability and performance.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Amitabh Mathrawala”
To: “Windows File Systems Devs Interest List”
Sent: Friday, January 13, 2006 2:05 AM
Subject: RE: [SPAM] - Re:[ntfsd] [SPAM] - Re:IRQL_NOT_LESS_OR_EQUAL because of
ExReleaseFastMutex - Bayesian Filter detected spam - Bayesian Filter detected
spam
No worries. Yes, the problem disappeared when I used regular mutexes.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
Sent: Thursday, January 12, 2006 3:03 PM
To: Windows File Systems Devs Interest List
Subject: [SPAM] - Re:[ntfsd] [SPAM] - Re:IRQL_NOT_LESS_OR_EQUAL because
of ExReleaseFastMutex - Bayesian Filter detected spam - Bayesian Filter
detected spam
My bad I was a bit sarcastic. Last year I had this very problem in some
driver code I inherited I hope your problem has dissapeared now.
“Amitabh Mathrawala” wrote in message
news:xxxxx@ntfsd…
Allright. I deserve this drubbing. Yes, I was confused between fast
mutex and resource. I thought of them as the same thing. Moreover, the
crash seemed to happen during the call to ExReleaseFastMutex, hence I
focused on resolving the mutex problem and wasn’t thinking about the Zw
functions. I should have used regular mutexes and not fast mutexes. I
fell for this line in the DDK “For better performance, use the
ExXxxFastMutex routines instead of the KeXxxMutex routines.” and did not
read the documentation for fast mutexes carefully.
Thanks a lot for your help.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
Sent: Thursday, January 12, 2006 1:12 PM
To: Windows File Systems Devs Interest List
Subject: [SPAM] - Re:[ntfsd] IRQL_NOT_LESS_OR_EQUAL because of
ExReleaseFastMutex - Bayesian Filter detected spam
Oh dear. I think you need to take some courses in the basics of kernel
mode
and driver development. You might also want to re-evaluate your approach
and
plan for an increase in the amount of time you spend on examination of
the
documentation.
You call ZwCreateFile after you have called ExAcquireFastMutex. Now the
documentation for ExFastMutex is quite clear “ExAcquireFastMutex sets
the
IRQL to APC_LEVEL, and the caller continues to run at APC_LEVEL after
ExAcquireFastMutex returns.” and the documentation for ZwCreateFile is
quite
clear “Callers of ZwCreateFile must be running at IRQL = PASSIVE_LEVEL
and
with APCs enabled.”. The documentation for KeEnterCriticalRegion is also
quite clear “The KeEnterCriticalRegion routine temporarily disables the
delivery of normal kernel APCs; special kernel-mode APCs are still
delivered.” but anyway it is not needed to call KeEnterCriticalRegion in
order to call ExAcquireFastMutex - are you confused between fast mutex
and
resource? These are both described in the wdf/ifs/ddk documentation!
“Amitabh Mathrawala” wrote in message
news:xxxxx@ntfsd…
Hi.
Could you please steer me in the right direction or tell me what could
be going wrong here ? I have a Pseudo FS driver and below is an
approximate code snippet from my driver. Below that is the crash I am
getting repeatedly on most machines but not all. I am trying to protect
“ccb->cache” and I feel like I am doing the right thing by wrapping
ExAcquire/Release resource by KeEnterCriticalRegion. Still getting the
crash. I am reasonably confident that (&fcb->OpenCloseMutex) has good
value. Please help me in understanding what could be going on.
Thanks.
KeEnterCriticalRegion();
ExAcquireFastMutex(&fcb->OpenCloseMutex);
//
// Open the cached file, to redirect I/O (ZwXxx) to the corresp.
filesystem (NTFS, etc.)
//
status = ZwCreateFile (&cache, FILE_READ_DATA | FILE_WRITE_DATA |
SYNCHRONIZE, &attr, &iosb, 0,
FILE_ATTRIBUTE_HIDDEN, FILE_SHARE_READ |
FILE_SHARE_WRITE | FILE_SHARE_DELETE,
FILE_OPEN_IF, options |
FILE_WRITE_THROUGH |
FILE_SYNCHRONOUS_IO_ALERT, NULL, 0);
ZwQueryInformationFile (ccb->cache, &iosb, (PVOID)&fend, sizeof
(fend), FileStandardInformation);
file.size = fcb->FileSize = fend.EndOfFile;
}
print (1, “Current IRQL right after getting size %x\n”,
(long)KeGetCurrentIrql());
ExReleaseFastMutex(&fcb->OpenCloseMutex);
KeLeaveCriticalRegion();
kd> !analyze -v
***********************************************************
Bugcheck Analysis
*****************************************************************
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address
at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0000003e, memory referenced
Arg2: 0000001c, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 804e5deb, address which referenced memory
Debugging Details:
------------------
OVERLAPPED_MODULE: rdbss
READ_ADDRESS: 0000003e
CURRENT_IRQL: 1c
FAULTING_IP:
nt!KeSetEvent+32
804e5deb 66394616 cmp [esi+0x16],ax
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0xA
LAST_CONTROL_TRANSFER: from 804ecdf2 to 804e5deb
IRP_ADDRESS: 822a9bd0
DEVICE_OBJECT: 8235a020
DRIVER_OBJECT: 8236c030
IMAGE_NAME: VkFSDrv.SYS
DEBUG_FLR_IMAGE_TIMESTAMP: 43c5ac64
MODULE_NAME: VkFSDrv
FAULTING_MODULE: f83a5000 Ntfs
TRAP_FRAME: f4409508 – (.trap fffffffff4409508)
ErrCode = 00000000
eax=00000001 ebx=822a9b01 ecx=f440918c edx=00000000 esi=00000028
edi=badb0d00
eip=804e5deb esp=f440957c ebp=f4409588 iopl=0 nv up ei pl nz na
po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010206
nt!KeSetEvent+0x32:
804e5deb 66394616 cmp [esi+0x16],ax
Resetting default scope
STACK_TEXT:
f4409588 804ecdf2 f440918c 00000000 00000000 nt!KeSetEvent+0x32
f44095e4 804ecd6a 822a9c10 f4409630 f4409624 nt!IopCompleteRequest+0x232
f4409634 806ffef2 00000000 00000000 f440964c nt!KiDeliverApc+0xb3
f4409634 806ff99a 00000000 00000000 f440964c hal!HalpApcInterrupt+0xc6
f44096bc f37154b9 819b4b40 819b4ac0 00000002 hal!ExReleaseFastMutex+0x26
f4409878 f372a535 819b4ac0 00130196 819b4ac0 VkFSDrv!open+0xb59
[c:\viack\via3\src\vkfsdrv\vkfsdrvrdr.cpp @ 1366]
f44098cc f372acd5 819b4ac0 00000004 e18fd548
VkFSDrv!RxCollapseOrCreateSrvOpen+0xf4
[d:\xpsp1\base\fs\rdr2\rdbss\create.c @ 1700]
f4409930 f372b7ba 819b4ac0 f440997c 82249158
VkFSDrv!RxCreateFromNetRoot+0x2ba [d:\xpsp1\base\fs\rdr2\rdbss\create.c
@ 2243]
f4409990 f371adce 819b4ac0 81bad998 f371fa10
VkFSDrv!RxCommonCreate+0x2df [d:\xpsp1\base\fs\rdr2\rdbss\create.c @
3254]
f4409a34 f37211bb f371fa10 82249100 822491c8
VkFSDrv!RxFsdCommonDispatch+0x333 [d:\xpsp1\base\fs\rdr2\rdbss\ntfsd.c @
784]
f4409a5c 804e13d9 819a9738 82249100 82249158 VkFSDrv!RxFsdDispatch+0xd9
[d:\xpsp1\base\fs\rdr2\rdbss\ntfsd.c @ 443]
f4409a6c 8057ccc7 819a9720 81f9b57c f4409c04 nt!IopfCallDriver+0x31
f4409b4c 8056c063 819a9738 00000000 81f9b4d8 nt!IopParseDevice+0xa58
f4409bc4 8056f2a8 00000000 f4409c04 00000040
nt!ObpLookupObjectName+0x53c
f4409c18 8057d2d3 00000000 00000000 b4e33001 nt!ObOpenObjectByName+0xea
f4409c94 8057d3a2 02b4e378 40110080 02b4e298 nt!IopCreateFile+0x407
f4409cf0 8057d3e5 02b4e378 40110080 02b4e298 nt!IoCreateFile+0x8e
f4409d30 804dd99f 02b4e378 40110080 02b4e298 nt!NtCreateFile+0x30
f4409d30 7c90eb94 02b4e378 40110080 02b4e298 nt!KiFastCallEntry+0xfc
02b4e0cc 7c90d68e 7c82f4ca 02b4e378 40110080 ntdll!KiFastSystemCallRet
02b4e0d0 7c82f4ca 02b4e378 40110080 02b4e298 ntdll!NtCreateFile+0xc
02b4e7cc 7c82eec5 01bd2084 000007c0 80000000
kernel32!BaseCopyStream+0x6fe
02b4ebdc 7c82f02b 01bd2084 01bd228c 7ca6c068
kernel32!BasepCopyFileExW+0x62f
02b4ec38 7ca6c291 01bd2084 01bd228c 7ca6c068 kernel32!CopyFileExW+0x39
02b4ee98 7ca6d407 01bd1f90 01bd2084 01bd228c SHELL32!FileCopy+0x1ba
02b4f0e4 7ca6f98a 01bd1f90 01bd2084 01bd228c SHELL32!DoFile_Copy+0xf0
02b4f824 7ca6fd45 01bd1f90 00000000 01bb6ad8
SHELL32!MoveCopyDriver+0x480
02b4f868 7cadb0cb 00000000 01bcabc4 01bd6524
SHELL32!SHFileOperationW+0x17b
02b4fcdc 7cadb3e9 01bd6524 01bcabc4 01bbe4f8
SHELL32!CFSDropTarget::_MoveCopy+0x1ff
02b4ff34 7cadb48f 01bd6524 01bcabc4 00000000
SHELL32!CFSDropTarget::_DoDrop+0x270
02b4ff50 77f74292 01bcabc4 00090778 00090000
SHELL32!CFSDropTarget::_DoDropThreadProc+0x46
02b4ffb4 7c80b50b 00000000 00090778 00090000
SHLWAPI!WrapperThreadProc+0x94
02b4ffec 00000000 77f74223 01eee964 00000000
kernel32!BaseThreadStart+0x37
FOLLOWUP_IP:
VkFSDrv!open+b59 [c:\viack\via3\src\vkfsdrv\vkfsdrvrdr.cpp @ 1366]
f37154b9 ff150cf171f3 call dword ptr
[VkFSDrv!_imp__KeLeaveCriticalRegion (f371f10c)]
SYMBOL_STACK_INDEX: 5
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: VkFSDrv!open+b59
STACK_COMMAND: .trap fffffffff4409508 ; kb
FAILURE_BUCKET_ID: 0xA_VkFSDrv!open+b59
BUCKET_ID: 0xA_VkFSDrv!open+b59
Followup: MachineOwner
---------
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@viack.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@viack.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com