I am working on a mini-filter and am getting a hang in my PreRead callback
when IRP_PAGING_IO is present. I know that you cannot have pageable code
in this path, and as far as I know I do not. Basically, I call a function
to write data to another system, this code creates an IRP and issues a
write to another disk volume, then waits for the result. The wait pends
forever and the irp is never processed. The same code works fine in all
other cases.
Basically the code is:
irp = IoBuildSynchronousFsdRequest( IRP_MJ_WRITE, Globals.CommObj, buf,
len, off, &event, &iosb );
if ( irp != NULL )
{
KeInitializeEvent( &event, NotificationEvent, FALSE );
status = IoCallDriver( Globals.CommObj, irp );
if ( status == STATUS_PENDING )
{
status = KeWaitForSingleObject( &event, Executive,
KernelMode, FALSE, NULL );
}
Any suggestions would be appreciated.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
Not enough information. I do not know whether you receive read or write
request and do not know whether you write directly to the disk or using
FSD( cached or not ).
For example, if this is a write request and you use a file, then the FSD may
hang in CcCanIWrite because you stop the MPW thread or the lazy writer
thread and the number of dirty pages does not decrease.
–
Slava Imameyev, xxxxx@hotmail.com
“Don Burn” wrote in message news:xxxxx@ntfsd…
>I am working on a mini-filter and am getting a hang in my PreRead callback
>when IRP_PAGING_IO is present. I know that you cannot have pageable code
>in this path, and as far as I know I do not. Basically, I call a function
>to write data to another system, this code creates an IRP and issues a
>write to another disk volume, then waits for the result. The wait pends
>forever and the irp is never processed. The same code works fine in all
>other cases.
>
> Basically the code is:
>
> irp = IoBuildSynchronousFsdRequest( IRP_MJ_WRITE, Globals.CommObj, buf,
> len, off, &event, &iosb );
> if ( irp != NULL )
> {
> KeInitializeEvent( &event, NotificationEvent, FALSE );
> status = IoCallDriver( Globals.CommObj, irp );
> if ( status == STATUS_PENDING )
> {
> status = KeWaitForSingleObject( &event, Executive,
> KernelMode, FALSE, NULL );
> }
>
> Any suggestions would be appreciated.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> http://www.windrvr.com
> Remove StopSpam from the email to reply
>
>
>
>
My next guess - you stop the lazy writer thread, but actually this thread is
a system worker thread and the code which writes the buffer uses the same
worker thread, so deadlock.
–
Slava Imameyev, xxxxx@hotmail.com
“Slava Imameyev” wrote in message news:xxxxx@ntfsd…
> Not enough information. I do not know whether you receive read or write
> request and do not know whether you write directly to the disk or using
> FSD( cached or not ).
> For example, if this is a write request and you use a file, then the FSD
> may hang in CcCanIWrite because you stop the MPW thread or the lazy writer
> thread and the number of dirty pages does not decrease.
>
> –
> Slava Imameyev, xxxxx@hotmail.com
>
>
> “Don Burn” wrote in message news:xxxxx@ntfsd…
>>I am working on a mini-filter and am getting a hang in my PreRead callback
>>when IRP_PAGING_IO is present. I know that you cannot have pageable code
>>in this path, and as far as I know I do not. Basically, I call a function
>>to write data to another system, this code creates an IRP and issues a
>>write to another disk volume, then waits for the result. The wait pends
>>forever and the irp is never processed. The same code works fine in all
>>other cases.
>>
>> Basically the code is:
>>
>> irp = IoBuildSynchronousFsdRequest( IRP_MJ_WRITE, Globals.CommObj, buf,
>> len, off, &event, &iosb );
>> if ( irp != NULL )
>> {
>> KeInitializeEvent( &event, NotificationEvent, FALSE );
>> status = IoCallDriver( Globals.CommObj, irp );
>> if ( status == STATUS_PENDING )
>> {
>> status = KeWaitForSingleObject( &event, Executive,
>> KernelMode, FALSE, NULL );
>> }
>>
>> Any suggestions would be appreciated.
>>
>>
>> –
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> http://www.windrvr.com
>> Remove StopSpam from the email to reply
>>
>>
>>
>>
>
>
>
A deadlock is a good winner here, because you don’t bugcheck.
My idea would be that the problem is you’re transforming an asynchronous
request into a synchronous request. This can result in a deadlock since the
system is expecting an asynchronous behavior to do continue a different
processing…
–
EA
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-270440-
xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Sunday, November 19, 2006 20:12
To: Windows File Systems Devs Interest List
Subject: [ntfsd] IRP_PAGING_IO hang
I am working on a mini-filter and am getting a hang in my PreRead
callback when IRP_PAGING_IO is present. I know that you cannot have
pageable code in this path, and as far as I know I do not. Basically,
I call a function to write data to another system, this code creates an
IRP and issues a write to another disk volume, then waits for the
result. The wait pends forever and the irp is never processed. The
same code works fine in all other cases.
Basically the code is:
irp = IoBuildSynchronousFsdRequest( IRP_MJ_WRITE, Globals.CommObj,
buf, len, off, &event, &iosb ); if ( irp != NULL ) {
KeInitializeEvent( &event, NotificationEvent, FALSE );
status = IoCallDriver( Globals.CommObj, irp );
if ( status == STATUS_PENDING )
{
status = KeWaitForSingleObject( &event, Executive,
KernelMode, FALSE, NULL );
}
Any suggestions would be appreciated.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com Remove StopSpam from the email to reply
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@fausse.info
To unsubscribe send a blank email to xxxxx@lists.osr.com
Can we be sure this is never called at elevated IRQL ? I am writing this
because the documentation says nothing about it while for other callbacks
such as post operation callbacks the IRQ levels are very clearly described.
All the samples suggest that preoperation callbacks are called at lower IRQ,
but is this always true in every case or I mean is this written anywhere ?
Thanks,
/Daniel
“Don Burn” wrote in message news:xxxxx@ntfsd…
>I am working on a mini-filter and am getting a hang in my PreRead callback
>when IRP_PAGING_IO is present. I know that you cannot have pageable code
>in this path, and as far as I know I do not. Basically, I call a function
>to write data to another system, this code creates an IRP and issues a
>write to another disk volume, then waits for the result. The wait pends
>forever and the irp is never processed. The same code works fine in all
>other cases.
>
> Basically the code is:
>
> irp = IoBuildSynchronousFsdRequest( IRP_MJ_WRITE, Globals.CommObj, buf,
> len, off, &event, &iosb );
> if ( irp != NULL )
> {
> KeInitializeEvent( &event, NotificationEvent, FALSE );
> status = IoCallDriver( Globals.CommObj, irp );
> if ( status == STATUS_PENDING )
> {
> status = KeWaitForSingleObject( &event, Executive,
> KernelMode, FALSE, NULL );
> }
>
> Any suggestions would be appreciated.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> http://www.windrvr.com
> Remove StopSpam from the email to reply
>
>
>
>
By the way:
“Intermediate or highest-level drivers can call IoBuildSynchronousFsdRequest
to set up IRPs for requests sent to lower-level drivers, only if the caller
is running in a nonarbitrary thread context and at IRQL = PASSIVE_LEVEL.”
Certainly the reason of your problem.
–
EA
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-270440-
xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Sunday, November 19, 2006 20:12
To: Windows File Systems Devs Interest List
Subject: [ntfsd] IRP_PAGING_IO hang
I am working on a mini-filter and am getting a hang in my PreRead
callback when IRP_PAGING_IO is present. I know that you cannot have
pageable code in this path, and as far as I know I do not. Basically,
I call a function to write data to another system, this code creates an
IRP and issues a write to another disk volume, then waits for the
result. The wait pends forever and the irp is never processed. The
same code works fine in all other cases.
Basically the code is:
irp = IoBuildSynchronousFsdRequest( IRP_MJ_WRITE, Globals.CommObj,
buf, len, off, &event, &iosb ); if ( irp != NULL ) {
KeInitializeEvent( &event, NotificationEvent, FALSE );
status = IoCallDriver( Globals.CommObj, irp );
if ( status == STATUS_PENDING )
{
status = KeWaitForSingleObject( &event, Executive,
KernelMode, FALSE, NULL );
}
Any suggestions would be appreciated.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com Remove StopSpam from the email to reply
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@fausse.info
To unsubscribe send a blank email to xxxxx@lists.osr.com
To answer the various questions:
“Edouard A.” wrote in message news:xxxxx@ntfsd…
>A deadlock is a good winner here, because you don’t bugcheck.
>
> My idea would be that the problem is you’re transforming an asynchronous
> request into a synchronous request. This can result in a deadlock since
> the
> system is expecting an asynchronous behavior to do continue a different
> processing…
>
A deadlock is possible, but I sure don’t know why. This is not a case of
asynchronous versus synchronous, since this is an IRP based I/O and there
is no difference.
“Daniel Terhell” wrote in message
news:xxxxx@ntfsd…
> Can we be sure this is never called at elevated IRQL ? I am writing this
> because the documentation says nothing about it while for other callbacks
> such as post operation callbacks the IRQ levels are very clearly
> described. All the samples suggest that preoperation callbacks are called
> at lower IRQ, but is this always true in every case or I mean is this
> written anywhere ?
This is being called at APC level, the verifier is on so this would have
been caught if not at the right IRQL.
“Slava Imameyev” wrote in message
news:xxxxx@ntfsd…
> Not enough information. I do not know whether you receive read or write
> request and do not know whether you write directly to the disk or using
> FSD( cached or not ).
> For example, if this is a write request and you use a file, then the FSD
> may hang in CcCanIWrite because you stop the MPW thread or the lazy
> writer thread and the number of dirty pages does not decrease.
This is on the applications thread, and I am going directly to the disk.
This is a cached I/O read comming around the second time, to page into the
cache. See the stack trace below, my driver is fcfs:
ad04a024 8050017a 89204808 89204798 804f99be nt!KiSwapContext+0x2e (FPO:
[Uses EBP] [0,0,4])
ad04a030 804f99be 00000000 ad04a0b8 89b698ec nt!KiSwapThread+0x46 (FPO:
[0,0,0])
ad04a058 8064c966 00000000 00000000 00000000 nt!KeWaitForSingleObject+0x1c2
(FPO: [Non-Fpo])
ad04a080 ae2b892f ad04a0b8 00000000 00000000
nt!VerifierKeWaitForSingleObject+0x56 (FPO: [Non-Fpo])
ad04a0d4 ae2badee 88cdc400 00000200 ad04a0f8 fcfs!WriteComm+0x17f (FPO:
[Non-Fpo]) (CONV: stdcall) ad04a100 ae2bb242 8a6cae20 8a7ceb08 00000001
fcfs!SendPacket+0xee (FPO: [Non-Fpo]) (CONV: stdcall) ad04a11c ae2bd399
8a4d8fb8 89c36e58 00000000 fcfs!SendMessage+0x102 (FPO: [Non-Fpo]) (CONV:
stdcall)
ad04a130 ae2bd17c 8a962f80 89b698ec 89b2f570 fcfs!SendMapRequest+0x199
(FPO: [Non-Fpo]) (CONV: stdcall)
ad04a168 ae2bcdcb 8a962f80 00000000 ad04a190 fcfs!CheckFileMap+0x24c (FPO:
[Non-Fpo]) (CONV: stdcall)
ad04a178 ae2bcae3 8a962f80 00000003 8a962f80 fcfs!DirectRead+0x8b (FPO:
[Non-Fpo]) (CONV: stdcall)
ad04a190 ba698deb 89b698ec ad04a1dc ad04a20c fcfs!PreRead+0x133 (FPO:
[Non-Fpo]) (CONV: stdcall)
ad04a1bc ba680888 00000001 00000003 ad04a20c fltMgr!FltvPreOperation+0x3f
(FPO: [Non-Fpo])
ad04a21c ba6822a0 0004a264 00000000 ad04a264
fltMgr!FltpPerformPreCallbacks+0x2d4 (FPO: [Non-Fpo])
ad04a230 ba682c48 ad04a264 00000000 890b3638
fltMgr!FltpPassThroughInternal+0x32 (FPO: [Non-Fpo])
ad04a24c ba683059 ad04a201 89d21a01 89d5b100 fltMgr!FltpPassThrough+0x1c2
(FPO: [Non-Fpo])
ad04a27c 804eddf9 890b3638 8a4dce48 806d02e8 fltMgr!FltpDispatch+0x10d
(FPO: [Non-Fpo])
ad04a28c 8064b5a8 89ada810 00001000 89d21a28 nt!IopfCallDriver+0x31 (FPO:
[0,0,0])
ad04a2b0 804ee7c4 00000000 89d21a18 89d21a28 nt!IovCallDriver+0xa0 (FPO:
[Non-Fpo])
ad04a2c4 804ee7eb 890b3638 89d21a09 89d21a30 nt!IopPageReadInternal+0xf4
(FPO: [Non-Fpo])
ad04a2e4 8051286a 89ada810 89d21a50 89d21a30 nt!IoPageRead+0x1b (FPO:
[Non-Fpo])
ad04a360 8051bdd4 e1057010 cc601000 c0663008 nt!MiDispatchFault+0x286 (FPO:
[Non-Fpo])
ad04a3c4 8053f6ec 00000000 cc601000 00000000 nt!MmAccessFault+0x7b4 (FPO:
[Non-Fpo])
ad04a3c4 8055e4fb 00000000 cc601000 00000000 nt!KiTrap0E+0xcc (FPO: [0,0]
TrapFrame @ ad04a3dc)
ad04a49c ba5ef7cb 89ada810 ad04a4cc 00001000 nt!CcMapData+0xef (FPO:
[Non-Fpo])
ad04a4bc ba5f01be ad04a7e8 e1044d20 00001000 Ntfs!NtfsMapStream+0x46 (FPO:
[Non-Fpo])
ad04a4ec ba5f072b ad04a7e8 0000000c 00000001 Ntfs!ReadIndexBuffer+0x8a
(FPO: [Non-Fpo])
ad04a51c ba5f1c9a ad04a7e8 ad04a628 e21d9008 Ntfs!FindFirstIndexEntry+0x191
(FPO: [Non-Fpo])
ad04a564 ba5f1ded ad04a7e8 e1044d20 e21d9008 Ntfs!NtfsFindIndexEntry+0x48
(FPO: [Non-Fpo])
ad04a598 ba5f1b28 ad04a7e8 e1044d20 00000101 Ntfs!NtfsLookupEntry+0xa2
(FPO: [Non-Fpo])
ad04a7c4 ba5edf72 ad04a7e8 8a9eee48 ad04a918 Ntfs!NtfsCommonCreate+0x10c3
(FPO: [Non-Fpo])
ad04a970 ba674f70 8a9eee48 ad04ac00 88a9a020
Ntfs!NtfsNetworkOpenCreate+0x8a (FPO: [Non-Fpo])
ad04a990 ba6820e8 8a9eee48 ad04ac00 890c57c0 sr!SrFastIoQueryOpen+0x40
(FPO: [Non-Fpo])
ad04a9b0 ba68e927 000000f2 00000000 ad04a9e8
fltMgr!FltpPerformFastIoCall+0x300 (FPO: [Non-Fpo])
ad04aa08 805772b8 8a9eee48 ad04ac00 890b3638
fltMgr!FltpFastIoQueryOpen+0xa1 (FPO: [Non-Fpo])
ad04aaf4 805b3642 89159820 00000000 88e7d730 nt!IopParseDevice+0x95c (FPO:
[Non-Fpo])
ad04ab7c 805afb23 00000000 ad04abbc 00000040 nt!ObpLookupObjectName+0x56a
(FPO: [Non-Fpo])
ad04abd0 8056b0b9 00000000 00000000 00000001 nt!ObOpenObjectByName+0xeb
(FPO: [Non-Fpo])
ad04ad54 8053c808 0104fcb8 0104fc90 0104fce4 nt!NtQueryAttributesFile+0xf1
(FPO: [Non-Fpo])
ad04ad54 7c90eb94 0104fcb8 0104fc90 0104fce4 nt!KiFastCallEntry+0xf8 (FPO:
[0,0] TrapFrame @ ad04ad64)
0104fce4 00000000 00000000 00000000 00000000 ntdll!KiFastSystemCallRet
(FPO: [0,0,0])
“Edouard A.” wrote in message news:xxxxx@ntfsd…
> By the way:
>
> “Intermediate or highest-level drivers can call
> IoBuildSynchronousFsdRequest
> to set up IRPs for requests sent to lower-level drivers, only if the
> caller
> is running in a nonarbitrary thread context and at IRQL = PASSIVE_LEVEL.”
>
> Certainly the reason of your problem.
Sorry the documentation you are quoting is old, the current doc’s indicate:
“Callers of IoBuildSynchronousFsdRequest must be running at IRQL <=
APC_LEVEL.”
Thanks to everyone who answered, this is driving me nuts.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
>This can result in a deadlock since the
system is expecting an asynchronous behavior
System never requires asynchronous behavior for this case. The MPW and the
lazy writer threads can tolerate synchronous requests.
–
Slava Imameyev, xxxxx@hotmail.com
“Edouard A.” wrote in message news:xxxxx@ntfsd…
>A deadlock is a good winner here, because you don’t bugcheck.
>
> My idea would be that the problem is you’re transforming an asynchronous
> request into a synchronous request. This can result in a deadlock since
> the
> system is expecting an asynchronous behavior to do continue a different
> processing…
>
>
> –
>
> EA
>
>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com [mailto:bounce-270440-
>> xxxxx@lists.osr.com] On Behalf Of Don Burn
>> Sent: Sunday, November 19, 2006 20:12
>> To: Windows File Systems Devs Interest List
>> Subject: [ntfsd] IRP_PAGING_IO hang
>>
>> I am working on a mini-filter and am getting a hang in my PreRead
>> callback when IRP_PAGING_IO is present. I know that you cannot have
>> pageable code in this path, and as far as I know I do not. Basically,
>> I call a function to write data to another system, this code creates an
>> IRP and issues a write to another disk volume, then waits for the
>> result. The wait pends forever and the irp is never processed. The
>> same code works fine in all other cases.
>>
>> Basically the code is:
>>
>> irp = IoBuildSynchronousFsdRequest( IRP_MJ_WRITE, Globals.CommObj,
>> buf, len, off, &event, &iosb ); if ( irp != NULL ) {
>> KeInitializeEvent( &event, NotificationEvent, FALSE );
>> status = IoCallDriver( Globals.CommObj, irp );
>> if ( status == STATUS_PENDING )
>> {
>> status = KeWaitForSingleObject( &event, Executive,
>> KernelMode, FALSE, NULL );
>> }
>>
>> Any suggestions would be appreciated.
>>
>>
>> –
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> http://www.windrvr.com Remove StopSpam from the email to reply
>>
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@fausse.info
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> This is being called at APC level,
Don, read DDK’s article “Do wait threads receive Alerts and APCs”. You may
argue that paging request would be completed, but completion of paging
requests have special processing without APCs.
–
Slava Imameyev, xxxxx@hotmail.com
“Don Burn” wrote in message news:xxxxx@ntfsd…
> To answer the various questions:
>
> “Edouard A.” wrote in message news:xxxxx@ntfsd…
>>A deadlock is a good winner here, because you don’t bugcheck.
>>
>> My idea would be that the problem is you’re transforming an asynchronous
>> request into a synchronous request. This can result in a deadlock since
>> the
>> system is expecting an asynchronous behavior to do continue a different
>> processing…
>>
>
> A deadlock is possible, but I sure don’t know why. This is not a case of
> asynchronous versus synchronous, since this is an IRP based I/O and there
> is no difference.
>
> “Daniel Terhell” wrote in message
> news:xxxxx@ntfsd…
>> Can we be sure this is never called at elevated IRQL ? I am writing this
>> because the documentation says nothing about it while for other callbacks
>> such as post operation callbacks the IRQ levels are very clearly
>> described. All the samples suggest that preoperation callbacks are called
>> at lower IRQ, but is this always true in every case or I mean is this
>> written anywhere ?
>
> This is being called at APC level, the verifier is on so this would have
> been caught if not at the right IRQL.
>
> “Slava Imameyev” wrote in message
> news:xxxxx@ntfsd…
>> Not enough information. I do not know whether you receive read or write
>> request and do not know whether you write directly to the disk or using
>> FSD( cached or not ).
>> For example, if this is a write request and you use a file, then the FSD
>> may hang in CcCanIWrite because you stop the MPW thread or the lazy
>> writer thread and the number of dirty pages does not decrease.
>
> This is on the applications thread, and I am going directly to the disk.
> This is a cached I/O read comming around the second time, to page into the
> cache. See the stack trace below, my driver is fcfs:
>
> ad04a024 8050017a 89204808 89204798 804f99be nt!KiSwapContext+0x2e (FPO:
> [Uses EBP] [0,0,4])
> ad04a030 804f99be 00000000 ad04a0b8 89b698ec nt!KiSwapThread+0x46 (FPO:
> [0,0,0])
> ad04a058 8064c966 00000000 00000000 00000000
> nt!KeWaitForSingleObject+0x1c2 (FPO: [Non-Fpo])
> ad04a080 ae2b892f ad04a0b8 00000000 00000000
> nt!VerifierKeWaitForSingleObject+0x56 (FPO: [Non-Fpo])
> ad04a0d4 ae2badee 88cdc400 00000200 ad04a0f8 fcfs!WriteComm+0x17f (FPO:
> [Non-Fpo]) (CONV: stdcall) ad04a100 ae2bb242 8a6cae20 8a7ceb08 00000001
> fcfs!SendPacket+0xee (FPO: [Non-Fpo]) (CONV: stdcall) ad04a11c ae2bd399
> 8a4d8fb8 89c36e58 00000000 fcfs!SendMessage+0x102 (FPO: [Non-Fpo]) (CONV:
> stdcall)
> ad04a130 ae2bd17c 8a962f80 89b698ec 89b2f570 fcfs!SendMapRequest+0x199
> (FPO: [Non-Fpo]) (CONV: stdcall)
> ad04a168 ae2bcdcb 8a962f80 00000000 ad04a190 fcfs!CheckFileMap+0x24c (FPO:
> [Non-Fpo]) (CONV: stdcall)
> ad04a178 ae2bcae3 8a962f80 00000003 8a962f80 fcfs!DirectRead+0x8b (FPO:
> [Non-Fpo]) (CONV: stdcall)
> ad04a190 ba698deb 89b698ec ad04a1dc ad04a20c fcfs!PreRead+0x133 (FPO:
> [Non-Fpo]) (CONV: stdcall)
> ad04a1bc ba680888 00000001 00000003 ad04a20c fltMgr!FltvPreOperation+0x3f
> (FPO: [Non-Fpo])
> ad04a21c ba6822a0 0004a264 00000000 ad04a264
> fltMgr!FltpPerformPreCallbacks+0x2d4 (FPO: [Non-Fpo])
> ad04a230 ba682c48 ad04a264 00000000 890b3638
> fltMgr!FltpPassThroughInternal+0x32 (FPO: [Non-Fpo])
> ad04a24c ba683059 ad04a201 89d21a01 89d5b100 fltMgr!FltpPassThrough+0x1c2
> (FPO: [Non-Fpo])
> ad04a27c 804eddf9 890b3638 8a4dce48 806d02e8 fltMgr!FltpDispatch+0x10d
> (FPO: [Non-Fpo])
> ad04a28c 8064b5a8 89ada810 00001000 89d21a28 nt!IopfCallDriver+0x31 (FPO:
> [0,0,0])
> ad04a2b0 804ee7c4 00000000 89d21a18 89d21a28 nt!IovCallDriver+0xa0 (FPO:
> [Non-Fpo])
> ad04a2c4 804ee7eb 890b3638 89d21a09 89d21a30 nt!IopPageReadInternal+0xf4
> (FPO: [Non-Fpo])
> ad04a2e4 8051286a 89ada810 89d21a50 89d21a30 nt!IoPageRead+0x1b (FPO:
> [Non-Fpo])
> ad04a360 8051bdd4 e1057010 cc601000 c0663008 nt!MiDispatchFault+0x286
> (FPO: [Non-Fpo])
> ad04a3c4 8053f6ec 00000000 cc601000 00000000 nt!MmAccessFault+0x7b4 (FPO:
> [Non-Fpo])
> ad04a3c4 8055e4fb 00000000 cc601000 00000000 nt!KiTrap0E+0xcc (FPO: [0,0]
> TrapFrame @ ad04a3dc)
> ad04a49c ba5ef7cb 89ada810 ad04a4cc 00001000 nt!CcMapData+0xef (FPO:
> [Non-Fpo])
> ad04a4bc ba5f01be ad04a7e8 e1044d20 00001000 Ntfs!NtfsMapStream+0x46 (FPO:
> [Non-Fpo])
> ad04a4ec ba5f072b ad04a7e8 0000000c 00000001 Ntfs!ReadIndexBuffer+0x8a
> (FPO: [Non-Fpo])
> ad04a51c ba5f1c9a ad04a7e8 ad04a628 e21d9008
> Ntfs!FindFirstIndexEntry+0x191 (FPO: [Non-Fpo])
> ad04a564 ba5f1ded ad04a7e8 e1044d20 e21d9008 Ntfs!NtfsFindIndexEntry+0x48
> (FPO: [Non-Fpo])
> ad04a598 ba5f1b28 ad04a7e8 e1044d20 00000101 Ntfs!NtfsLookupEntry+0xa2
> (FPO: [Non-Fpo])
> ad04a7c4 ba5edf72 ad04a7e8 8a9eee48 ad04a918 Ntfs!NtfsCommonCreate+0x10c3
> (FPO: [Non-Fpo])
> ad04a970 ba674f70 8a9eee48 ad04ac00 88a9a020
> Ntfs!NtfsNetworkOpenCreate+0x8a (FPO: [Non-Fpo])
> ad04a990 ba6820e8 8a9eee48 ad04ac00 890c57c0 sr!SrFastIoQueryOpen+0x40
> (FPO: [Non-Fpo])
> ad04a9b0 ba68e927 000000f2 00000000 ad04a9e8
> fltMgr!FltpPerformFastIoCall+0x300 (FPO: [Non-Fpo])
> ad04aa08 805772b8 8a9eee48 ad04ac00 890b3638
> fltMgr!FltpFastIoQueryOpen+0xa1 (FPO: [Non-Fpo])
> ad04aaf4 805b3642 89159820 00000000 88e7d730 nt!IopParseDevice+0x95c (FPO:
> [Non-Fpo])
> ad04ab7c 805afb23 00000000 ad04abbc 00000040 nt!ObpLookupObjectName+0x56a
> (FPO: [Non-Fpo])
> ad04abd0 8056b0b9 00000000 00000000 00000001 nt!ObOpenObjectByName+0xeb
> (FPO: [Non-Fpo])
> ad04ad54 8053c808 0104fcb8 0104fc90 0104fce4 nt!NtQueryAttributesFile+0xf1
> (FPO: [Non-Fpo])
> ad04ad54 7c90eb94 0104fcb8 0104fc90 0104fce4 nt!KiFastCallEntry+0xf8 (FPO:
> [0,0] TrapFrame @ ad04ad64)
> 0104fce4 00000000 00000000 00000000 00000000 ntdll!KiFastSystemCallRet
> (FPO: [0,0,0])
>
> “Edouard A.” wrote in message news:xxxxx@ntfsd…
>> By the way:
>>
>> “Intermediate or highest-level drivers can call
>> IoBuildSynchronousFsdRequest
>> to set up IRPs for requests sent to lower-level drivers, only if the
>> caller
>> is running in a nonarbitrary thread context and at IRQL = PASSIVE_LEVEL.”
>>
>> Certainly the reason of your problem.
>
> Sorry the documentation you are quoting is old, the current doc’s
> indicate:
> “Callers of IoBuildSynchronousFsdRequest must be running at IRQL <=
> APC_LEVEL.”
>
> Thanks to everyone who answered, this is driving me nuts.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> http://www.windrvr.com
> Remove StopSpam from the email to reply
>
>
>
>
Are you setting the event in your completion routine for this IRP? If
not, the problem is that this IRP will never complete if it gets posted
because the notification is done in a special kernel mode APC, and those
are always disabled for paging I/O.
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Slava and Tony,
Thank you, the bugs are always obvious after the fact. You can tell I
haven’t done enough with filters (Tony the OSR File System Kit makes the
whole thing too easy 
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
“Tony Mason” wrote in message news:xxxxx@ntfsd…
Are you setting the event in your completion routine for this IRP? If
not, the problem is that this IRP will never complete if it gets posted
because the notification is done in a special kernel mode APC, and those
are always disabled for paging I/O.
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
In fact, the I/O Manager does a direct set of the event if the
IRP_PAGING_IO bit is set, which is what allows this to work for paging
I/O. Without that, it queues a special kernel APC back to the
originating thread.
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com