Rolling own IRP

NTFSD
1

In my FSFD in need to implement the following behavior. When user requests
some operation on my file (e.g. IRP_MJ_READ) I want to perform this
operation for another FO. Here’s extract from my sources.

NTSTATUS OnRead(PIRP IrpPtr)
{
// extract information from file object
PFILE_OBJECT FileObjectPtr =
IoGetCurrentIrpStackLocation(IrpPtr)->FileObject;
PFILE_OBJECT OriginalFileObjectPtr = (PFILE_OBJECT)FileObjectPtr->FsContext;
PDEVICE_OBJECT TargetDevicePtr = (PDEVICE_OBJECT)FileObjectPtr->FsContext2;
// allocate irp
PIRP ReadIrpPtr = IoAllocateIrp(TargetDevicePtr->StackSize, FALSE);
if (NULL == ReadIrpPtr)
{
IrpPtr->IoStatus.Information = 0;
IrpPtr->IoStatus.Status = STATUS_INSUFFICIENT_RESOURCES;
IoCompleteRequest(IrpPtr, IO_NO_INCREMENT);
return STATUS_INSUFFICIENT_RESOURCES;
}
// initialize irp
ReadIrpPtr->AssociatedIrp.SystemBuffer = IrpPtr->AssociatedIrp.SystemBuffer;
ReadIrpPtr->MdlAddress = IrpPtr->MdlAddress;
ReadIrpPtr->UserBuffer = IrpPtr->UserBuffer;
ReadIrpPtr->Tail.Overlay.Thread = IrpPtr->Tail.Overlay.Thread;
ReadIrpPtr->Flags = IrpPtr->Flags;
// initialize next irp stack location
PIO_STACK_LOCATION CurrentIrpStackLocationPtr =
IoGetCurrentIrpStackLocation(IrpPtr);
PIO_STACK_LOCATION NextIrpStackLocationPtr =
IoGetNextIrpStackLocation(ReadIrpPtr);
NextIrpStackLocationPtr->DeviceObject = TargetDevicePtr;
NextIrpStackLocationPtr->FileObject = OriginalFileObjectPtr;
NextIrpStackLocationPtr->MajorFunction =
CurrentIrpStackLocationPtr->MajorFunction;
NextIrpStackLocationPtr->MinorFunction =
CurrentIrpStackLocationPtr->MinorFunction;
NextIrpStackLocationPtr->Flags = CurrentIrpStackLocationPtr->Flags;
NextIrpStackLocationPtr->Parameters.Read =
CurrentIrpStackLocationPtr->Parameters.Read;
// set completion routine
IoSetCompletionRoutine(ReadIrpPtr, _ForwardedRequestCompletionRoutine,
IrpPtr, TRUE, TRUE, TRUE);
return IoCallDriver(TargetDevicePtr, ReadIrpPtr);
}
static NTSTATUS _ForwardedRequestCompletionRoutine(PDEVICE_OBJECT
DeviceObjectPtr, PIRP IrpPtr, PVOID ContextPtr)
{
PIRP OriginalIrpPtr = (PIRP)ContextPtr;
if (IrpPtr->PendingReturned)
{
IoMarkIrpPending(IrpPtr);
IoMarkIrpPending(OriginalIrpPtr);
}
//
OriginalIrpPtr->AssociatedIrp.SystemBuffer =
IrpPtr->AssociatedIrp.SystemBuffer;
OriginalIrpPtr->MdlAddress = IrpPtr->MdlAddress;
OriginalIrpPtr->UserBuffer = IrpPtr->UserBuffer;
OriginalIrpPtr->IoStatus = IrpPtr->IoStatus;
OriginalIrpPtr->Flags = IrpPtr->Flags;
IoCompleteRequest(OriginalIrpPtr, IO_NO_INCREMENT);
//
IrpPtr->AssociatedIrp.SystemBuffer = NULL;
IrpPtr->MdlAddress = NULL;
IrpPtr->UserBuffer = NULL;
IoFreeIrp(IrpPtr);
//
return STATUS_MORE_PROCESSING_REQUIRED;
}

The problem is I often get the following bugcheck on some kinds of original
FO (for example ones that represent .dll’s cause a BSOD).

****************************************************************************
***
* *
* Bugcheck Analysis *
* *
****************************************************************************
***
SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION (c1)
Special pool has detected memory corruption. Typically the current thread’s
stack backtrace will reveal the guilty party.
Arguments:
Arg1: acdcde90, address trying to free
Arg2: acdcdfff, address where bits are corrupted
Arg3: 1200016c, (reserved)
Arg4: 00000024, caller is freeing an address where bytes after the end of
the allocation have been overwritten
Debugging Details:

SPECIAL_POOL_CORRUPTION_TYPE: 24
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0xC1
LAST_CONTROL_TRANSFER: from 80438bab to 804a9bcc
STACK_TEXT:
eb437708 80438bab 00000003 eb437750 acdcde90
nt!RtlpBreakWithStatusInstruction
eb437738 8043919e 00000003 c02b3734 0000016c nt!KiBugCheckDebugBreak+0x31
eb437ac4 8062119d 000000c1 acdcde90 acdcdfff nt!KeBugCheckEx+0x390
eb437b08 804c5f3b acdcde90 eb437b8c acdcde90 nt!MmFreeSpecialPool+0x1f2
eb437b3c 804c5e13 acdcde90 00000000 eb437b70 nt!ExFreePoolWithTag+0x22
eb437b4c 80436187 acdcde90 815add48 8060b84c nt!ExFreePool+0xd
eb437b58 8060b84c acdcde90 000000c9 00000000
nt!IovpProtectedIrpMakeUntouchable+0x11
eb437b70 80607c4e acdcdff4 acdcde90 00000000 nt!IovpFreeIrp+0x15d
eb437b84 80607bf3 acdcde90 eb437ba0 eb033b5c nt!IovFreeIrpPrivate+0x56
eb437b90 eb033b5c acdcde90 acdcbf68 eb437bec nt!IovFreeIrp+0xb
eb437ba0 8060828d 00000000 acdcde90 acdcbf68
Vba32dNT!CRootDeviceExtension::_ForwardedRequestCompletionRoutine+0xbc
[r:\projects@vba4\monitor\fsffilter\rootdev.h @ 69]
eb437bec bfe72216 816e5b68 eb437ce0 bfe732d6
nt!IovSpecialIrpCompleteRequest+0x1f7
eb437bf8 bfe732d6 816e5b68 acdcde90 00000000
Fastfat!FatCompleteRequest_Real+0x64
eb437ce0 bfe95780 816e5b68 acdcde90 816e5b6c Fastfat!FatCommonRead+0x951
eb437d40 8041c1ec 816e5b68 00000000 00000000 Fastfat!FatFspDispatch+0xf3
eb437da8 804a91e6 00000000 00000000 00000000 nt!ExpWorkerThread+0x106
eb437ddc 804c3d4a 8041c0e6 00000000 00000000 nt!PspSystemThreadStartup+0x54
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
Vba32dNT!CRootDeviceExtension::_ForwardedRequestCompletionRoutine+bc
eb033b5c b8160000c0 mov eax,0xc0000016
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME:
Vba32dNT!CRootDeviceExtension::_ForwardedRequestCompletionRoutine+bc
MODULE_NAME: Vba32dNT
IMAGE_NAME: Vba32dNT.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 3dbfda48
STACK_COMMAND: kb
BUCKET_ID:
0xC1_Vba32dNT!CRootDeviceExtension::_ForwardedRequestCompletionRoutine+bc
Followup: MachineOwner

The target OS is Win2K SP2 checked. The “Rolling Your Own IRP” article on
the OSR says that this may appear when “important IRP field (Zoned flag) is
cleared, which cause subsequent call to IoFreeIrp to call ExFreePool on that
IRP”. But I don’t see any problem here. It’s also strange that the code
fails basicly on executable files (actually it never bugchecked on anything
but .dll’s).

2

I wanted to add that bugchecking on .dll file is just a coincidence. I
crashes on every other kind of files as well.

----- Original Message -----
From: “Alexey Logachyov”
To: “File Systems Developers”
Sent: Wednesday, October 30, 2002 4:01 PM
Subject: [ntfsd] Rolling own IRP

> In my FSFD in need to implement the following behavior. When user requests
> some operation on my file (e.g. IRP_MJ_READ) I want to perform this
> operation for another FO. Here’s extract from my sources.
>
> NTSTATUS OnRead(PIRP IrpPtr)
> {
> // extract information from file object
> PFILE_OBJECT FileObjectPtr =
> IoGetCurrentIrpStackLocation(IrpPtr)->FileObject;
> PFILE_OBJECT OriginalFileObjectPtr =
(PFILE_OBJECT)FileObjectPtr->FsContext;
> PDEVICE_OBJECT TargetDevicePtr =
(PDEVICE_OBJECT)FileObjectPtr->FsContext2;
> // allocate irp
> PIRP ReadIrpPtr = IoAllocateIrp(TargetDevicePtr->StackSize, FALSE);
> if (NULL == ReadIrpPtr)
> {
> IrpPtr->IoStatus.Information = 0;
> IrpPtr->IoStatus.Status = STATUS_INSUFFICIENT_RESOURCES;
> IoCompleteRequest(IrpPtr, IO_NO_INCREMENT);
> return STATUS_INSUFFICIENT_RESOURCES;
> }
> // initialize irp
> ReadIrpPtr->AssociatedIrp.SystemBuffer =
IrpPtr->AssociatedIrp.SystemBuffer;
> ReadIrpPtr->MdlAddress = IrpPtr->MdlAddress;
> ReadIrpPtr->UserBuffer = IrpPtr->UserBuffer;
> ReadIrpPtr->Tail.Overlay.Thread = IrpPtr->Tail.Overlay.Thread;
> ReadIrpPtr->Flags = IrpPtr->Flags;
> // initialize next irp stack location
> PIO_STACK_LOCATION CurrentIrpStackLocationPtr =
> IoGetCurrentIrpStackLocation(IrpPtr);
> PIO_STACK_LOCATION NextIrpStackLocationPtr =
> IoGetNextIrpStackLocation(ReadIrpPtr);
> NextIrpStackLocationPtr->DeviceObject = TargetDevicePtr;
> NextIrpStackLocationPtr->FileObject = OriginalFileObjectPtr;
> NextIrpStackLocationPtr->MajorFunction =
> CurrentIrpStackLocationPtr->MajorFunction;
> NextIrpStackLocationPtr->MinorFunction =
> CurrentIrpStackLocationPtr->MinorFunction;
> NextIrpStackLocationPtr->Flags = CurrentIrpStackLocationPtr->Flags;
> NextIrpStackLocationPtr->Parameters.Read =
> CurrentIrpStackLocationPtr->Parameters.Read;
> // set completion routine
> IoSetCompletionRoutine(ReadIrpPtr, _ForwardedRequestCompletionRoutine,
> IrpPtr, TRUE, TRUE, TRUE);
> return IoCallDriver(TargetDevicePtr, ReadIrpPtr);
> }
> static NTSTATUS _ForwardedRequestCompletionRoutine(PDEVICE_OBJECT
> DeviceObjectPtr, PIRP IrpPtr, PVOID ContextPtr)
> {
> PIRP OriginalIrpPtr = (PIRP)ContextPtr;
> if (IrpPtr->PendingReturned)
> {
> IoMarkIrpPending(IrpPtr);
> IoMarkIrpPending(OriginalIrpPtr);
> }
> //
> OriginalIrpPtr->AssociatedIrp.SystemBuffer =
> IrpPtr->AssociatedIrp.SystemBuffer;
> OriginalIrpPtr->MdlAddress = IrpPtr->MdlAddress;
> OriginalIrpPtr->UserBuffer = IrpPtr->UserBuffer;
> OriginalIrpPtr->IoStatus = IrpPtr->IoStatus;
> OriginalIrpPtr->Flags = IrpPtr->Flags;
> IoCompleteRequest(OriginalIrpPtr, IO_NO_INCREMENT);
> //
> IrpPtr->AssociatedIrp.SystemBuffer = NULL;
> IrpPtr->MdlAddress = NULL;
> IrpPtr->UserBuffer = NULL;
> IoFreeIrp(IrpPtr);
> //
> return STATUS_MORE_PROCESSING_REQUIRED;
> }
>
> The problem is I often get the following bugcheck on some kinds of
original
> FO (for example ones that represent .dll’s cause a BSOD).
>
>
*************************************************************************
>
> * *
> * Bugcheck Analysis *
> * *
>
*************************************************************************
>
> SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION (c1)
> Special pool has detected memory corruption. Typically the current
thread’s
> stack backtrace will reveal the guilty party.
> Arguments:
> Arg1: acdcde90, address trying to free
> Arg2: acdcdfff, address where bits are corrupted
> Arg3: 1200016c, (reserved)
> Arg4: 00000024, caller is freeing an address where bytes after the end of
> the allocation have been overwritten
> Debugging Details:
> ------------------
>
> SPECIAL_POOL_CORRUPTION_TYPE: 24
> DEFAULT_BUCKET_ID: DRIVER_FAULT
> BUGCHECK_STR: 0xC1
> LAST_CONTROL_TRANSFER: from 80438bab to 804a9bcc
> STACK_TEXT:
> eb437708 80438bab 00000003 eb437750 acdcde90
> nt!RtlpBreakWithStatusInstruction
> eb437738 8043919e 00000003 c02b3734 0000016c nt!KiBugCheckDebugBreak+0x31
> eb437ac4 8062119d 000000c1 acdcde90 acdcdfff nt!KeBugCheckEx+0x390
> eb437b08 804c5f3b acdcde90 eb437b8c acdcde90 nt!MmFreeSpecialPool+0x1f2
> eb437b3c 804c5e13 acdcde90 00000000 eb437b70 nt!ExFreePoolWithTag+0x22
> eb437b4c 80436187 acdcde90 815add48 8060b84c nt!ExFreePool+0xd
> eb437b58 8060b84c acdcde90 000000c9 00000000
> nt!IovpProtectedIrpMakeUntouchable+0x11
> eb437b70 80607c4e acdcdff4 acdcde90 00000000 nt!IovpFreeIrp+0x15d
> eb437b84 80607bf3 acdcde90 eb437ba0 eb033b5c nt!IovFreeIrpPrivate+0x56
> eb437b90 eb033b5c acdcde90 acdcbf68 eb437bec nt!IovFreeIrp+0xb
> eb437ba0 8060828d 00000000 acdcde90 acdcbf68
> Vba32dNT!CRootDeviceExtension::_ForwardedRequestCompletionRoutine+0xbc
> [r:\projects@vba4\monitor\fsffilter\rootdev.h @ 69]
> eb437bec bfe72216 816e5b68 eb437ce0 bfe732d6
> nt!IovSpecialIrpCompleteRequest+0x1f7
> eb437bf8 bfe732d6 816e5b68 acdcde90 00000000
> Fastfat!FatCompleteRequest_Real+0x64
> eb437ce0 bfe95780 816e5b68 acdcde90 816e5b6c Fastfat!FatCommonRead+0x951
> eb437d40 8041c1ec 816e5b68 00000000 00000000 Fastfat!FatFspDispatch+0xf3
> eb437da8 804a91e6 00000000 00000000 00000000 nt!ExpWorkerThread+0x106
> eb437ddc 804c3d4a 8041c0e6 00000000 00000000
nt!PspSystemThreadStartup+0x54
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
> FOLLOWUP_IP:
> Vba32dNT!CRootDeviceExtension::_ForwardedRequestCompletionRoutine+bc
> eb033b5c b8160000c0 mov eax,0xc0000016
> FOLLOWUP_NAME: MachineOwner
> SYMBOL_NAME:
> Vba32dNT!CRootDeviceExtension::_ForwardedRequestCompletionRoutine+bc
> MODULE_NAME: Vba32dNT
> IMAGE_NAME: Vba32dNT.sys
> DEBUG_FLR_IMAGE_TIMESTAMP: 3dbfda48
> STACK_COMMAND: kb
> BUCKET_ID:
> 0xC1_Vba32dNT!CRootDeviceExtension::_ForwardedRequestCompletionRoutine+bc
> Followup: MachineOwner
> ---------
>
> The target OS is Win2K SP2 checked. The “Rolling Your Own IRP” article on
> the OSR says that this may appear when “important IRP field (Zoned flag)
is
> cleared, which cause subsequent call to IoFreeIrp to call ExFreePool on
that
> IRP”. But I don’t see any problem here. It’s also strange that the code
> fails basicly on executable files (actually it never bugchecked on
anything
> but .dll’s).
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> To unsubscribe send a blank email to %%email.unsub%%
>

3

I found that error appears only when STATUS_PENDING was returned from the
underlying FSD.

----- Original Message -----
From: “Alexey Logachyov”
To: “File Systems Developers”
Sent: Wednesday, October 30, 2002 4:48 PM
Subject: [ntfsd] Re: Rolling own IRP

> I wanted to add that bugchecking on .dll file is just a coincidence. I
> crashes on every other kind of files as well.
>
>
> ----- Original Message -----
> From: “Alexey Logachyov”
> To: “File Systems Developers”
> Sent: Wednesday, October 30, 2002 4:01 PM
> Subject: [ntfsd] Rolling own IRP
>
>
> > In my FSFD in need to implement the following behavior. When user
requests
> > some operation on my file (e.g. IRP_MJ_READ) I want to perform this
> > operation for another FO. Here’s extract from my sources.
> >
> > NTSTATUS OnRead(PIRP IrpPtr)
> > {
> > // extract information from file object
> > PFILE_OBJECT FileObjectPtr =
> > IoGetCurrentIrpStackLocation(IrpPtr)->FileObject;
> > PFILE_OBJECT OriginalFileObjectPtr =
> (PFILE_OBJECT)FileObjectPtr->FsContext;
> > PDEVICE_OBJECT TargetDevicePtr =
> (PDEVICE_OBJECT)FileObjectPtr->FsContext2;
> > // allocate irp
> > PIRP ReadIrpPtr = IoAllocateIrp(TargetDevicePtr->StackSize, FALSE);
> > if (NULL == ReadIrpPtr)
> > {
> > IrpPtr->IoStatus.Information = 0;
> > IrpPtr->IoStatus.Status = STATUS_INSUFFICIENT_RESOURCES;
> > IoCompleteRequest(IrpPtr, IO_NO_INCREMENT);
> > return STATUS_INSUFFICIENT_RESOURCES;
> > }
> > // initialize irp
> > ReadIrpPtr->AssociatedIrp.SystemBuffer =
> IrpPtr->AssociatedIrp.SystemBuffer;
> > ReadIrpPtr->MdlAddress = IrpPtr->MdlAddress;
> > ReadIrpPtr->UserBuffer = IrpPtr->UserBuffer;
> > ReadIrpPtr->Tail.Overlay.Thread = IrpPtr->Tail.Overlay.Thread;
> > ReadIrpPtr->Flags = IrpPtr->Flags;
> > // initialize next irp stack location
> > PIO_STACK_LOCATION CurrentIrpStackLocationPtr =
> > IoGetCurrentIrpStackLocation(IrpPtr);
> > PIO_STACK_LOCATION NextIrpStackLocationPtr =
> > IoGetNextIrpStackLocation(ReadIrpPtr);
> > NextIrpStackLocationPtr->DeviceObject = TargetDevicePtr;
> > NextIrpStackLocationPtr->FileObject = OriginalFileObjectPtr;
> > NextIrpStackLocationPtr->MajorFunction =
> > CurrentIrpStackLocationPtr->MajorFunction;
> > NextIrpStackLocationPtr->MinorFunction =
> > CurrentIrpStackLocationPtr->MinorFunction;
> > NextIrpStackLocationPtr->Flags = CurrentIrpStackLocationPtr->Flags;
> > NextIrpStackLocationPtr->Parameters.Read =
> > CurrentIrpStackLocationPtr->Parameters.Read;
> > // set completion routine
> > IoSetCompletionRoutine(ReadIrpPtr, _ForwardedRequestCompletionRoutine,
> > IrpPtr, TRUE, TRUE, TRUE);
> > return IoCallDriver(TargetDevicePtr, ReadIrpPtr);
> > }
> > static NTSTATUS _ForwardedRequestCompletionRoutine(PDEVICE_OBJECT
> > DeviceObjectPtr, PIRP IrpPtr, PVOID ContextPtr)
> > {
> > PIRP OriginalIrpPtr = (PIRP)ContextPtr;
> > if (IrpPtr->PendingReturned)
> > {
> > IoMarkIrpPending(IrpPtr);
> > IoMarkIrpPending(OriginalIrpPtr);
> > }
> > //
> > OriginalIrpPtr->AssociatedIrp.SystemBuffer =
> > IrpPtr->AssociatedIrp.SystemBuffer;
> > OriginalIrpPtr->MdlAddress = IrpPtr->MdlAddress;
> > OriginalIrpPtr->UserBuffer = IrpPtr->UserBuffer;
> > OriginalIrpPtr->IoStatus = IrpPtr->IoStatus;
> > OriginalIrpPtr->Flags = IrpPtr->Flags;
> > IoCompleteRequest(OriginalIrpPtr, IO_NO_INCREMENT);
> > //
> > IrpPtr->AssociatedIrp.SystemBuffer = NULL;
> > IrpPtr->MdlAddress = NULL;
> > IrpPtr->UserBuffer = NULL;
> > IoFreeIrp(IrpPtr);
> > //
> > return STATUS_MORE_PROCESSING_REQUIRED;
> > }
> >
> > The problem is I often get the following bugcheck on some kinds of
> original
> > FO (for example ones that represent .dll’s cause a BSOD).
> >
> >
>
*************************************************************************
> >
> > * *
> > * Bugcheck Analysis *
> > * *
> >
>
*************************************************************************
> >
> > SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION (c1)
> > Special pool has detected memory corruption. Typically the current
> thread’s
> > stack backtrace will reveal the guilty party.
> > Arguments:
> > Arg1: acdcde90, address trying to free
> > Arg2: acdcdfff, address where bits are corrupted
> > Arg3: 1200016c, (reserved)
> > Arg4: 00000024, caller is freeing an address where bytes after the end
of
> > the allocation have been overwritten
> > Debugging Details:
> > ------------------
> >
> > SPECIAL_POOL_CORRUPTION_TYPE: 24
> > DEFAULT_BUCKET_ID: DRIVER_FAULT
> > BUGCHECK_STR: 0xC1
> > LAST_CONTROL_TRANSFER: from 80438bab to 804a9bcc
> > STACK_TEXT:
> > eb437708 80438bab 00000003 eb437750 acdcde90
> > nt!RtlpBreakWithStatusInstruction
> > eb437738 8043919e 00000003 c02b3734 0000016c
nt!KiBugCheckDebugBreak+0x31
> > eb437ac4 8062119d 000000c1 acdcde90 acdcdfff nt!KeBugCheckEx+0x390
> > eb437b08 804c5f3b acdcde90 eb437b8c acdcde90 nt!MmFreeSpecialPool+0x1f2
> > eb437b3c 804c5e13 acdcde90 00000000 eb437b70 nt!ExFreePoolWithTag+0x22
> > eb437b4c 80436187 acdcde90 815add48 8060b84c nt!ExFreePool+0xd
> > eb437b58 8060b84c acdcde90 000000c9 00000000
> > nt!IovpProtectedIrpMakeUntouchable+0x11
> > eb437b70 80607c4e acdcdff4 acdcde90 00000000 nt!IovpFreeIrp+0x15d
> > eb437b84 80607bf3 acdcde90 eb437ba0 eb033b5c nt!IovFreeIrpPrivate+0x56
> > eb437b90 eb033b5c acdcde90 acdcbf68 eb437bec nt!IovFreeIrp+0xb
> > eb437ba0 8060828d 00000000 acdcde90 acdcbf68
> > Vba32dNT!CRootDeviceExtension::_ForwardedRequestCompletionRoutine+0xbc
> > [r:\projects@vba4\monitor\fsffilter\rootdev.h @ 69]
> > eb437bec bfe72216 816e5b68 eb437ce0 bfe732d6
> > nt!IovSpecialIrpCompleteRequest+0x1f7
> > eb437bf8 bfe732d6 816e5b68 acdcde90 00000000
> > Fastfat!FatCompleteRequest_Real+0x64
> > eb437ce0 bfe95780 816e5b68 acdcde90 816e5b6c Fastfat!FatCommonRead+0x951
> > eb437d40 8041c1ec 816e5b68 00000000 00000000 Fastfat!FatFspDispatch+0xf3
> > eb437da8 804a91e6 00000000 00000000 00000000 nt!ExpWorkerThread+0x106
> > eb437ddc 804c3d4a 8041c0e6 00000000 00000000
> nt!PspSystemThreadStartup+0x54
> > 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
> >
> > FOLLOWUP_IP:
> > Vba32dNT!CRootDeviceExtension::_ForwardedRequestCompletionRoutine+bc
> > eb033b5c b8160000c0 mov eax,0xc0000016
> > FOLLOWUP_NAME: MachineOwner
> > SYMBOL_NAME:
> > Vba32dNT!CRootDeviceExtension::_ForwardedRequestCompletionRoutine+bc
> > MODULE_NAME: Vba32dNT
> > IMAGE_NAME: Vba32dNT.sys
> > DEBUG_FLR_IMAGE_TIMESTAMP: 3dbfda48
> > STACK_COMMAND: kb
> > BUCKET_ID:
> >
0xC1_Vba32dNT!CRootDeviceExtension::_ForwardedRequestCompletionRoutine+bc
> > Followup: MachineOwner
> > ---------
> >
> > The target OS is Win2K SP2 checked. The “Rolling Your Own IRP” article
on
> > the OSR says that this may appear when “important IRP field (Zoned flag)
> is
> > cleared, which cause subsequent call to IoFreeIrp to call ExFreePool on
> that
> > IRP”. But I don’t see any problem here. It’s also strange that the code
> > fails basicly on executable files (actually it never bugchecked on
> anything
> > but .dll’s).
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> To unsubscribe send a blank email to %%email.unsub%%
>

4

Ah! Stupid me. Allocated IRP does not have current IRP stack location. So,
calling IoMarkIrpPending causes special pool corruption.

----- Original Message -----
From: “Alexey Logachyov”
To: “File Systems Developers”
Sent: Wednesday, October 30, 2002 5:45 PM
Subject: [ntfsd] Re: Rolling own IRP

> I found that error appears only when STATUS_PENDING was returned from the
> underlying FSD.
>
> ----- Original Message -----
> From: “Alexey Logachyov”
> To: “File Systems Developers”
> Sent: Wednesday, October 30, 2002 4:48 PM
> Subject: [ntfsd] Re: Rolling own IRP
>
>
> > I wanted to add that bugchecking on .dll file is just a coincidence. I
> > crashes on every other kind of files as well.
> >
> >
> > ----- Original Message -----
> > From: “Alexey Logachyov”
> > To: “File Systems Developers”
> > Sent: Wednesday, October 30, 2002 4:01 PM
> > Subject: [ntfsd] Rolling own IRP
> >
> >
> > > In my FSFD in need to implement the following behavior. When user
> requests
> > > some operation on my file (e.g. IRP_MJ_READ) I want to perform this
> > > operation for another FO. Here’s extract from my sources.
> > >
> > > NTSTATUS OnRead(PIRP IrpPtr)
> > > {
> > > // extract information from file object
> > > PFILE_OBJECT FileObjectPtr =
> > > IoGetCurrentIrpStackLocation(IrpPtr)->FileObject;
> > > PFILE_OBJECT OriginalFileObjectPtr =
> > (PFILE_OBJECT)FileObjectPtr->FsContext;
> > > PDEVICE_OBJECT TargetDevicePtr =
> > (PDEVICE_OBJECT)FileObjectPtr->FsContext2;
> > > // allocate irp
> > > PIRP ReadIrpPtr = IoAllocateIrp(TargetDevicePtr->StackSize, FALSE);
> > > if (NULL == ReadIrpPtr)
> > > {
> > > IrpPtr->IoStatus.Information = 0;
> > > IrpPtr->IoStatus.Status = STATUS_INSUFFICIENT_RESOURCES;
> > > IoCompleteRequest(IrpPtr, IO_NO_INCREMENT);
> > > return STATUS_INSUFFICIENT_RESOURCES;
> > > }
> > > // initialize irp
> > > ReadIrpPtr->AssociatedIrp.SystemBuffer =
> > IrpPtr->AssociatedIrp.SystemBuffer;
> > > ReadIrpPtr->MdlAddress = IrpPtr->MdlAddress;
> > > ReadIrpPtr->UserBuffer = IrpPtr->UserBuffer;
> > > ReadIrpPtr->Tail.Overlay.Thread = IrpPtr->Tail.Overlay.Thread;
> > > ReadIrpPtr->Flags = IrpPtr->Flags;
> > > // initialize next irp stack location
> > > PIO_STACK_LOCATION CurrentIrpStackLocationPtr =
> > > IoGetCurrentIrpStackLocation(IrpPtr);
> > > PIO_STACK_LOCATION NextIrpStackLocationPtr =
> > > IoGetNextIrpStackLocation(ReadIrpPtr);
> > > NextIrpStackLocationPtr->DeviceObject = TargetDevicePtr;
> > > NextIrpStackLocationPtr->FileObject = OriginalFileObjectPtr;
> > > NextIrpStackLocationPtr->MajorFunction =
> > > CurrentIrpStackLocationPtr->MajorFunction;
> > > NextIrpStackLocationPtr->MinorFunction =
> > > CurrentIrpStackLocationPtr->MinorFunction;
> > > NextIrpStackLocationPtr->Flags = CurrentIrpStackLocationPtr->Flags;
> > > NextIrpStackLocationPtr->Parameters.Read =
> > > CurrentIrpStackLocationPtr->Parameters.Read;
> > > // set completion routine
> > > IoSetCompletionRoutine(ReadIrpPtr, _ForwardedRequestCompletionRoutine,
> > > IrpPtr, TRUE, TRUE, TRUE);
> > > return IoCallDriver(TargetDevicePtr, ReadIrpPtr);
> > > }
> > > static NTSTATUS _ForwardedRequestCompletionRoutine(PDEVICE_OBJECT
> > > DeviceObjectPtr, PIRP IrpPtr, PVOID ContextPtr)
> > > {
> > > PIRP OriginalIrpPtr = (PIRP)ContextPtr;
> > > if (IrpPtr->PendingReturned)
> > > {
> > > IoMarkIrpPending(IrpPtr);
> > > IoMarkIrpPending(OriginalIrpPtr);
> > > }
> > > //
> > > OriginalIrpPtr->AssociatedIrp.SystemBuffer =
> > > IrpPtr->AssociatedIrp.SystemBuffer;
> > > OriginalIrpPtr->MdlAddress = IrpPtr->MdlAddress;
> > > OriginalIrpPtr->UserBuffer = IrpPtr->UserBuffer;
> > > OriginalIrpPtr->IoStatus = IrpPtr->IoStatus;
> > > OriginalIrpPtr->Flags = IrpPtr->Flags;
> > > IoCompleteRequest(OriginalIrpPtr, IO_NO_INCREMENT);
> > > //
> > > IrpPtr->AssociatedIrp.SystemBuffer = NULL;
> > > IrpPtr->MdlAddress = NULL;
> > > IrpPtr->UserBuffer = NULL;
> > > IoFreeIrp(IrpPtr);
> > > //
> > > return STATUS_MORE_PROCESSING_REQUIRED;
> > > }
> > >
> > > The problem is I often get the following bugcheck on some kinds of
> > original
> > > FO (for example ones that represent .dll’s cause a BSOD).
> > >
> > >
> >
>
*************************************************************************
> > >
> > > * *
> > > * Bugcheck Analysis *
> > > * *
> > >
> >
>
*************************************************************************
> > >
> > > SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION (c1)
> > > Special pool has detected memory corruption. Typically the current
> > thread’s
> > > stack backtrace will reveal the guilty party.
> > > Arguments:
> > > Arg1: acdcde90, address trying to free
> > > Arg2: acdcdfff, address where bits are corrupted
> > > Arg3: 1200016c, (reserved)
> > > Arg4: 00000024, caller is freeing an address where bytes after the end
> of
> > > the allocation have been overwritten
> > > Debugging Details:
> > > ------------------
> > >
> > > SPECIAL_POOL_CORRUPTION_TYPE: 24
> > > DEFAULT_BUCKET_ID: DRIVER_FAULT
> > > BUGCHECK_STR: 0xC1
> > > LAST_CONTROL_TRANSFER: from 80438bab to 804a9bcc
> > > STACK_TEXT:
> > > eb437708 80438bab 00000003 eb437750 acdcde90
> > > nt!RtlpBreakWithStatusInstruction
> > > eb437738 8043919e 00000003 c02b3734 0000016c
> nt!KiBugCheckDebugBreak+0x31
> > > eb437ac4 8062119d 000000c1 acdcde90 acdcdfff nt!KeBugCheckEx+0x390
> > > eb437b08 804c5f3b acdcde90 eb437b8c acdcde90
nt!MmFreeSpecialPool+0x1f2
> > > eb437b3c 804c5e13 acdcde90 00000000 eb437b70 nt!ExFreePoolWithTag+0x22
> > > eb437b4c 80436187 acdcde90 815add48 8060b84c nt!ExFreePool+0xd
> > > eb437b58 8060b84c acdcde90 000000c9 00000000
> > > nt!IovpProtectedIrpMakeUntouchable+0x11
> > > eb437b70 80607c4e acdcdff4 acdcde90 00000000 nt!IovpFreeIrp+0x15d
> > > eb437b84 80607bf3 acdcde90 eb437ba0 eb033b5c nt!IovFreeIrpPrivate+0x56
> > > eb437b90 eb033b5c acdcde90 acdcbf68 eb437bec nt!IovFreeIrp+0xb
> > > eb437ba0 8060828d 00000000 acdcde90 acdcbf68
> > > Vba32dNT!CRootDeviceExtension::_ForwardedRequestCompletionRoutine+0xbc
> > > [r:\projects@vba4\monitor\fsffilter\rootdev.h @ 69]
> > > eb437bec bfe72216 816e5b68 eb437ce0 bfe732d6
> > > nt!IovSpecialIrpCompleteRequest+0x1f7
> > > eb437bf8 bfe732d6 816e5b68 acdcde90 00000000
> > > Fastfat!FatCompleteRequest_Real+0x64
> > > eb437ce0 bfe95780 816e5b68 acdcde90 816e5b6c
Fastfat!FatCommonRead+0x951
> > > eb437d40 8041c1ec 816e5b68 00000000 00000000
Fastfat!FatFspDispatch+0xf3
> > > eb437da8 804a91e6 00000000 00000000 00000000 nt!ExpWorkerThread+0x106
> > > eb437ddc 804c3d4a 8041c0e6 00000000 00000000
> > nt!PspSystemThreadStartup+0x54
> > > 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
> > >
> > > FOLLOWUP_IP:
> > > Vba32dNT!CRootDeviceExtension::_ForwardedRequestCompletionRoutine+bc
> > > eb033b5c b8160000c0 mov eax,0xc0000016
> > > FOLLOWUP_NAME: MachineOwner
> > > SYMBOL_NAME:
> > > Vba32dNT!CRootDeviceExtension::_ForwardedRequestCompletionRoutine+bc
> > > MODULE_NAME: Vba32dNT
> > > IMAGE_NAME: Vba32dNT.sys
> > > DEBUG_FLR_IMAGE_TIMESTAMP: 3dbfda48
> > > STACK_COMMAND: kb
> > > BUCKET_ID:
> > >
> 0xC1_Vba32dNT!CRootDeviceExtension::_ForwardedRequestCompletionRoutine+bc
> > > Followup: MachineOwner
> > > ---------
> > >
> > > The target OS is Win2K SP2 checked. The “Rolling Your Own IRP” article
> on
> > > the OSR says that this may appear when “important IRP field (Zoned
flag)
> > is
> > > cleared, which cause subsequent call to IoFreeIrp to call ExFreePool
on
> > that
> > > IRP”. But I don’t see any problem here. It’s also strange that the
code
> > > fails basicly on executable files (actually it never bugchecked on
> > anything
> > > but .dll’s).
> > >
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> > > To unsubscribe send a blank email to %%email.unsub%%
> > >
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> To unsubscribe send a blank email to %%email.unsub%%
>