Problem during IRP_MJ_CREATE

NTFSD
1

Dear All,

I am developing a file system filter driver for W2k
and WXP platforms.
I want to capture the IRP_MJ_CREATE requests and do
some preprocessing in a service and based upon that
send the IRP to lower level driver or complete with
some error code(like STATUS_ACCESS_DENIED).
Since it is not recommended to return STATUS_PENDING
for IRP_MJ_CREATE, (better to be synchronous) I keep
the Irp in a Cancel safe IRP queue and wait in a
notification event for notification from the service.
When the service informs the driver via a private
I/O control, I signal the event so that the IRP can be
sent to lower driver or completed in my filter driver.
But I receive the following bug check.
Based upon the memory location, I found that windows
tries to access the Irp->PendingReturned member for
the IRP completed by lower level driver (either file
system driver or some other). I wonder why this
happens,since this should happen only if the IRP is
pended and not for a completed IRP. I receive
STATUS_SUCCESS from my lower level driver. Is it means
the IrpStack->Control still has SL_PENDING_RETURNED
somewhere? The crash occurs because the Irp has
already been completed and freed to system pool. My
confusion is why should the Irp->PendingReturned
should be checked after the Irp has been successfully
completed by the lower level driver.
I tested in both checked and free builds of W2k and
free build of WXP with driver verifier enabled with
all options except low resources simulation. I/O
verification level is set at 2.

*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

PAGE_FAULT_IN_FREED_SPECIAL_POOL (cc)
Memory was referenced after it was freed.
This cannot be protected by try-except.
When possible, the guilty driver's name (Unicode
string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: fb73fe49, memory referenced
Arg2: 00000000, value 0 = read operation, 1 = write
operation
Arg3: 8054f87e, if non-zero, the address which
referenced memory.
Arg4: 00000000, Mm internal code.

Debugging Details:

Could not read faulting driver name

READ_ADDRESS: fb73fe49 Nonpaged pool expansion

FAULTING_IP:
nt!Phase1Initialization+229
8054f87e 807e2100 cmp byte ptr
[esi+0x21],0x0

MM_INTERNAL_CODE: 0

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xCC

LAST_CONTROL_TRANSFER: from 8043984a to 804aab44

STACK_TEXT:
f207446c 8043984a 00000003 c03edcfc 00000001
nt!RtlUnicodeToMultiByteN+0x71
f20747f8 80493cac 00000001 fb73fe49 00000000
nt!MiSegmentDelete+0x23a
f2074848 804c34c3 00000000 fb73fe49 00000000
nt!NtQuerySystemInformation+0xe68
f2074860 8054f87e badb0d00 00000000 fcd97b98
nt!ExCreateCallback+0x31
f2074a4c 804a3178 ff258398 00000000 f2074b04
nt!Phase1Initialization+0x229
f2074ac4 8057a8e5 00000000 f2074bc0 00000040
nt!NtFreeVirtualMemory+0x5ea
f2074bd4 80521621 00000000 00000000 c0201401
nt!_NULL_IMPORT_DESCRIPTOR (nt+0x17a8e5)
f2074d48 804bfb2a 0012e8f8 0012e8d0 00139000
nt!NtSetInformationKey+0x82
f2074d64 77f78def badb0d00 0012e8bc 12345678
nt!SeCaptureSidAndAttributesArray+0xf9
0012e924 4ad198e2 00136270 00135e50 0012fc68
ntdll!LdrUnloadDll+0x2a0
0012eb4c 4ad1fb4f 00136270 00000001 0012fc24
cmd!AppendPath+0x24
0012ef8c 4ad1d60b 0012fc24 00000001 00000001
cmd!CmdJBuf1+0xf
0012f7f4 4ad1cbf7 0012fc24 00134d50 4ad24000
cmd!tempstr+0x6b
0012fc90 4ad0dd71 00000000 0012fec4 4ad11ebf
cmd!JumpTable+0x317
0012fce8 4ad0a11d 0012fd08 00000200 4ad03130
cmd!ePipe+0x188
0012fcf4 4ad03130 0012ff1c 00000002 77e93cd1
cmd!GetRegistryValues+0xb2
00000200 00000000 00000000 00000000 00000000
cmd!FParseWork+0x83

FOLLOWUP_IP:
nt!Phase1Initialization+229
8054f87e 807e2100 cmp byte ptr
[esi+0x21],0x0

SYMBOL_STACK_INDEX: 4

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nt!Phase1Initialization+229

MODULE_NAME: nt

IMAGE_NAME: ntoskrnl.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 3ee650a8

STACK_COMMAND: kb

BUCKET_ID: 0xCC_nt!Phase1Initialization+229

Followup: MachineOwner
---------

Thanks,
Janardhanan.R.

_______________________________
Do you Yahoo!?
Shop for Back-to-School deals on Yahoo! Shopping.
http://shopping.yahoo.com/backtoschool

2

Janardhanan,

There is no issue with returning STATUS_PENDING for a create IRP. The
IOManager will properly wait for the operation to complete. Where did
you get the impression that this was bad?

Also, there is no point in setting a cancel routine for a create IRP
because create IRPs are not cancelable.

What event were you signaling? Did you do other file system operations
using this file object? If so do you role your own IRPs and set the
"OriginalFileObject" field? If so there is a known issue.

I have never tried to do what you are doing so I don't exactly know what
would happen. What we do (you can look at the filespy sample in the
IFSKit) is synchronize the create back to our dispatch routine and do
the necessary processing in the context of the originating thread.

Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided "AS IS" with no warranties, and confers no
rights

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Janardhanan R.
Sent: Monday, September 13, 2004 7:42 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Problem during IRP_MJ_CREATE

Dear All,

I am developing a file system filter driver for W2k
and WXP platforms.
I want to capture the IRP_MJ_CREATE requests and do
some preprocessing in a service and based upon that
send the IRP to lower level driver or complete with
some error code(like STATUS_ACCESS_DENIED).
Since it is not recommended to return STATUS_PENDING
for IRP_MJ_CREATE, (better to be synchronous) I keep
the Irp in a Cancel safe IRP queue and wait in a
notification event for notification from the service.
When the service informs the driver via a private
I/O control, I signal the event so that the IRP can be
sent to lower driver or completed in my filter driver.
But I receive the following bug check.
Based upon the memory location, I found that windows
tries to access the Irp->PendingReturned member for
the IRP completed by lower level driver (either file
system driver or some other). I wonder why this
happens,since this should happen only if the IRP is
pended and not for a completed IRP. I receive
STATUS_SUCCESS from my lower level driver. Is it means
the IrpStack->Control still has SL_PENDING_RETURNED
somewhere? The crash occurs because the Irp has
already been completed and freed to system pool. My
confusion is why should the Irp->PendingReturned
should be checked after the Irp has been successfully
completed by the lower level driver.
I tested in both checked and free builds of W2k and
free build of WXP with driver verifier enabled with
all options except low resources simulation. I/O
verification level is set at 2.

************************************************************************
*******
*
*
* Bugcheck Analysis
*
*
*
************************************************************************
*******

PAGE_FAULT_IN_FREED_SPECIAL_POOL (cc)
Memory was referenced after it was freed.
This cannot be protected by try-except.
When possible, the guilty driver's name (Unicode
string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: fb73fe49, memory referenced
Arg2: 00000000, value 0 = read operation, 1 = write
operation
Arg3: 8054f87e, if non-zero, the address which
referenced memory.
Arg4: 00000000, Mm internal code.

Debugging Details:

Could not read faulting driver name

READ_ADDRESS: fb73fe49 Nonpaged pool expansion

FAULTING_IP:
nt!Phase1Initialization+229
8054f87e 807e2100 cmp byte ptr
[esi+0x21],0x0

MM_INTERNAL_CODE: 0

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xCC

LAST_CONTROL_TRANSFER: from 8043984a to 804aab44

STACK_TEXT:
f207446c 8043984a 00000003 c03edcfc 00000001
nt!RtlUnicodeToMultiByteN+0x71
f20747f8 80493cac 00000001 fb73fe49 00000000
nt!MiSegmentDelete+0x23a
f2074848 804c34c3 00000000 fb73fe49 00000000
nt!NtQuerySystemInformation+0xe68
f2074860 8054f87e badb0d00 00000000 fcd97b98
nt!ExCreateCallback+0x31
f2074a4c 804a3178 ff258398 00000000 f2074b04
nt!Phase1Initialization+0x229
f2074ac4 8057a8e5 00000000 f2074bc0 00000040
nt!NtFreeVirtualMemory+0x5ea
f2074bd4 80521621 00000000 00000000 c0201401
nt!_NULL_IMPORT_DESCRIPTOR (nt+0x17a8e5)
f2074d48 804bfb2a 0012e8f8 0012e8d0 00139000
nt!NtSetInformationKey+0x82
f2074d64 77f78def badb0d00 0012e8bc 12345678
nt!SeCaptureSidAndAttributesArray+0xf9
0012e924 4ad198e2 00136270 00135e50 0012fc68
ntdll!LdrUnloadDll+0x2a0
0012eb4c 4ad1fb4f 00136270 00000001 0012fc24
cmd!AppendPath+0x24
0012ef8c 4ad1d60b 0012fc24 00000001 00000001
cmd!CmdJBuf1+0xf
0012f7f4 4ad1cbf7 0012fc24 00134d50 4ad24000
cmd!tempstr+0x6b
0012fc90 4ad0dd71 00000000 0012fec4 4ad11ebf
cmd!JumpTable+0x317
0012fce8 4ad0a11d 0012fd08 00000200 4ad03130
cmd!ePipe+0x188
0012fcf4 4ad03130 0012ff1c 00000002 77e93cd1
cmd!GetRegistryValues+0xb2
00000200 00000000 00000000 00000000 00000000
cmd!FParseWork+0x83

FOLLOWUP_IP:
nt!Phase1Initialization+229
8054f87e 807e2100 cmp byte ptr
[esi+0x21],0x0

SYMBOL_STACK_INDEX: 4

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nt!Phase1Initialization+229

MODULE_NAME: nt

IMAGE_NAME: ntoskrnl.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 3ee650a8

STACK_COMMAND: kb

BUCKET_ID: 0xCC_nt!Phase1Initialization+229

Followup: MachineOwner
---------

Thanks,
Janardhanan.R.

_______________________________
Do you Yahoo!?
Shop for Back-to-School deals on Yahoo! Shopping.
http://shopping.yahoo.com/backtoschool

---
Questions? First check the IFS FAQ at
The NT Insider:Windows NT Virtual Memory (Part I)

You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Dear Neal,
I avoided pending the IRP because in the IFS
documentation, it was recommended to avoid pending of
create IRPs. So, I made it synchronous so that it will
wait until my processing of the IRP is over.
Now I changed the code to avoid cancelling of the
Create IRP since it was not necessary. The code is
working properly after I removed the cancelling code
and still leaving the create IRP processing
synchronous inside the dispatch routine. I tried with
various verifier options.

Thanks,
Janardhanan.R.
— Neal Christiansen
wrote:

> Janardhanan,
>
> There is no issue with returning STATUS_PENDING for
> a create IRP. The
> IOManager will properly wait for the operation to
> complete. Where did
> you get the impression that this was bad?
>
> Also, there is no point in setting a cancel routine
> for a create IRP
> because create IRPs are not cancelable.
>
> What event were you signaling? Did you do other
> file system operations
> using this file object? If so do you role your own
> IRPs and set the
> “OriginalFileObject” field? If so there is a known
> issue.
>
> I have never tried to do what you are doing so I
> don’t exactly know what
> would happen. What we do (you can look at the
> filespy sample in the
> IFSKit) is synchronize the create back to our
> dispatch routine and do
> the necessary processing in the context of the
> originating thread.
>
> Neal Christiansen
> Microsoft File System Filter Group Lead
> This posting is provided “AS IS” with no warranties,
> and confers no
> rights
>
>
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf
> Of Janardhanan R.
> Sent: Monday, September 13, 2004 7:42 AM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] Problem during IRP_MJ_CREATE
>
> Dear All,
>
> I am developing a file system filter driver for
> W2k
> and WXP platforms.
> I want to capture the IRP_MJ_CREATE requests and
> do
> some preprocessing in a service and based upon that
> send the IRP to lower level driver or complete with
> some error code(like STATUS_ACCESS_DENIED).
> Since it is not recommended to return
> STATUS_PENDING
> for IRP_MJ_CREATE, (better to be synchronous) I keep
> the Irp in a Cancel safe IRP queue and wait in a
> notification event for notification from the
> service.
> When the service informs the driver via a private
> I/O control, I signal the event so that the IRP can
> be
> sent to lower driver or completed in my filter
> driver.
> But I receive the following bug check.
> Based upon the memory location, I found that
> windows
> tries to access the Irp->PendingReturned member for
> the IRP completed by lower level driver (either file
> system driver or some other). I wonder why this
> happens,since this should happen only if the IRP is
> pended and not for a completed IRP. I receive
> STATUS_SUCCESS from my lower level driver. Is it
> means
> the IrpStack->Control still has SL_PENDING_RETURNED
> somewhere? The crash occurs because the Irp has
> already been completed and freed to system pool. My
> confusion is why should the Irp->PendingReturned
> should be checked after the Irp has been
> successfully
> completed by the lower level driver.
> I tested in both checked and free builds of W2k
> and
> free build of WXP with driver verifier enabled with
> all options except low resources simulation. I/O
> verification level is set at 2.
>
>
*****************************************************************
>
> *
>
> *
> * Bugcheck Analysis
>
> *
> *
>
> *
>
*****************************************************************
>
>
> PAGE_FAULT_IN_FREED_SPECIAL_POOL (cc)
> Memory was referenced after it was freed.
> This cannot be protected by try-except.
> When possible, the guilty driver’s name (Unicode
> string) is printed on
> the bugcheck screen and saved in KiBugCheckDriver.
> Arguments:
> Arg1: fb73fe49, memory referenced
> Arg2: 00000000, value 0 = read operation, 1 = write
> operation
> Arg3: 8054f87e, if non-zero, the address which
> referenced memory.
> Arg4: 00000000, Mm internal code.
>
> Debugging Details:
> ------------------
>
>
> Could not read faulting driver name
>
> READ_ADDRESS: fb73fe49 Nonpaged pool expansion
>
> FAULTING_IP:
> nt!Phase1Initialization+229
> 8054f87e 807e2100 cmp byte ptr
> [esi+0x21],0x0
>
> MM_INTERNAL_CODE: 0
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0xCC
>
> LAST_CONTROL_TRANSFER: from 8043984a to 804aab44
>
> STACK_TEXT:
> f207446c 8043984a 00000003 c03edcfc 00000001
> nt!RtlUnicodeToMultiByteN+0x71
> f20747f8 80493cac 00000001 fb73fe49 00000000
> nt!MiSegmentDelete+0x23a
> f2074848 804c34c3 00000000 fb73fe49 00000000
> nt!NtQuerySystemInformation+0xe68
> f2074860 8054f87e badb0d00 00000000 fcd97b98
> nt!ExCreateCallback+0x31
> f2074a4c 804a3178 ff258398 00000000 f2074b04
> nt!Phase1Initialization+0x229
> f2074ac4 8057a8e5 00000000 f2074bc0 00000040
> nt!NtFreeVirtualMemory+0x5ea
> f2074bd4 80521621 00000000 00000000 c0201401
> nt!_NULL_IMPORT_DESCRIPTOR (nt+0x17a8e5)
> f2074d48 804bfb2a 0012e8f8 0012e8d0 00139000
> nt!NtSetInformationKey+0x82
> f2074d64 77f78def badb0d00 0012e8bc 12345678
> nt!SeCaptureSidAndAttributesArray+0xf9
> 0012e924 4ad198e2 00136270 00135e50 0012fc68
> ntdll!LdrUnloadDll+0x2a0
> 0012eb4c 4ad1fb4f 00136270 00000001 0012fc24
> cmd!AppendPath+0x24
> 0012ef8c 4ad1d60b 0012fc24 00000001 00000001
> cmd!CmdJBuf1+0xf
> 0012f7f4 4ad1cbf7 0012fc24 00134d50 4ad24000
> cmd!tempstr+0x6b
> 0012fc90 4ad0dd71 00000000 0012fec4 4ad11ebf
> cmd!JumpTable+0x317
> 0012fce8 4ad0a11d 0012fd08 00000200 4ad03130
> cmd!ePipe+0x188
> 0012fcf4 4ad03130 0012ff1c 00000002 77e93cd1
> cmd!GetRegistryValues+0xb2
> 00000200 00000000 00000000 00000000 00000000
> cmd!FParseWork+0x83
>
>
> FOLLOWUP_IP:
> nt!Phase1Initialization+229
> 8054f87e 807e2100 cmp byte ptr
> [esi+0x21],0x0
>
> SYMBOL_STACK_INDEX: 4
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: nt!Phase1Initialization+229
>
> MODULE_NAME: nt
>
> IMAGE_NAME: ntoskrnl.exe
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 3ee650a8
>
> STACK_COMMAND: kb
>
> BUCKET_ID: 0xCC_nt!Phase1Initialization+229
>
> Followup: MachineOwner
> ---------
>
> Thanks,
>
=== message truncated ===

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail