IoCallDriver and Filter driver question.

NTDEV
1

Hello,

I have a volume filter (based on toaster filter samples)
that attaches on top of the parition object
“\Device\Harddisk1\Partition0” by calling IoAttachDevice

The filter driver does not do much. It prints out some debug
info then passes everything down to the next lower driver.

I have another device driver that needs perform data read from the
partition.
The driver does this by keeping a pointer to the partition device object.
////
IoGetDeviceObjectPointer
(&ntDeviceName, // L"\Device\Harddisk1\Partition0"
, …);
pDevObj->AlignmentRequirement =
pTargetDevObj->AlignmentRequirement;
pDevObj->StackSize = pTargetDevObj->StackSize + 1;
////

To perform a read, this driver will builds a Read IRP using
IoBuildSynchronousFsdRequest and then calls
IoCallDriver(pTargetDevObj, readIrp)

I load the drivers, issue a read and get this error
////
Access violation - code c0000005 (!!! second chance !!!)
CLASSPNP!ServiceTransferRequest+159:
f95a9055 8b4010 mov eax,[eax+0x10] ;eax = 0 here
////

and the stack_text is:
f765c564 f95aa256 823c6038 81db1808 823c6038
CLASSPNP!ServiceTransferRequest+0x159
f765c5b4 80a2675c 823c6038 81db1808 81db1808 CLASSPNP!ClassReadWrite+0x28e
f765c5d0 f983595f 823c6dc0 81db1808 00000000 nt!IofCallDriver+0x62
f765c5e8 80a2675c 823c6dc0 81db1808 81e55048 PartMgr!PmReadWrite+0xb5
f765c604 f9c1dd1e 00000001 81e55100 00000000 nt!IofCallDriver+0x62
f765c61c 80a2675c 81e55048 81db1808 f765c8cc MY_FILTER!FltrPassDown+0x1ce
[u:\my_filter\fltr.c @ 363]
f765c638 f78cdf32 00000001 00000001 00000001 nt!IofCallDriver+0x62
f765c664 f78c8617 81e55048 f765c6c4 00000200
MY_DEVICE!ReadPartitionDevice+0x1d2 [u:\my_device\dev.c @ 114]
…

I check the irq levels, Irp fields, etc. They all have reasonable values.
If I run only one driver at a time then everything works fine.
My filter will see and pass down the read requests.
My other device driver will read the correct data from the partition.
But together they won’t go. Please shed some light on my confusion.

Thanks.

Chu Bun

2

Show us the code where you’re calling IoBuildSynchronousFsdRequest,
setting up the next stack location, and invoking IoCallDriver.

ChuBun wrote:

Hello,

I have a volume filter (based on toaster filter samples)
that attaches on top of the parition object
“\Device\Harddisk1\Partition0” by calling IoAttachDevice

The filter driver does not do much. It prints out some debug
info then passes everything down to the next lower driver.

I have another device driver that needs perform data read from the
partition.
The driver does this by keeping a pointer to the partition device object.
////
IoGetDeviceObjectPointer
(&ntDeviceName, // L"\Device\Harddisk1\Partition0"
, …);
pDevObj->AlignmentRequirement =
pTargetDevObj->AlignmentRequirement;
pDevObj->StackSize = pTargetDevObj->StackSize + 1;
////

To perform a read, this driver will builds a Read IRP using
IoBuildSynchronousFsdRequest and then calls
IoCallDriver(pTargetDevObj, readIrp)

I load the drivers, issue a read and get this error
////
Access violation - code c0000005 (!!! second chance !!!)
CLASSPNP!ServiceTransferRequest+159:
f95a9055 8b4010 mov eax,[eax+0x10] ;eax = 0 here
////

and the stack_text is:
f765c564 f95aa256 823c6038 81db1808 823c6038
CLASSPNP!ServiceTransferRequest+0x159
f765c5b4 80a2675c 823c6038 81db1808 81db1808 CLASSPNP!ClassReadWrite+0x28e
f765c5d0 f983595f 823c6dc0 81db1808 00000000 nt!IofCallDriver+0x62
f765c5e8 80a2675c 823c6dc0 81db1808 81e55048 PartMgr!PmReadWrite+0xb5
f765c604 f9c1dd1e 00000001 81e55100 00000000 nt!IofCallDriver+0x62
f765c61c 80a2675c 81e55048 81db1808 f765c8cc MY_FILTER!FltrPassDown+0x1ce
[u:\my_filter\fltr.c @ 363]
f765c638 f78cdf32 00000001 00000001 00000001 nt!IofCallDriver+0x62
f765c664 f78c8617 81e55048 f765c6c4 00000200
MY_DEVICE!ReadPartitionDevice+0x1d2 [u:\my_device\dev.c @ 114]
…

I check the irq levels, Irp fields, etc. They all have reasonable values.
If I run only one driver at a time then everything works fine.
My filter will see and pass down the read requests.
My other device driver will read the correct data from the partition.
But together they won’t go. Please shed some light on my confusion.

Thanks.

Chu Bun

–
Nick Ryan (MVP for DDK)

3

Here is the routine. Usually, this routine is called inside a
driver-created worker thread. But in this case the call is
inside the IOCTL dispatch routine.

//// based on romfs::FsdReadBlockDevice by Bo Brantén
NTSTATUS ReadPartitionDevice(
IN PDEVICE_OBJECT pTargetDevObj,
IN PLARGE_INTEGER Offset,
IN ULONG Length,
IN OUT PVOID Buffer,
OUT PIO_STATUS_BLOCK pIoStatus)
{
KEVENT Event;
PIRP Irp;
NTSTATUS Status;

DBGPRINT((“ReadPartitionDevice in. irql: %d\n”,
KeGetCurrentIrql())); // irql = 0 here

ASSERT(pTargetDevObj != NULL);
ASSERT(Offset != NULL);
ASSERT(Buffer != NULL);

Status = STATUS_INSUFFICIENT_RESOURCES;
pIoStatus->Status = Status;
pIoStatus->Information = 0;

// DBGPRINT((" valid buf: %d\n", MmIsAddressValid(Buffer)));
// DBGPRINT((" valid iostatus: %d\n", MmIsAddressValid(pIoStatus)));
// DBGPRINT((" len: %d\n", Length));
// DBGPRINT((" targetDevObj: %p\n", pTargetDevObj));

KeInitializeEvent(&Event, NotificationEvent, FALSE);

DBGPRINT((" Build io request. offset: %I64d, len: %d\n",
Offset->QuadPart,
Length));

Irp = IoBuildSynchronousFsdRequest(
IRP_MJ_READ,
pTargetDevObj,
Buffer,
Length,
Offset,
&Event,
pIoStatus
);

if(!Irp)
{
DBGPRINT((“ReadPartitionDevice out. (build failed)\n”));
return STATUS_INSUFFICIENT_RESOURCES;
}

DBGPRINT((" Forward request to target device\n"));
Status = IoCallDriver(pTargetDevObj, Irp);

// need completion routine as in KB 326315 here ???

if(Status == STATUS_PENDING)
{
KeWaitForSingleObject(
&Event,
Executive,
KernelMode,
FALSE,
NULL
);
Status = pIoStatus->Status;
}

DBGPRINT((“ReadPartitionDevice out\n”));
return Status;
}
////

“Nick Ryan” wrote in message news:xxxxx@ntdev…
>
> Show us the code where you’re calling IoBuildSynchronousFsdRequest,
> setting up the next stack location, and invoking IoCallDriver.
>
> ChuBun wrote:
>
> > Hello,
> >
> > I have a volume filter (based on toaster filter samples)
> > that attaches on top of the parition object
> > “\Device\Harddisk1\Partition0” by calling IoAttachDevice
> >
> > The filter driver does not do much. It prints out some debug
> > info then passes everything down to the next lower driver.
> >
> > I have another device driver that needs perform data read from the
> > partition.
> > The driver does this by keeping a pointer to the partition device
object.
> > ////
> > IoGetDeviceObjectPointer
> > (&ntDeviceName, // L"\Device\Harddisk1\Partition0"
> > , …);
> > pDevObj->AlignmentRequirement =
> > pTargetDevObj->AlignmentRequirement;
> > pDevObj->StackSize = pTargetDevObj->StackSize + 1;
> > ////
> >
> > To perform a read, this driver will builds a Read IRP using
> > IoBuildSynchronousFsdRequest and then calls
> > IoCallDriver(pTargetDevObj, readIrp)
> >
> > I load the drivers, issue a read and get this error
> > ////
> > Access violation - code c0000005 (!!! second chance !!!)
> > CLASSPNP!ServiceTransferRequest+159:
> > f95a9055 8b4010 mov eax,[eax+0x10] ;eax = 0 here
> > ////
> >
> > and the stack_text is:
> > f765c564 f95aa256 823c6038 81db1808 823c6038
> > CLASSPNP!ServiceTransferRequest+0x159
> > f765c5b4 80a2675c 823c6038 81db1808 81db1808
CLASSPNP!ClassReadWrite+0x28e
> > f765c5d0 f983595f 823c6dc0 81db1808 00000000 nt!IofCallDriver+0x62
> > f765c5e8 80a2675c 823c6dc0 81db1808 81e55048 PartMgr!PmReadWrite+0xb5
> > f765c604 f9c1dd1e 00000001 81e55100 00000000 nt!IofCallDriver+0x62
> > f765c61c 80a2675c 81e55048 81db1808 f765c8cc
MY_FILTER!FltrPassDown+0x1ce
> > [u:\my_filter\fltr.c @ 363]
> > f765c638 f78cdf32 00000001 00000001 00000001 nt!IofCallDriver+0x62
> > f765c664 f78c8617 81e55048 f765c6c4 00000200
> > MY_DEVICE!ReadPartitionDevice+0x1d2 [u:\my_device\dev.c @ 114]
> > …
> >
> > I check the irq levels, Irp fields, etc. They all have reasonable
values.
> > If I run only one driver at a time then everything works fine.
> > My filter will see and pass down the read requests.
> > My other device driver will read the correct data from the partition.
> > But together they won’t go. Please shed some light on my confusion.
> >
> > Thanks.
> >
> > Chu Bun
> >
> >
> >
> >
>
> –
> Nick Ryan (MVP for DDK)
>
>
>

4

Heck, I’m stumped, it looks good to me. (No, you don’t need to set a
completion routine if you’re calling IoBuildSynchronousFsdRequest.) What
build of the OS are you testing on, service pack, and free/checked? This
will allow me to tell exactly what the code that faults in classpnp.sys
is doing (it’s building a SCSI request that the lower drivers can
understand).

That KB article you mention, 326315 (part 2, part 1 is 320275) is great,
I hadn’t seen that before. For those who haven’t seen it, it’s a ‘cheat
sheet’ describing 11 different scenarios one can encounter while
handling an IRP, with detailed code samples. I didn’t know Microsoft had
put out something like this.

ChuBun wrote:

Here is the routine. Usually, this routine is called inside a
driver-created worker thread. But in this case the call is
inside the IOCTL dispatch routine.

//// based on romfs::FsdReadBlockDevice by Bo Brantén
NTSTATUS ReadPartitionDevice(
IN PDEVICE_OBJECT pTargetDevObj,
IN PLARGE_INTEGER Offset,
IN ULONG Length,
IN OUT PVOID Buffer,
OUT PIO_STATUS_BLOCK pIoStatus)
{
KEVENT Event;
PIRP Irp;
NTSTATUS Status;

DBGPRINT((“ReadPartitionDevice in. irql: %d\n”,
KeGetCurrentIrql())); // irql = 0 here

ASSERT(pTargetDevObj != NULL);
ASSERT(Offset != NULL);
ASSERT(Buffer != NULL);

Status = STATUS_INSUFFICIENT_RESOURCES;
pIoStatus->Status = Status;
pIoStatus->Information = 0;

// DBGPRINT((" valid buf: %d\n", MmIsAddressValid(Buffer)));
// DBGPRINT((" valid iostatus: %d\n", MmIsAddressValid(pIoStatus)));
// DBGPRINT((" len: %d\n", Length));
// DBGPRINT((" targetDevObj: %p\n", pTargetDevObj));

KeInitializeEvent(&Event, NotificationEvent, FALSE);

DBGPRINT((" Build io request. offset: %I64d, len: %d\n",
Offset->QuadPart,
Length));

Irp = IoBuildSynchronousFsdRequest(
IRP_MJ_READ,
pTargetDevObj,
Buffer,
Length,
Offset,
&Event,
pIoStatus
);

if(!Irp)
{
DBGPRINT((“ReadPartitionDevice out. (build failed)\n”));
return STATUS_INSUFFICIENT_RESOURCES;
}

DBGPRINT((" Forward request to target device\n"));
Status = IoCallDriver(pTargetDevObj, Irp);

// need completion routine as in KB 326315 here ???

if(Status == STATUS_PENDING)
{
KeWaitForSingleObject(
&Event,
Executive,
KernelMode,
FALSE,
NULL
);
Status = pIoStatus->Status;
}

DBGPRINT((“ReadPartitionDevice out\n”));
return Status;
}
////

“Nick Ryan” wrote in message news:xxxxx@ntdev…
>
>>Show us the code where you’re calling IoBuildSynchronousFsdRequest,
>>setting up the next stack location, and invoking IoCallDriver.
>>
>>ChuBun wrote:
>>
>>
>>>Hello,
>>>
>>>I have a volume filter (based on toaster filter samples)
>>>that attaches on top of the parition object
>>>“\Device\Harddisk1\Partition0” by calling IoAttachDevice
>>>
>>>The filter driver does not do much. It prints out some debug
>>>info then passes everything down to the next lower driver.
>>>
>>>I have another device driver that needs perform data read from the
>>>partition.
>>>The driver does this by keeping a pointer to the partition device
>
> object.
>
>>>////
>>> IoGetDeviceObjectPointer
>>> (&ntDeviceName, // L"\Device\Harddisk1\Partition0"
>>> , …);
>>> pDevObj->AlignmentRequirement =
>>> pTargetDevObj->AlignmentRequirement;
>>> pDevObj->StackSize = pTargetDevObj->StackSize + 1;
>>>////
>>>
>>>To perform a read, this driver will builds a Read IRP using
>>>IoBuildSynchronousFsdRequest and then calls
>>>IoCallDriver(pTargetDevObj, readIrp)
>>>
>>>I load the drivers, issue a read and get this error
>>>////
>>>Access violation - code c0000005 (!!! second chance !!!)
>>>CLASSPNP!ServiceTransferRequest+159:
>>>f95a9055 8b4010 mov eax,[eax+0x10] ;eax = 0 here
>>>////
>>>
>>>and the stack_text is:
>>>f765c564 f95aa256 823c6038 81db1808 823c6038
>>>CLASSPNP!ServiceTransferRequest+0x159
>>>f765c5b4 80a2675c 823c6038 81db1808 81db1808
>
> CLASSPNP!ClassReadWrite+0x28e
>
>>>f765c5d0 f983595f 823c6dc0 81db1808 00000000 nt!IofCallDriver+0x62
>>>f765c5e8 80a2675c 823c6dc0 81db1808 81e55048 PartMgr!PmReadWrite+0xb5
>>>f765c604 f9c1dd1e 00000001 81e55100 00000000 nt!IofCallDriver+0x62
>>>f765c61c 80a2675c 81e55048 81db1808 f765c8cc
>
> MY_FILTER!FltrPassDown+0x1ce
>
>>>[u:\my_filter\fltr.c @ 363]
>>>f765c638 f78cdf32 00000001 00000001 00000001 nt!IofCallDriver+0x62
>>>f765c664 f78c8617 81e55048 f765c6c4 00000200
>>>MY_DEVICE!ReadPartitionDevice+0x1d2 [u:\my_device\dev.c @ 114]
>>>…
>>>
>>>I check the irq levels, Irp fields, etc. They all have reasonable
>
> values.
>
>>>If I run only one driver at a time then everything works fine.
>>>My filter will see and pass down the read requests.
>>>My other device driver will read the correct data from the partition.
>>>But together they won’t go. Please shed some light on my confusion.
>>>
>>>Thanks.
>>>
>>>Chu Bun
>>>
>>>
>>>
>>>
>>
>>–
>>Nick Ryan (MVP for DDK)
>>
>>
>>
>
>
>
>
>

–
Nick Ryan (MVP for DDK)

5

ChuBun,

you wrote on Tuesday, September 23, 2003, 22:43:21:

C> I have a volume filter (based on toaster filter samples)
C> that attaches on top of the parition object
C> “\Device\Harddisk1\Partition0” by calling IoAttachDevice

I’m not a kernel guy so I’m probably missing something, but remember
that \Device\Harddisk1X\Partition0 refers to the physical disk, not the
first partition on the disk. That is, Partition0 is always the RAW file
system. Partitions are numbered one-based. See also WinObj.

Just wanted to make sure you are attaching to what you think you are
attaching to.

Ralf.

6

My test machine is a unpatched Windows 2003 check build version.
////
Windows Server 2003 Kernel Version 3790 MP (1 procs) Checked x86 compatible
Built by: 3790.srv03_rtm.030324-2048
////
I guess this could be a stack size problem and try to increase
pDevObj->StackSize of both drivers but that doesnt help.

Here is the entire print out from !analyze -v
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: f95a9055, The address that the exception occurred at
Arg3: f7670914, Exception Record Address
Arg4: f7670564, Context Record Address

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx”
referenced memory at “0x%08lx”. The memory could not be “%s”.

FAULTING_IP:
CLASSPNP!ServiceTransferRequest+159
f95a9055 8b4010 mov eax,[eax+0x10]

EXCEPTION_PARAMETER1: f7670914

CONTEXT: f7670564 – (.cxr fffffffff7670564)
eax=00000000 ebx=00000000 ecx=00000000 edx=00000002 esi=81e26e70
edi=823c6038
eip=f95a9055 esp=f76709dc ebp=f7670a7c iopl=0 nv up ei pl zr na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
CLASSPNP!ServiceTransferRequest+159:
f95a9055 8b4010 mov eax,[eax+0x10]
Resetting default context

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x7E

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from f95aa256 to f95a9055

STACK_TEXT:
f7670a7c f95aa256 823c6038 81e26e70 823c6038
CLASSPNP!ServiceTransferRequest+0x159
f7670acc 80a2675c 823c6038 81e26e70 81e26e70 CLASSPNP!ClassReadWrite+0x28e
f7670ae8 f983595f 823c6dc0 81e26e70 00000000 nt!IofCallDriver+0x62
f7670b00 80a2675c 823c6dc0 81e26e70 ffaabeb0 PartMgr!PmReadWrite+0xb5
f7670b1c f9badd65 00000001 ffaabf68 00000000 nt!IofCallDriver+0x62
f7670b34 80a2675c ffaabeb0 81e26e70 00000000
my_filter!my_filterPassDown+0x1e5 [u:\my_filter\my_filter.c @ 363]
f7670b50 f6d89f62 00000001 00000001 00000001 nt!IofCallDriver+0x62
f7670b7c f6d884b5 ffaabeb0 f7670ba4 00010000
my_drv!ReadPartitionDevice+0x1d2 [u:\my_drv\blockdev.c @ 114]
f7670bb4 f6d87af9 81db7428 00000000 f7670c38 my_drv!ReadSectors+0x195
[u:\my_drv\my_drv.c @ 2115]
f7670d7c f6d899dc 81db7370 81df0b80 00000003 my_drv!DoVolumeIO+0xdd9
[u:\my_drv\my_drv.c @ 1937]
f7670dac 80d391d0 81db7428 00000000 00000000 my_drv!WorkerThreadMain+0x28c
[u:\my_drv\misc.c @ 186]
f7670ddc 80b00c92 f6d89750 81db7428 00000000 nt!PspSystemThreadStartup+0x2e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
CLASSPNP!ServiceTransferRequest+159
f95a9055 8b4010 mov eax,[eax+0x10]

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: CLASSPNP!ServiceTransferRequest+159

MODULE_NAME: CLASSPNP

IMAGE_NAME: CLASSPNP.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 3e800493

STACK_COMMAND: .cxr fffffffff7670564 ; kb

BUCKET_ID: 0x7E_CLASSPNP!ServiceTransferRequest+159

Followup: MachineOwner

7

Thanks. My driver needs to read data from the whole disk not just a
partition.
Besides, I think it would be the same if the device is change to Partition1,
2, or so on.

“Ralf Buschmann” wrote in message news:xxxxx@ntdev…
>
> ChuBun,
>
> you wrote on Tuesday, September 23, 2003, 22:43:21:
>
> C> I have a volume filter (based on toaster filter samples)
> C> that attaches on top of the parition object
> C> “\Device\Harddisk1\Partition0” by calling IoAttachDevice
>
> I’m not a kernel guy so I’m probably missing something, but remember
> that \Device\Harddisk1X\Partition0 refers to the physical disk, not the
> first partition on the disk. That is, Partition0 is always the RAW file
> system. Partitions are numbered one-based. See also WinObj.
>
> Just wanted to make sure you are attaching to what you think you are
> attaching to.
>
> Ralf.
> –
>
>
>

8

The full source to classpnp.sys for Server 2k3 is actually in the DDK.
What I suggest you do is compile a checked build and put it on your test
machine (make sure to disable WFP of course).

ChuBun wrote:

My test machine is a unpatched Windows 2003 check build version.
////
Windows Server 2003 Kernel Version 3790 MP (1 procs) Checked x86 compatible
Built by: 3790.srv03_rtm.030324-2048
////
I guess this could be a stack size problem and try to increase
pDevObj->StackSize of both drivers but that doesnt help.

Here is the entire print out from !analyze -v
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: f95a9055, The address that the exception occurred at
Arg3: f7670914, Exception Record Address
Arg4: f7670564, Context Record Address

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx”
referenced memory at “0x%08lx”. The memory could not be “%s”.

FAULTING_IP:
CLASSPNP!ServiceTransferRequest+159
f95a9055 8b4010 mov eax,[eax+0x10]

EXCEPTION_PARAMETER1: f7670914

CONTEXT: f7670564 – (.cxr fffffffff7670564)
eax=00000000 ebx=00000000 ecx=00000000 edx=00000002 esi=81e26e70
edi=823c6038
eip=f95a9055 esp=f76709dc ebp=f7670a7c iopl=0 nv up ei pl zr na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
CLASSPNP!ServiceTransferRequest+159:
f95a9055 8b4010 mov eax,[eax+0x10]
Resetting default context

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x7E

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from f95aa256 to f95a9055

STACK_TEXT:
f7670a7c f95aa256 823c6038 81e26e70 823c6038
CLASSPNP!ServiceTransferRequest+0x159
f7670acc 80a2675c 823c6038 81e26e70 81e26e70 CLASSPNP!ClassReadWrite+0x28e
f7670ae8 f983595f 823c6dc0 81e26e70 00000000 nt!IofCallDriver+0x62
f7670b00 80a2675c 823c6dc0 81e26e70 ffaabeb0 PartMgr!PmReadWrite+0xb5
f7670b1c f9badd65 00000001 ffaabf68 00000000 nt!IofCallDriver+0x62
f7670b34 80a2675c ffaabeb0 81e26e70 00000000
my_filter!my_filterPassDown+0x1e5 [u:\my_filter\my_filter.c @ 363]
f7670b50 f6d89f62 00000001 00000001 00000001 nt!IofCallDriver+0x62
f7670b7c f6d884b5 ffaabeb0 f7670ba4 00010000
my_drv!ReadPartitionDevice+0x1d2 [u:\my_drv\blockdev.c @ 114]
f7670bb4 f6d87af9 81db7428 00000000 f7670c38 my_drv!ReadSectors+0x195
[u:\my_drv\my_drv.c @ 2115]
f7670d7c f6d899dc 81db7370 81df0b80 00000003 my_drv!DoVolumeIO+0xdd9
[u:\my_drv\my_drv.c @ 1937]
f7670dac 80d391d0 81db7428 00000000 00000000 my_drv!WorkerThreadMain+0x28c
[u:\my_drv\misc.c @ 186]
f7670ddc 80b00c92 f6d89750 81db7428 00000000 nt!PspSystemThreadStartup+0x2e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
CLASSPNP!ServiceTransferRequest+159
f95a9055 8b4010 mov eax,[eax+0x10]

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: CLASSPNP!ServiceTransferRequest+159

MODULE_NAME: CLASSPNP

IMAGE_NAME: CLASSPNP.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 3e800493

STACK_COMMAND: .cxr fffffffff7670564 ; kb

BUCKET_ID: 0x7E_CLASSPNP!ServiceTransferRequest+159

Followup: MachineOwner

–
Nick Ryan (MVP for DDK)

9

Thanks. I’ll check it out.

“Nick Ryan” wrote in message news:xxxxx@ntdev…
>
> The full source to classpnp.sys for Server 2k3 is actually in the DDK.
> What I suggest you do is compile a checked build and put it on your test
> machine (make sure to disable WFP of course).
>
> ChuBun wrote:
>
> > My test machine is a unpatched Windows 2003 check build version.
> > ////
> > Windows Server 2003 Kernel Version 3790 MP (1 procs) Checked x86
compatible
> > Built by: 3790.srv03_rtm.030324-2048
> > ////
> > I guess this could be a stack size problem and try to increase
> > pDevObj->StackSize of both drivers but that doesnt help.
> >
> > Here is the entire print out from !analyze -v
> >
*************************************************************************
> >
> > *
> > *
> > * Bugcheck Analysis
> > *
> > *
> > *
> >
*************************************************************************
> >
> >
> > SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
> > This is a very common bugcheck. Usually the exception address pinpoints
> > the driver/function that caused the problem. Always note this address
> > as well as the link date of the driver/image that contains this address.
> > Arguments:
> > Arg1: c0000005, The exception code that was not handled
> > Arg2: f95a9055, The address that the exception occurred at
> > Arg3: f7670914, Exception Record Address
> > Arg4: f7670564, Context Record Address
> >
> > Debugging Details:
> > ------------------
> >
> > EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx”
> > referenced memory at “0x%08lx”. The memory could not be “%s”.
> >
> > FAULTING_IP:
> > CLASSPNP!ServiceTransferRequest+159
> > f95a9055 8b4010 mov eax,[eax+0x10]
> >
> > EXCEPTION_PARAMETER1: f7670914
> >
> > CONTEXT: f7670564 – (.cxr fffffffff7670564)
> > eax=00000000 ebx=00000000 ecx=00000000 edx=00000002 esi=81e26e70
> > edi=823c6038
> > eip=f95a9055 esp=f76709dc ebp=f7670a7c iopl=0 nv up ei pl zr na
po
> > nc
> > cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> > efl=00010246
> > CLASSPNP!ServiceTransferRequest+159:
> > f95a9055 8b4010 mov eax,[eax+0x10]
> > Resetting default context
> >
> > DEFAULT_BUCKET_ID: DRIVER_FAULT
> >
> > BUGCHECK_STR: 0x7E
> >
> > CURRENT_IRQL: 0
> >
> > LAST_CONTROL_TRANSFER: from f95aa256 to f95a9055
> >
> > STACK_TEXT:
> > f7670a7c f95aa256 823c6038 81e26e70 823c6038
> > CLASSPNP!ServiceTransferRequest+0x159
> > f7670acc 80a2675c 823c6038 81e26e70 81e26e70
CLASSPNP!ClassReadWrite+0x28e
> > f7670ae8 f983595f 823c6dc0 81e26e70 00000000 nt!IofCallDriver+0x62
> > f7670b00 80a2675c 823c6dc0 81e26e70 ffaabeb0 PartMgr!PmReadWrite+0xb5
> > f7670b1c f9badd65 00000001 ffaabf68 00000000 nt!IofCallDriver+0x62
> > f7670b34 80a2675c ffaabeb0 81e26e70 00000000
> > my_filter!my_filterPassDown+0x1e5 [u:\my_filter\my_filter.c @ 363]
> > f7670b50 f6d89f62 00000001 00000001 00000001 nt!IofCallDriver+0x62
> > f7670b7c f6d884b5 ffaabeb0 f7670ba4 00010000
> > my_drv!ReadPartitionDevice+0x1d2 [u:\my_drv\blockdev.c @ 114]
> > f7670bb4 f6d87af9 81db7428 00000000 f7670c38 my_drv!ReadSectors+0x195
> > [u:\my_drv\my_drv.c @ 2115]
> > f7670d7c f6d899dc 81db7370 81df0b80 00000003 my_drv!DoVolumeIO+0xdd9
> > [u:\my_drv\my_drv.c @ 1937]
> > f7670dac 80d391d0 81db7428 00000000 00000000
my_drv!WorkerThreadMain+0x28c
> > [u:\my_drv\misc.c @ 186]
> > f7670ddc 80b00c92 f6d89750 81db7428 00000000
nt!PspSystemThreadStartup+0x2e
> > 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
> >
> >
> > FOLLOWUP_IP:
> > CLASSPNP!ServiceTransferRequest+159
> > f95a9055 8b4010 mov eax,[eax+0x10]
> >
> > FOLLOWUP_NAME: MachineOwner
> >
> > SYMBOL_NAME: CLASSPNP!ServiceTransferRequest+159
> >
> > MODULE_NAME: CLASSPNP
> >
> > IMAGE_NAME: CLASSPNP.SYS
> >
> > DEBUG_FLR_IMAGE_TIMESTAMP: 3e800493
> >
> > STACK_COMMAND: .cxr fffffffff7670564 ; kb
> >
> > BUCKET_ID: 0x7E_CLASSPNP!ServiceTransferRequest+159
> >
> > Followup: MachineOwner
> > ---------
> >
> >
> >
> >
> >
>
> –
> Nick Ryan (MVP for DDK)
>
>
>