Function Call Not Returning

NTFSD
1

All:

I have created a file system driver that maps unused sectors of a USB mass
storage to a second drive. (I did this so that the driver may ultimately
support encryption of the extra sectors.) My driver “piggy-backs” off of the
existing driver (USBSTOR.SYS) by sending IOCTL_SCSI_PASS_THROUGH along the
lines of the following pseudo-code:

// #
// # Initialization procedure
// #

// Get USB driver name
GetDeviceObjectPointer(ucDeviceName, FILE_ALL_ACCESS,
&pdx->pTargetFileObject, &pdx->pTargetDeviceObject);

// Register interface
IoRegisterDeviceInterface(pdx->UnderlyingPDO,
(LPGUID)&MOUNTDEV_MOUNTED_DEVICE_GUID, NULL, &pdx->InterfaceString);

// Enable interface
IoSetDeviceInterfaceState(pdx->InterfaceString, TRUE);

// #
// # IRP_MJ_READ Handler
// #
SCSI_PASS_THROUGH* pspt = NULL;
ULONG ulSize;

// Allocate
ulSize = sizeof(SCSI_PASS_THORUGH) + ulReadBufferSize;
pspt = ExAllocatePool(PagedPool, ulSize);

// Build request
pIoctlIrp = IoBuildDeviceControlRequest(IOCTL_SCSI_PASS_THROUGH,
pdx->pTargetDeviceObject, pspt, ulSize, pspt, ulSize, FALSE, &event,
&iostatus);

// Call driver
IoCallDriver(pdx->pTargetDeviceObject, pIoctlIrp)

I can test my IRP_MJ_READ handler using a user specified IOCTL and confirm
that my IRP_MJ_READ handler is reading and returning the proper sectors, but
when I let my driver respond to an actual IRP_MJ_READ request from Windows,
IoCallDriver never returns. (Even though TimeOutValue is 0x02.)

I was wondering if anyone could explain any differences between the flow of
IRP_MJ_DEVICE_CONTROL event and an IRP_MJ_READ event so that I might
understand why the IoCallDriver call doesn’t return (I’m guessing it
blocks). Also, does anyone have any techniques for dealing with driver level
functions that do not return.

Thanks for any help that can be provided.

Thomas McCormick

2

You can’t use IoBuildDeviceControlRequest on the Read path. The function
can’t be used above PASSIVE_LEVEL or in context of PagingIO. You need to use
IoAsynchronousFsdRequest or IoAllocateIrp to build the IRP.
It may be the source your problem but not necessarily is - you need to
break in debugger when this occur and find out what the thread is waiting
for.

Alexei.

“McCormick, Tom” wrote in message
news:xxxxx@ntfsd…
> All:
>
> I have created a file system driver that maps unused sectors of a USB mass
> storage to a second drive. (I did this so that the driver may ultimately
> support encryption of the extra sectors.) My driver “piggy-backs” off of
the
> existing driver (USBSTOR.SYS) by sending IOCTL_SCSI_PASS_THROUGH along the
> lines of the following pseudo-code:
>
> // #
> // # Initialization procedure
> // #
>
> // Get USB driver name
> GetDeviceObjectPointer(ucDeviceName, FILE_ALL_ACCESS,
> &pdx->pTargetFileObject, &pdx->pTargetDeviceObject);
>
> // Register interface
> IoRegisterDeviceInterface(pdx->UnderlyingPDO,
> (LPGUID)&MOUNTDEV_MOUNTED_DEVICE_GUID, NULL, &pdx->InterfaceString);
>
> // Enable interface
> IoSetDeviceInterfaceState(pdx->InterfaceString, TRUE);
>
>
> // #
> // # IRP_MJ_READ Handler
> // #
> SCSI_PASS_THROUGH* pspt = NULL;
> ULONG ulSize;
>
> // Allocate
> ulSize = sizeof(SCSI_PASS_THORUGH) + ulReadBufferSize;
> pspt = ExAllocatePool(PagedPool, ulSize);
>
> // Build request
> pIoctlIrp = IoBuildDeviceControlRequest(IOCTL_SCSI_PASS_THROUGH,
> pdx->pTargetDeviceObject, pspt, ulSize, pspt, ulSize, FALSE, &event,
> &iostatus);
>
> // Call driver
> IoCallDriver(pdx->pTargetDeviceObject, pIoctlIrp)
>
>
> I can test my IRP_MJ_READ handler using a user specified IOCTL and confirm
> that my IRP_MJ_READ handler is reading and returning the proper sectors,
but
> when I let my driver respond to an actual IRP_MJ_READ request from
Windows,
> IoCallDriver never returns. (Even though TimeOutValue is 0x02.)
>
> I was wondering if anyone could explain any differences between the flow
of
> IRP_MJ_DEVICE_CONTROL event and an IRP_MJ_READ event so that I might
> understand why the IoCallDriver call doesn’t return (I’m guessing it
> blocks). Also, does anyone have any techniques for dealing with driver
level
> functions that do not return.
>
> Thanks for any help that can be provided.
>
> Thomas McCormick
>
>

3

> It may be the source your problem but not necessarily is - you need to

break in debugger when this occur and find out what the thread is waiting
for.

Or, better way, crash the OS manually,
generate the crash dump and analyze it in WinDbg.

To crash windows manually, write this into the registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters]
“CrashOnCtrlScroll”=dword:00000001

Reboot, then press Right Ctrl + ScrollLock twice and
the system will manually crash. The crash dump generated
may be used for finding the cause of deadlock.

L.