From: COX,DAVID (HP-Roseville,ex1) [david_cox2@hp.com]
Sent: Wednesday, December 13, 2000 12:01 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Receiving IRPs in SCSI port filter driver on NT4

> I have a problem receiving IRPs in my SCSI port filter driver on NT4.
> 
> I took DDK's DiskPerf as an example and wrote simple filter 
> driver which attaches its own device objects to ScsiPort%d 
> device objects (OSR DevceTree shows device objects of my 
> filter attached to ScsiPort%d device objects). The filter monitors 
> IRP_MJ_DEVICE_CONTROL and IRP_MJ_INTERNAL_DEVICE_CONTROL. It 
> shows IRPs with SRBs perfectly well when any application 
> accesses SCSI devices through ASPI layer. At the same time my 
> filter does not receive IRPs (IRP_MJ_DEVICE_CONTROL and 
> IRP_MJ_INTERNAL_DEVICE_CONTROL) when an application (e.g. 
> Windows Explorer) reads files from a media via  file system 
> (e.g. CDFS in my case).
> 
> I thought the problem was in drivers' load order, but it 
> seems to me ok now. I load my filter during boot time (Start 
> = 0x00) between "SCSI miniport" group and "port" group. The 
> problem still exists.
> 
> Any ideas why is it so?

Look at ScsiClassClaimDevice() in ddk\src\storage\class\class\class.c...

When a class driver claims a LUN on NT4, the port driver returns a
DEVICE_OBJECT which the class driver then uses for all subsequent SCSI
IRPs.  You've got to filter the claim request and substitute your filter
device object for the one returned by the port driver; otherwise, the
class driver will send its IRPs directly to the port driver's device
object, bypassing your filter.  If you wanted to be entirely correct,
you should probably stash the DEVICE_OBJECT the port driver returned,
and make sure when you pass SRBs down for that particular LUN, you are
using the stashed DO rather than the one you attacked to.  In reality
the DO returned by a claim will normally be the same DO you attached to.
Only if there is some exotic port driver or filter below your filter
might you see a different DO.

-----------------------------------------------------------------------
Dave Cox
Hewlett-Packard Co.
NSSO/SANS/SMSO (Santa Barbara)
https://ecardfile.com/id/Dave+Cox

---
You are currently subscribed to ntdev as: GlennEverhart@FirstUSA.com
To unsubscribe send a blank email to leave-ntdev-247T@lists.osr.com