VolumeFilter - Loading failed

NTDEV
1

Hi everybody,

My volume filter driver failed during loading…I have developed a pass through volume filter driver. I am just passing the I/O requests received by FileSystem to the lower level driver.

NTSTATUS
VolumeFilterDispatchPassThrough (IN PDEVICE_OBJECT pDeviceObject, IN PIRP pIrp) {

IoSkipCurrentIrpStackLocation (pIrp);
return IoCallDriver (((PDEVICE_EXTENSION)pDeviceObject->DeviceExtension)->pLowerDeviceObject, pIrp);
}

Here is the debugger output - Could you please help me out? Thanks!

kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

FAT_FILE_SYSTEM (23)
If you see FatExceptionFilter on the stack then the 2nd and 3rd
parameters are the exception record and context record. Do a .cxr
on the 3rd parameter and then kb to obtain a more informative stack
trace.
Arguments:
Arg1: 000e0100
Arg2: f9f46530
Arg3: f9f46230
Arg4: f9a9baf3

Debugging Details:

EXCEPTION_RECORD: f9f46530 – (.exr fffffffff9f46530)
ExceptionAddress: f9a9baf3 (CLASSPNP!ServiceTransferRequest+0x00000021)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 00000018
Attempt to read from address 00000018

CONTEXT: f9f46230 – (.cxr fffffffff9f46230)
eax=8133b354 ebx=00000200 ecx=00000000 edx=813a4008 esi=8133b230 edi=8138a0e8
eip=f9a9baf3 esp=f9f465f8 ebp=f9f46618 iopl=0 nv up ei ng nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000282
CLASSPNP!ServiceTransferRequest+0x21:
f9a9baf3 8b7918 mov edi,dword ptr [ecx+18h] ds:0023:00000018=???
Resetting default scope

PROCESS_NAME: autochk.exe

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

READ_ADDRESS: 00000018

BUGCHECK_STR: 0x23

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

LAST_CONTROL_TRANSFER: from f9a9c0b3 to f9a9baf3

STACK_TEXT:
f9f46618 f9a9c0b3 8138a030 8133b230 8133b230 CLASSPNP!ServiceTransferRequest+0x21
f9f4663c 804ec04f 8138a030 00000000 813d4dd0 CLASSPNP!ClassReadWrite+0xfd
f9f4664c f9cd3537 81388ee8 8138b448 f9f46688 nt!IopfCallDriver+0x31
f9f4665c 804ec04f 8138b448 8133b230 8133b378 PartMgr!PmReadWrite+0x2d
f9f4666c f99e01c6 8133b230 813d5030 8051022d nt!IopfCallDriver+0x31
f9f46688 804ec04f 81388e30 8133b230 813d4cd8 ftdisk!FtDiskReadWrite+0x194
f9f46698 f9a7b4e0 813a2a20 813a2a20 f9f466c0 nt!IopfCallDriver+0x31
f9f466a8 804ec04f 813a2a20 8133b230 813a2cd0 VolSnap!VolSnapRead+0x24
f9f466b8 fa013643 f9f46704 804ec04f 813a2850 nt!IopfCallDriver+0x31
f9f466c0 804ec04f 813a2850 8133b230 813a0460 volfltr!VolumeFilterDispatchPassThrough+0x33 [d:\aniket\wdd\volumefilter\volfltr.c @ 141]
f9f466d0 f998b732 813a0460 00000200 813d2000 nt!IopfCallDriver+0x31
f9f46704 f998c407 8139dbb8 813a0460 813d2000 Fastfat!FatPerformVerifyDiskRead+0x6f
f9f46874 f99815ff 8139dbb8 813d3008 813a0720 Fastfat!FatVerifyVolume+0x1ca
f9f4688c f9978ef5 8139dbb8 813d3008 813a0720 Fastfat!FatCommonFileSystemControl+0x34
f9f468d8 804ec04f 813a0368 813d3008 813a07d8 Fastfat!FatFsdFileSystemControl+0x85
f9f468e8 f9998b73 81386a30 00000000 f9f4693c nt!IopfCallDriver+0x31
f9f468f8 804ec04f 813a07d8 813d3008 81388e30 sr!SrFsControl+0x11f
f9f46908 805f56fa 81379a98 813a0460 81399c60 nt!IopfCallDriver+0x31
f9f4693c f998e6f4 81388e30 00000000 813d38b0 nt!IoVerifyVolume+0xc1
f9f46980 f9983e6b 81399c60 813d38b0 81388e30 Fastfat!FatPerformVerify+0x81
f9f469d0 f997e6dd 81399c60 813d38b0 80000016 Fastfat!FatProcessException+0x190
f9f46a18 804ec04f 813a0368 813d38b0 00000001 Fastfat!FatFsdCreate+0x80
f9f46a28 f999851a 813d38c0 81386a30 81379a98 nt!IopfCallDriver+0x31
f9f46a74 804ec04f 813a07d8 81379a98 813d38b0 sr!SrCreate+0x12a
f9f46a84 80574663 81388e18 813145b4 f9f46c2c nt!IopfCallDriver+0x31
f9f46b68 8057069c 81388e30 00000000 81314510 nt!IopParseDevice+0xa17
f9f46bec 80572d6b 00000000 f9f46c2c 00000040 nt!ObpLookupObjectName+0x56a
f9f46c40 80574a10 00000000 00000000 00000001 nt!ObOpenObjectByName+0xe9
f9f46cbc 80574ac1 0006fcf8 0012019f 0006fcb4 nt!IopCreateFile+0x407
f9f46d04 8057646e 0006fcf8 0012019f 0006fcb4 nt!IoCreateFile+0x36
f9f46d44 804d4e91 0006fcf8 0012019f 0006fcb4 nt!NtOpenFile+0x25
f9f46d44 7ffe0304 0006fcf8 0012019f 0006fcb4 nt!KiSystemService+0xc4
0006fc88 77f7eaff 0101131e 0006fcf8 0012019f SharedUserData!SystemCallStub+0x4
WARNING: Stack unwind information not available. Following frames may be wrong.
0006fce4 0100c83e 0006fdac 000b5620 00000702 ntdll!ZwOpenFile+0xc
0006fdfc 0100d188 0006ff48 0006ff60 00000080 autochk+0xc83e
0006fe00 0006ff48 0006ff60 00000080 00000000 autochk+0xd188
0006fe04 0006ff60 00000080 00000000 00073000 0x6ff48
0006ffa8 0100d6f5 00000002 00072358 00072364 0x6ff60
0006ffac 00000000 00072358 00072364 00000000 autochk+0xd6f5

FOLLOWUP_IP:
CLASSPNP!ServiceTransferRequest+21
f9a9baf3 8b7918 mov edi,dword ptr [ecx+18h]

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: CLASSPNP

IMAGE_NAME: CLASSPNP.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 3b7dc5af

SYMBOL_NAME: CLASSPNP!ServiceTransferRequest+21

STACK_COMMAND: .cxr 0xfffffffff9f46230 ; kb

FAILURE_BUCKET_ID: 0x23_CLASSPNP!ServiceTransferRequest+21

BUCKET_ID: 0x23_CLASSPNP!ServiceTransferRequest+21

Followup: MachineOwner

kd> lmvm CLASSPNP
start end module name
f9a9b000 f9aa5f80 CLASSPNP (pdb symbols) D:\Aniket\Symbols\xp_wosp_sombols\classpnp.pdb\1D7149EAFE6E4CB2BC09DC382A6CBD472\classpnp.pdb
Loaded symbol image file: CLASSPNP.SYS
Image path: \WINDOWS\System32\DRIVERS\CLASSPNP.SYS
Image name: CLASSPNP.SYS
Timestamp: Sat Aug 18 07:02:31 2001 (3B7DC5AF)
CheckSum: 00014741
ImageSize: 0000AF80
Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0

  • Jhon
2

when you create DeviceObject to attache the volum driver, you should set
deviceObject->Flags to DO_DIRECT_IO.
danny

3

Danny, Thanks for reply!
Suggested changes worked just fine. But I am wondering if my driver was using buffered I/O previously then how things worked fine in driver hierarchy till CLASSPNP rather why it didn’t fail when the request passed through VolSnap, ftdisk, PartMgr up to CLASSPNP. Thanks!

Jhon

danny wrote:

when you create DeviceObject to attache the volum driver, you should
set deviceObject->Flags to DO_DIRECT_IO.
danny

jhon wrote:

Hi everybody,

My volume filter driver failed during loading…I have developed a pass through volume filter driver. I am just passing the I/O requests received by FileSystem to the lower level driver.

NTSTATUS
VolumeFilterDispatchPassThrough (IN PDEVICE_OBJECT pDeviceObject, IN PIRP pIrp) {

IoSkipCurrentIrpStackLocation (pIrp);
return IoCallDriver (((PDEVICE_EXTENSION)pDeviceObject->DeviceExtension)->pLowerDeviceObject, pIrp);
}

Here is the debugger output - Could you please help me out? Thanks!

kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

FAT_FILE_SYSTEM (23)
If you see FatExceptionFilter on the stack then the 2nd and 3rd
parameters are the exception record and context record. Do a .cxr
on the 3rd parameter and then kb to obtain a more informative stack
trace.
Arguments:
Arg1: 000e0100
Arg2: f9f46530
Arg3: f9f46230
Arg4: f9a9baf3

Debugging Details:

EXCEPTION_RECORD: f9f46530 – (.exr fffffffff9f46530)
ExceptionAddress: f9a9baf3 (CLASSPNP!ServiceTransferRequest+0x00000021)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 00000018
Attempt to read from address 00000018

CONTEXT: f9f46230 – (.cxr fffffffff9f46230)
eax=8133b354 ebx=00000200 ecx=00000000 edx=813a4008 esi=8133b230 edi=8138a0e8
eip=f9a9baf3 esp=f9f465f8 ebp=f9f46618 iopl=0 nv up ei ng nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000282
CLASSPNP!ServiceTransferRequest+0x21:
f9a9baf3 8b7918 mov edi,dword ptr [ecx+18h] ds:0023:00000018=???
Resetting default scope

PROCESS_NAME: autochk.exe

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

READ_ADDRESS: 00000018

BUGCHECK_STR: 0x23

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

LAST_CONTROL_TRANSFER: from f9a9c0b3 to f9a9baf3

STACK_TEXT:
f9f46618 f9a9c0b3 8138a030 8133b230 8133b230 CLASSPNP!ServiceTransferRequest+0x21
f9f4663c 804ec04f 8138a030 00000000 813d4dd0 CLASSPNP!ClassReadWrite+0xfd
f9f4664c f9cd3537 81388ee8 8138b448 f9f46688 nt!IopfCallDriver+0x31
f9f4665c 804ec04f 8138b448 8133b230 8133b378 PartMgr!PmReadWrite+0x2d
f9f4666c f99e01c6 8133b230 813d5030 8051022d nt!IopfCallDriver+0x31
f9f46688 804ec04f 81388e30 8133b230 813d4cd8 ftdisk!FtDiskReadWrite+0x194
f9f46698 f9a7b4e0 813a2a20 813a2a20 f9f466c0 nt!IopfCallDriver+0x31
f9f466a8 804ec04f 813a2a20 8133b230 813a2cd0 VolSnap!VolSnapRead+0x24
f9f466b8 fa013643 f9f46704 804ec04f 813a2850 nt!IopfCallDriver+0x31
f9f466c0 804ec04f 813a2850 8133b230 813a0460 volfltr!VolumeFilterDispatchPassThrough+0x33 [d:\aniket\wdd\volumefilter\volfltr.c @ 141]
f9f466d0 f998b732 813a0460 00000200 813d2000 nt!IopfCallDriver+0x31
f9f46704 f998c407 8139dbb8 813a0460 813d2000 Fastfat!FatPerformVerifyDiskRead+0x6f
f9f46874 f99815ff 8139dbb8 813d3008 813a0720 Fastfat!FatVerifyVolume+0x1ca
f9f4688c f9978ef5 8139dbb8 813d3008 813a0720 Fastfat!FatCommonFileSystemControl+0x34
f9f468d8 804ec04f 813a0368 813d3008 813a07d8 Fastfat!FatFsdFileSystemControl+0x85
f9f468e8 f9998b73 81386a30 00000000 f9f4693c nt!IopfCallDriver+0x31
f9f468f8 804ec04f 813a07d8 813d3008 81388e30 sr!SrFsControl+0x11f
f9f46908 805f56fa 81379a98 813a0460 81399c60 nt!IopfCallDriver+0x31
f9f4693c f998e6f4 81388e30 00000000 813d38b0 nt!IoVerifyVolume+0xc1
f9f46980 f9983e6b 81399c60 813d38b0 81388e30 Fastfat!FatPerformVerify+0x81
f9f469d0 f997e6dd 81399c60 813d38b0 80000016 Fastfat!FatProcessException+0x190
f9f46a18 804ec04f 813a0368 813d38b0 00000001 Fastfat!FatFsdCreate+0x80
f9f46a28 f999851a 813d38c0 81386a30 81379a98 nt!IopfCallDriver+0x31
f9f46a74 804ec04f 813a07d8 81379a98 813d38b0 sr!SrCreate+0x12a
f9f46a84 80574663 81388e18 813145b4 f9f46c2c nt!IopfCallDriver+0x31
f9f46b68 8057069c 81388e30 00000000 81314510 nt!IopParseDevice+0xa17
f9f46bec 80572d6b 00000000 f9f46c2c 00000040 nt!ObpLookupObjectName+0x56a
f9f46c40 80574a10 00000000 00000000 00000001 nt!ObOpenObjectByName+0xe9
f9f46cbc 80574ac1 0006fcf8 0012019f 0006fcb4 nt!IopCreateFile+0x407
f9f46d04 8057646e 0006fcf8 0012019f 0006fcb4 nt!IoCreateFile+0x36
f9f46d44 804d4e91 0006fcf8 0012019f 0006fcb4 nt!NtOpenFile+0x25
f9f46d44 7ffe0304 0006fcf8 0012019f 0006fcb4 nt!KiSystemService+0xc4
0006fc88 77f7eaff 0101131e 0006fcf8 0012019f SharedUserData!SystemCallStub+0x4
WARNING: Stack unwind information not available. Following frames may be wrong.
0006fce4 0100c83e 0006fdac 000b5620 00000702 ntdll!ZwOpenFile+0xc
0006fdfc 0100d188 0006ff48 0006ff60 00000080 autochk+0xc83e
0006fe00 0006ff48 0006ff60 00000080 00000000 autochk+0xd188
0006fe04 0006ff60 00000080 00000000 00073000 0x6ff48
0006ffa8 0100d6f5 00000002 00072358 00072364 0x6ff60
0006ffac 00000000 00072358 00072364 00000000 autochk+0xd6f5

FOLLOWUP_IP:
CLASSPNP!ServiceTransferRequest+21
f9a9baf3 8b7918 mov edi,dword ptr [ecx+18h]

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: CLASSPNP

IMAGE_NAME: CLASSPNP.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 3b7dc5af

SYMBOL_NAME: CLASSPNP!ServiceTransferRequest+21

STACK_COMMAND: .cxr 0xfffffffff9f46230 ; kb

FAILURE_BUCKET_ID: 0x23_CLASSPNP!ServiceTransferRequest+21

BUCKET_ID: 0x23_CLASSPNP!ServiceTransferRequest+21

Followup: MachineOwner

kd> lmvm CLASSPNP
start end module name
f9a9b000 f9aa5f80 CLASSPNP (pdb symbols) D:\Aniket\Symbols\xp_wosp_sombols\classpnp.pdb\1D7149EAFE6E4CB2BC09DC382A6CBD472\classpnp.pdb
Loaded symbol image file: CLASSPNP.SYS
Image path: \WINDOWS\System32\DRIVERS\CLASSPNP.SYS
Image name: CLASSPNP.SYS
Timestamp: Sat Aug 18 07:02:31 2001 (3B7DC5AF)
CheckSum: 00014741
ImageSize: 0000AF80
Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0

  • Jhon

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

4

you can see fastfat source code. in FatPerformVerifyDiskRead function, the
IoBuildSynchronousFsdRequest is called, and the device object is your filter
device object,it allocates buffer or locks the page of user’s buffer
depending on deviceobject->flag.if your device object->flag is not set to
DO_DIRECT_IO,the user buffer is not locked into memory,and irp->MdlAddress
is null. you can also see source code of CLASSPNP!ServiceTransferRequest in
ddk. it gets the buffrer from MmGetMdlVirtualAddress(Irp->MdlAddress,so the
os will crash if your filter device object->flag is not set to
DO_DIRECT_IO.(if you disassemble and compare it to the source code ,you will
find the crash instruction (mov edi,dword ptr [ecx+18h])is reference the
memory though irp->MdlAddress, but it’s null, ecx is 0)

But I am wondering if my driver was using buffered I/O previously then how
things worked fine in driver hierarchy till CLASSPNP rather why it didn’t
fail when the request passed through VolSnap, ftdisk, PartMgr up to
CLASSPNP.

because other drivers don’t actually touch irp->MdlAddress, only pass
irp to lower device.
danny

5

Hi Danny,

Thanks for the clarification!

danny wrote:

you can see fastfat source code. in FatPerformVerifyDiskRead function, the
IoBuildSynchronousFsdRequest is called, and the device object is your
filter device object,it allocates buffer or locks the page of user’s
buffer depending on deviceobject->flag.if your device object->flag
is not set to DO_DIRECT_IO,the user buffer is not locked into memory,and
irp->MdlAddress is null. you can also see source code of
CLASSPNP!ServiceTransferRequest in ddk. it gets the buffrer from
MmGetMdlVirtualAddress(Irp->MdlAddress,so the os will crash if your
filter device object->flag is not set to DO_DIRECT_IO.(if you
disassemble and compare it to the source code ,you will find the crash
instruction (mov edi,dword ptr [ecx+18h])is reference the memory
though irp->MdlAddress, but it’s null, ecx is 0)

>But I am wondering if my driver was using buffered I/O previously then
how things worked fine in driver hierarchy till CLASSPNP rather why it
didn’t fail when the request passed through VolSnap, ftdisk, PartMgr up
to CLASSPNP.

because other drivers don’t actually touch irp->MdlAddress, only pass
irp to lower device.
danny