NT 4.0 - SRB_FUNCTION_CLAIM_DEVICE Handling?

I’m still maintaining a ScsiPort Filter driver fot NT 4.0
and encountered a bug with either my driver or a third party
driver that I need to resolve. I have identified the problem,
although based on the problem location I’m not sure if it’s
really my filter drivers problem or the 3rd party. Unfornately,
I haven’t found the definitive answer I would like before I
either change my code or contact the 3rd party. In this
configuration the device stack looks something like the below.

HBA Miniport/ScsiPort (3rd party) (group: SCSI Miniport)
HBA Miniport Filter (3rd party) (group: SCSI Miniport)
ScsiPort Filter (My driver) (group: SCSI Class)

In my DriverEntry() I use IoGetDeviceObjectPointer() against
the \Device\ScsiPort# which gives me the HBA Miniport Filter
address. I then use IoAttachDeviceToDeviceStack() which also
gives me the HBA Miniport Filter address.

Then when intercepting the SRB_FUNCTION_CLAIM_DEVICE and passing
it down to my Target Device Object (ie. The HBA Miniport Filter)
I get the HBA Miniport/ScsiPort PDO Object instead.

So I guess the question is this correct behavior on the HBA
Miniport Filter’s part or should it be returning it’s own address
again instead of the HBA Miniport/ScsiPort PDO.

  1. There is no “miniport filter”. All SCSI filters are filtering SCSIPORT.

  2. Claim device is a special case:

// SRB_FUNCTION_CLAIM_DEVICE will have a completion routine to
// patch the port device object in Srb->DataBuffer
if( IoGetCurrentIrpStackLocation(Irp)->Parameters.Scsi.Srb->Function ==
SRB_FUNCTION_CLAIM_DEVICE )
{
IoCopyCurrentIrpStackLocationToNext(Irp);
IoSetCompletionRoutine(Irp, ScsiToolClaimCompletion, NULL, TRUE, TRUE,
TRUE);
return IoCallDriver(Device->LowerDevice, Irp);
}

// Completion routine for SRB_FUNCTION_CLAIM_DEVICE
static NTSTATUS ScsiToolClaimCompletion(PDEVICE_OBJECT DeviceObject,
PIRP Irp, PVOID Context)
{
// Patch to our device object
IoGetCurrentIrpStackLocation(Irp)->Parameters.Scsi.Srb->DataBuffer =
DeviceObject;
// Do this since we return STATUS_SUCCESS
if( Irp->PendingReturned )
IoMarkIrpPending(Irp);
// Continue IRP unwind
return STATUS_SUCCESS;
UNREFERENCED_PARAMETER(Context);
}

I suspect that the filter below you is not properly patching the device
object in the Srb->DataBuffer. But please make sure that YOU DO THIS in your
filter driver. Otherwise, all sorts of strange stuff can happen.

  1. I would recommend changing the Group to “Port”

I hope this helps,

Jamey Kirby, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
On Behalf Of David
Sent: Friday, August 15, 2003 1:31 PM
To: Windows System Software Developers Interest List
Subject: [ntdev] NT 4.0 - SRB_FUNCTION_CLAIM_DEVICE Handling?

I’m still maintaining a ScsiPort Filter driver fot NT 4.0
and encountered a bug with either my driver or a third party
driver that I need to resolve. I have identified the problem,
although based on the problem location I’m not sure if it’s
really my filter drivers problem or the 3rd party. Unfornately,
I haven’t found the definitive answer I would like before I
either change my code or contact the 3rd party. In this
configuration the device stack looks something like the below.

HBA Miniport/ScsiPort (3rd party) (group: SCSI Miniport)
HBA Miniport Filter (3rd party) (group: SCSI Miniport)
ScsiPort Filter (My driver) (group: SCSI Class)

In my DriverEntry() I use IoGetDeviceObjectPointer() against
the \Device\ScsiPort# which gives me the HBA Miniport Filter
address. I then use IoAttachDeviceToDeviceStack() which also
gives me the HBA Miniport Filter address.

Then when intercepting the SRB_FUNCTION_CLAIM_DEVICE and passing
it down to my Target Device Object (ie. The HBA Miniport Filter)
I get the HBA Miniport/ScsiPort PDO Object instead.

So I guess the question is this correct behavior on the HBA
Miniport Filter’s part or should it be returning it’s own address
again instead of the HBA Miniport/ScsiPort PDO.


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

You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com