SCSI Processor Device Driver

We have a legacy driver for NT to communicate with a piece of custom
hardware. This hardware doesn't seem to fall into any of Microsoft's
existing classes (at least I don't think so, but you've probably heard that
line before).

It attaches via a SCSI-2 interface, and meets the minimum requirements under
SCSI-2 as a 'Processor' device. It allows the computer to interface with a
large amount of individual I/O points used in a full-scope control room
simulator (app. 1500 analog outputs, 7500 digital outputs, 4500 digital
inputs, and 300 analog inputs, all scanned at 20 Hz).

Our legacy driver, (originally written for NT 3.51) has served us pretty
well through the various OS upgrades. I developed a new '.inf' file a few
years back to provide client-side installation on Windows 2000. The same
.inf and .sys files work under Windows XP (pro & home). But they do *not*
seem to work on Windows 2003 Standard edition. Why not?? The OS complains
about error starting the driver yet it works under XP and 2000.

Anyway, I'm trying to write a new driver using the latest DDK and WDM models
(I wrote the original as well). Or should I wait for WDF? But I can't find
nearly the amount of information on SCSI device drivers that I had back in
the NT days. Most new things are USB & 1394 it seems. I do have the SCSI
specs down pat and work quite closely with the device firmware programmer,
so I have that going for me (as well as a SCSI bus analyzer etc...) But
searching for a good text on the subject of SCSI drivers under WDM hasn't
been successful (have "Programming the Microsoft WIndows Driver Model" and
"The Windows 2000 Device Driver Book", but they barely acknowledge that SCSI
exists).

I've started by using a storage/class sample from the DDK. But since 'SCSI
Processor' devices support a lot fewer features than either CDROM, disk
drives, or tape, there's a lot of code that needs to be thrown away. And
cutting out code without breaking things is a bit tricky. Anyone have a
better starting point for a simple SCSI device that still fits the WDM
model?

Also, since this device is external, and has it's own power, can I just
reply success to all the power management requests (the device doesn't have
any sort of power-down mode)?

Sorry for the long ramble, but this is a small outfit and I feel lost in the
wilderness a bit. I get to do the low-level drivers because I'm the one
that works with the hardware folks and understand bit-bashing.

Mike Fochtman

heinz
Wed Sep 07 22:10:24 CDT 2005

The first thing I would do is run the chkinf tool (found in the DDK) to
check for problems with your inf file. The next thing to do is look at
setupapi.log to learn more about what failed. Next, run verifier,
flipping on all its most stringest checks except simulating low
resources. Finally, look at how you respond to each IRP, particularly
the last one that arrives.

I am assuming you have a processor class driver. As far as pnp & power
irps make sure you handle ones you don't know correctly: you DO NOT
touch the status of the IRP and you DO NOT complete it; you pass it
down without touching anything. And you must use PoStartNextPowerIrp &
PoCallDriver for each power IRP. Hope that helps.

Mark
Wed Sep 07 22:29:48 CDT 2005

Mike Fochtman wrote:
> We have a legacy driver for NT to communicate with a piece of custom
> hardware. This hardware doesn't seem to fall into any of Microsoft's
> existing classes (at least I don't think so, but you've probably heard that
> line before).
>
> It attaches via a SCSI-2 interface, and meets the minimum requirements under
> SCSI-2 as a 'Processor' device. It allows the computer to interface with a
> large amount of individual I/O points used in a full-scope control room
> simulator (app. 1500 analog outputs, 7500 digital outputs, 4500 digital
> inputs, and 300 analog inputs, all scanned at 20 Hz).
>
> Our legacy driver, (originally written for NT 3.51) has served us pretty
> well through the various OS upgrades. I developed a new '.inf' file a few
> years back to provide client-side installation on Windows 2000. The same
> ..inf and .sys files work under Windows XP (pro & home). But they do *not*
> seem to work on Windows 2003 Standard edition. Why not?? The OS complains
> about error starting the driver yet it works under XP and 2000.
>
> Anyway, I'm trying to write a new driver using the latest DDK and WDM models
> (I wrote the original as well). Or should I wait for WDF? But I can't find
> nearly the amount of information on SCSI device drivers that I had back in
> the NT days. Most new things are USB & 1394 it seems. I do have the SCSI
> specs down pat and work quite closely with the device firmware programmer,
> so I have that going for me (as well as a SCSI bus analyzer etc...) But
> searching for a good text on the subject of SCSI drivers under WDM hasn't
> been successful (have "Programming the Microsoft WIndows Driver Model" and
> "The Windows 2000 Device Driver Book", but they barely acknowledge that SCSI
> exists).
>
> I've started by using a storage/class sample from the DDK. But since 'SCSI
> Processor' devices support a lot fewer features than either CDROM, disk
> drives, or tape, there's a lot of code that needs to be thrown away. And
> cutting out code without breaking things is a bit tricky. Anyone have a
> better starting point for a simple SCSI device that still fits the WDM
> model?
>
> Also, since this device is external, and has it's own power, can I just
> reply success to all the power management requests (the device doesn't have
> any sort of power-down mode)?
>
> Sorry for the long ramble, but this is a small outfit and I feel lost in the
> wilderness a bit. I get to do the low-level drivers because I'm the one
> that works with the hardware folks and understand bit-bashing.
>
> Mike Fochtman
>
>
>
You could implement a class driver using the classpnp library in the
storage source tree in the ddk. Disk/Cdrom/Tape sample clients are
provided. Disk is too complex as it is a bus driver for disk partition
PDOs in addition to being a function driver for the scsi disk target.
I'd start with CDROM and just rip out all the CDROM hardware idiocy
code. You should be able to rather readily get it down to a simple
driver that queries your scsi target, then add in the read/write or
ioctl or whatever it is that you do to communicate with your hardware.
The advantage of classpnp is that it handles all of the basic PnP code
for you.

Too bad classpnp is really rather undocumented, huh? But you do have
three functional source examples, so that is something.

I don't think WDF currently has anything to offer in the scsi class
driver space.

I think it is also possible to pretty much avoid a driver entirely and
communicate with the PDO using scsi passthrough from user mode.
--

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

Mike
Thu Sep 08 06:14:51 CDT 2005


"Mark Roddy" <markr@hollistech.com> wrote in message
news:eRPeSWCtFHA.3328@TK2MSFTNGP11.phx.gbl...
> Mike Fochtman wrote:
<snip>>
>>
>>
> You could implement a class driver using the classpnp library in the
> storage source tree in the ddk. Disk/Cdrom/Tape sample clients are
> provided. Disk is too complex as it is a bus driver for disk partition
> PDOs in addition to being a function driver for the scsi disk target. I'd
> start with CDROM and just rip out all the CDROM hardware idiocy code. You
> should be able to rather readily get it down to a simple driver that
> queries your scsi target, then add in the read/write or ioctl or whatever
> it is that you do to communicate with your hardware. The advantage of
> classpnp is that it handles all of the basic PnP code for you.
>
> Too bad classpnp is really rather undocumented, huh? But you do have three
> functional source examples, so that is something.
>
> I don't think WDF currently has anything to offer in the scsi class driver
> space.
>
> I think it is also possible to pretty much avoid a driver entirely and
> communicate with the PDO using scsi passthrough from user mode.
> --

Thanks for the reply Mark...

Yes, I had started with the storage/class/Cdrom sample. But for things like
building the SRB and CDB, it often passes back into classpnp library. And
as you say, that is not too well documented.

I'm still puzzled as to why the legacy driver, that works in 2K and XP fails
in 2003. Did something change there that no longer supports some legacy??
Guess I'll have to fire up windbg to find out. But recompiling the old
driver now to get a debug-build is a bit tricky, would have to get an NT
3.51 DDK (and that doesn't seem very easy).

I had considered just going direct with SCSI_PASS_THROUGH and
SCSI_PASS_THROUGH_DIRECT, but it seems those specific ioctl() codes and the
struct's needed (SRB and CDB) are only defined in DDK header files. So I'd
have to somehow include those in my deliverables since clients won't have
them by default??

If I could somehow 'wrap' all those calls in a DLL that I supply to
customers, I guess they could change their application code from
"CreateFile() / ReadFile() / WriteFile() / CloseFile()" to call unique
methods in my DLL. Guess that's worth considering.

Mike Fochtman

Mike
Thu Sep 08 06:18:22 CDT 2005


"heinz" <heinz_baer@my-deja.com> wrote in message
news:1126149024.234191.275970@g47g2000cwa.googlegroups.com...
> The first thing I would do is run the chkinf tool (found in the DDK) to
> check for problems with your inf file. The next thing to do is look at
> setupapi.log to learn more about what failed. Next, run verifier,
> flipping on all its most stringest checks except simulating low
> resources. Finally, look at how you respond to each IRP, particularly
> the last one that arrives.
>

The chkinf tool reports no errors, other than the lack of a catalog file at
this point. I'll check the setupapi.log. I'm not sure the verifier will
help much since the driver is failing in the DriverEntry point (legacy
doesn't have an AddDevice() method).

> I am assuming you have a processor class driver. As far as pnp & power
> irps make sure you handle ones you don't know correctly: you DO NOT
> touch the status of the IRP and you DO NOT complete it; you pass it
> down without touching anything. And you must use PoStartNextPowerIrp &
> PoCallDriver for each power IRP. Hope that helps.
>

Yes, this helps. I was wondering exactly how to handle Po IRP's when my
device (being externally powered) doesn't really know anything about power
management.

Thanks,

Mike Fochtman

Mark
Thu Sep 08 06:45:40 CDT 2005

Mike Fochtman wrote:

> Thanks for the reply Mark...
>
> Yes, I had started with the storage/class/Cdrom sample. But for things like
> building the SRB and CDB, it often passes back into classpnp library. And
> as you say, that is not too well documented.
>

I agree - but the advantage of getting all the PNP stuff for free seems
compelling.


> I'm still puzzled as to why the legacy driver, that works in 2K and XP fails
> in 2003. Did something change there that no longer supports some legacy??
> Guess I'll have to fire up windbg to find out. But recompiling the old
> driver now to get a debug-build is a bit tricky, would have to get an NT
> 3.51 DDK (and that doesn't seem very easy).
>
Don't know - but there certainly is no guarantee that 3.51 driver
binaries work on any of these releases. You were living on borrowed time.

> I had considered just going direct with SCSI_PASS_THROUGH and
> SCSI_PASS_THROUGH_DIRECT, but it seems those specific ioctl() codes and the
> struct's needed (SRB and CDB) are only defined in DDK header files. So I'd
> have to somehow include those in my deliverables since clients won't have
> them by default??

scsi.h can be included in a user mode application/dll. The scsi
passthrough sample app in the ddk (<ddkroot>\src\storage\tools\spti)
unfortunately uses 'inheritance by cut'n'paste' to get the CDB
definitions but you don' have to do that.

>
> If I could somehow 'wrap' all those calls in a DLL that I supply to
> customers, I guess they could change their application code from
> "CreateFile() / ReadFile() / WriteFile() / CloseFile()" to call unique
> methods in my DLL. Guess that's worth considering.
>
> Mike Fochtman

That's the way I would go unless there is a compelling need for a kernel
mode class driver. Much easier to debug the user mode failure.


--

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

Maxim
Thu Sep 08 15:06:32 CDT 2005

IIRC MS's people warned against using the Processor device class for SCSI.
This is reserved for something.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Mike Fochtman" <mike@fochtman.org> wrote in message
news:%23u2Ue55sFHA.4076@TK2MSFTNGP11.phx.gbl...
> We have a legacy driver for NT to communicate with a piece of custom
> hardware. This hardware doesn't seem to fall into any of Microsoft's
> existing classes (at least I don't think so, but you've probably heard that
> line before).
>
> It attaches via a SCSI-2 interface, and meets the minimum requirements under
> SCSI-2 as a 'Processor' device. It allows the computer to interface with a
> large amount of individual I/O points used in a full-scope control room
> simulator (app. 1500 analog outputs, 7500 digital outputs, 4500 digital
> inputs, and 300 analog inputs, all scanned at 20 Hz).
>
> Our legacy driver, (originally written for NT 3.51) has served us pretty
> well through the various OS upgrades. I developed a new '.inf' file a few
> years back to provide client-side installation on Windows 2000. The same
> .inf and .sys files work under Windows XP (pro & home). But they do *not*
> seem to work on Windows 2003 Standard edition. Why not?? The OS complains
> about error starting the driver yet it works under XP and 2000.
>
> Anyway, I'm trying to write a new driver using the latest DDK and WDM models
> (I wrote the original as well). Or should I wait for WDF? But I can't find
> nearly the amount of information on SCSI device drivers that I had back in
> the NT days. Most new things are USB & 1394 it seems. I do have the SCSI
> specs down pat and work quite closely with the device firmware programmer,
> so I have that going for me (as well as a SCSI bus analyzer etc...) But
> searching for a good text on the subject of SCSI drivers under WDM hasn't
> been successful (have "Programming the Microsoft WIndows Driver Model" and
> "The Windows 2000 Device Driver Book", but they barely acknowledge that SCSI
> exists).
>
> I've started by using a storage/class sample from the DDK. But since 'SCSI
> Processor' devices support a lot fewer features than either CDROM, disk
> drives, or tape, there's a lot of code that needs to be thrown away. And
> cutting out code without breaking things is a bit tricky. Anyone have a
> better starting point for a simple SCSI device that still fits the WDM
> model?
>
> Also, since this device is external, and has it's own power, can I just
> reply success to all the power management requests (the device doesn't have
> any sort of power-down mode)?
>
> Sorry for the long ramble, but this is a small outfit and I feel lost in the
> wilderness a bit. I get to do the low-level drivers because I'm the one
> that works with the hardware folks and understand bit-bashing.
>
> Mike Fochtman
>
>
>

Norman
Sun Sep 11 20:38:45 CDT 2005

"Mike Fochtman" <mike@fochtman.org> wrote in message
news:uwi3ZbGtFHA.2880@TK2MSFTNGP12.phx.gbl...

> I'm still puzzled as to why the legacy driver, that works in 2K and XP
> fails in 2003. Did something change there that no longer supports some
> legacy?? Guess I'll have to fire up windbg to find out. But recompiling
> the old driver now to get a debug-build is a bit tricky, would have to get
> an NT 3.51 DDK (and that doesn't seem very easy).

I'd also try compiling with the W2K3SP1 DDK. If your legacy source code
compiles and runs then you'll have to ship two binaries (one for current
OSes and the older one for designated new technologies) but it might solve
your problem for you.

Mike
Wed Sep 14 14:46:01 CDT 2005


"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:eiPbhqLtFHA.1132@TK2MSFTNGP10.phx.gbl...
> IIRC MS's people warned against using the Processor device class for
> SCSI.
> This is reserved for something.
>

Yes, years ago I found that the SCSI-Scanner generic driver provided by MS
*assumed* that any SCSI processor class device was an image scanner. It
would allocate any SCSI Processor device and prevent my driver from loading.
But I worked around this with the Tag registry key to control load order so
my driver could allocate the device *before* the generic scanner.

Doesn't seem to be much of a problem in XP or 2000 since scanners now are
almost always USB or 1394. Nothing in MS documentation that discussed it
back then, and even less documentation about SCSI functional drivers now.
:-(

Mike Fochtman

> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>
> "Mike Fochtman" <mike@fochtman.org> wrote in message
> news:%23u2Ue55sFHA.4076@TK2MSFTNGP11.phx.gbl...
>> We have a legacy driver for NT to communicate with a piece of custom
>> hardware. This hardware doesn't seem to fall into any of Microsoft's
>> existing classes (at least I don't think so, but you've probably heard
>> that
>> line before).
>>
>> It attaches via a SCSI-2 interface, and meets the minimum requirements
>> under
>> SCSI-2 as a 'Processor' device. It allows the computer to interface with
>> a
>> large amount of individual I/O points used in a full-scope control room
>> simulator (app. 1500 analog outputs, 7500 digital outputs, 4500 digital
>> inputs, and 300 analog inputs, all scanned at 20 Hz).
>>
>> Our legacy driver, (originally written for NT 3.51) has served us pretty
>> well through the various OS upgrades. I developed a new '.inf' file a
>> few
>> years back to provide client-side installation on Windows 2000. The same
>> .inf and .sys files work under Windows XP (pro & home). But they do
>> *not*
>> seem to work on Windows 2003 Standard edition. Why not?? The OS
>> complains
>> about error starting the driver yet it works under XP and 2000.
>>
>> Anyway, I'm trying to write a new driver using the latest DDK and WDM
>> models
>> (I wrote the original as well). Or should I wait for WDF? But I can't
>> find
>> nearly the amount of information on SCSI device drivers that I had back
>> in
>> the NT days. Most new things are USB & 1394 it seems. I do have the
>> SCSI
>> specs down pat and work quite closely with the device firmware
>> programmer,
>> so I have that going for me (as well as a SCSI bus analyzer etc...) But
>> searching for a good text on the subject of SCSI drivers under WDM hasn't
>> been successful (have "Programming the Microsoft WIndows Driver Model"
>> and
>> "The Windows 2000 Device Driver Book", but they barely acknowledge that
>> SCSI
>> exists).
>>
>> I've started by using a storage/class sample from the DDK. But since
>> 'SCSI
>> Processor' devices support a lot fewer features than either CDROM, disk
>> drives, or tape, there's a lot of code that needs to be thrown away. And
>> cutting out code without breaking things is a bit tricky. Anyone have a
>> better starting point for a simple SCSI device that still fits the WDM
>> model?
>>
>> Also, since this device is external, and has it's own power, can I just
>> reply success to all the power management requests (the device doesn't
>> have
>> any sort of power-down mode)?
>>
>> Sorry for the long ramble, but this is a small outfit and I feel lost in
>> the
>> wilderness a bit. I get to do the low-level drivers because I'm the one
>> that works with the hardware folks and understand bit-bashing.
>>
>> Mike Fochtman
>>
>>
>>
>
>

heinz
Wed Sep 14 22:54:35 CDT 2005

> Yes, years ago I found that the SCSI-Scanner generic driver provided by
> MS *assumed* that any SCSI processor class device was an image scanner.

Right, this is an ancient issue that does not extend past NT 4. And
even in NT 4 is not a big deal.