SCSI miniport handle

OSR_Community_User · September 24, 2001, 7:25am

Hi Joe,

This means you just do not open the handle to your SCSI miniport driver
correctly. There are at least two ways of doing (retreiving the handle of
SCSI miniport). First one is just walk down the list of the device objects
(you get the pointer to your driver object in DriverEntry() - that’s your
staring point) associated with your driver object and seek for
DEVICE_TYPE_CONTROLLER. Second way - you pass the name of the SCSI miniport
(or at least index) from the User Mode control application (you can
implement the IOCTL_SCSI_MINIPORT call in the SCSI miniport to differ your
SCSI miniport from the others, pass some kind of private structure and
analyze reponse filled by the SCSI miniport in your User Mode application)
to the SCSI miniport. Then you open the miniport by call to
ZwCreateFile(…) inside the worker thread and keep the handle value.
You’ll recycle this value in the serie of the calls to complete SRB.

Hi Anton,

Alright I got by that problem. New problem. I get a STATUS_NO_DEVICE
response to my intermediate SRB call. I set a break point in my
HwStartIo
and sure enough, I did not get called. After awhile of searching around
and
debugging. I realized my SRB was headed to my PCI/IDE controller Scsi
Miniport driver (atapi.sys). I guess this driver consumed device
//device/ScsiPort0. I assumed my Scsi Miniport should be at
//device/ScsiPort1 but when I tried I got a STATUS_OBJECT_NAME_NOT_FOUND
error when searching for the device object.

My virtual miniport was defined as an ISA device. It has nothing to do
with
ISA but I wanted to support the PnP model. Setting my miniport to an
Internal device causes the miniport to not support PnP. I want PnP
support
for power management of the system. In particular, hibernation support
for
our system. I also could never get it to call any of my entry points
after
HwFindAdapter was called when setting the miniport to Internal.

Any ideas?

Thanks,
Joe

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · September 24, 2001, 2:08pm

Hi Anton,

Got by that problem. The rest of the code is in place. SRB request that
need to go to the lower level driver are being executed and completed as
they should through the Intermediate callback routine. I am getting past
the DiskInitFdo routine and I am recieving
DiskDeviceControl requests. I got a BSOD when trying to read the partition
table and I got a BSOD from the disk class driver. stack is below.

fc9b07e4 809511ac 00000003 00000000 000000c2
ntkrnlmp!RtlpBreakWithStatusInstruction (FPO: [1,0,0])
fc9b0830 80951ac7 00000003 8019f684 815f9270
ntkrnlmp!KiBugCheckDebugBreak+0x19
fc9b0bf8 80951e7b 000000c2 00000006 00000c31 ntkrnlmp!KeBugCheck2+0x41c
fc9b0c18 809f148e 000000c2 00000006 00000c31 ntkrnlmp!KeBugCheckEx+0x19
fc9b0c64 80944ff0 815f9278 00000000 815fa8b8
ntkrnlmp!ExFreePoolWithTag+0xaeb
fc9b0cb4 80945454 00000000 00000000 81617000
ntkrnlmp!IopAllocateIrpPrivate+0xe6
fc9b0cf0 8094578b 00000003 815fa8b8 815f7000
ntkrnlmp!IoBuildAsynchronousFsdRequest+0x20
fc9b0d14 80a21af9 00000003 815fa8b8 815f7000
ntkrnlmp!IoBuildSynchronousFsdRequest+0x1b
fc9b0dd4 80a230d2 00000000 fc9b0df0 815d8f18
ntkrnlmp!IoReadPartitionTable+0x193
fc9b0df4 80a26b54 815d8f18 00000000 fc9b0e3c
ntkrnlmp!FstubReadPartitionTableMBR+0xa0
fc9b0e14 fbe67435 00000000 fc9b0e3c 00000000
ntkrnlmp!IoReadPartitionTableEx+0xdb
fc9b0e44 fbe5f29c 815fa970 00000000 fc9b0e84
disk!DiskReadPartitionTableEx+0x140 (FPO: [Non-Fpo])
[d:\ddk\winxprc1\src\storage\class\disk\part.c @ 140]
fc9b0e90 fbe57902 815fa8b8 81699220 815fa8b8
disk!DiskIoctlGetDriveLayoutEx+0xef (FPO: [Non-Fpo])
[d:\ddk\winxprc1\src\storage\class\disk\disk.c @ 5478]
fc9b1244 fbe71619 815fa8b8 81699220 815fa8b8 disk!DiskDeviceControl+0x1f7b
(FPO: [Non-Fpo]) [d:\ddk\winxprc1\src\storage\class\disk\disk.c @ 2236]
fc9b1260 80942df2 815fa8b8 81699220 00000000
CLASSPNP!ClassDeviceControlDispatch+0x68 (FPO: [Non-Fpo])
fc9b1278 fc810534 815fa758 00000000 816369b8 ntkrnlmp!IopfCallDriver+0x4f
fc9b12b4 fc811cda 815fa8b8 fc9b12e8 815fa6a0
partmgr!PmReadPartitionTableEx+0x66 (FPO: [Non-Fpo])
fc9b12f0 80942df2 815fa6a0 00000000 815fa6a0 partmgr!PmPnp+0x27a (FPO:
[Non-Fpo])
fc9b1308 80a5adde 00000001 815fbcb0 00000000 ntkrnlmp!IopfCallDriver+0x4f
fc9b1334 80a5af5e 815fa6a0 fc9b1348 00000000
ntkrnlmp!IopSynchronousCall+0xf1

BSOD parameters
BAD_POOL_CALLER (c2)
The current thread is making a bad pool request. Typically this is at a bad
IRQL level or double freeing the same allocation, etc.
Arguments:
Arg1: 00000006, Attempt to free pool which was already freed
Arg2: 00000c31, Reserved ( LINE )
Arg3: 815f9270, Pointer to pool header
Arg4: 00000000, Pool header contents
Creating .\DMP68.tmp - mini kernel dump

The dump of address 0x815f9270 is
kd> db 815f9270
815f9270 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
815f9280 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
815f9290 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
815f92a0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
815f92b0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
815f92c0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
815f92d0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
815f92e0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
kd> db
815f92f0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
815f9300 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
815f9310 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
815f9320 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
815f9330 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
815f9340 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
815f9350 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
815f9360 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …

I am lost as to why I am getting this BSOD. I don’t know if it’s because I
am using the stack for my SRB data buffer or whether I should allocate
memory of the heap for my SRB data buffer in my intermediate callback
routine. I don’t have MS source as to why this is happening. If anyone
knows what causes this or a way to debug this to find out why this is
happening, then that would be great.

Thanks,
Joe

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of
> xxxxx@hotmail.com
> Sent: Monday, September 24, 2001 7:22 AM
> To: NT Developers Interest List
> Subject: [ntdev] SCSI miniport handle
>
>
> Hi Joe,
>
> This means you just do not open the handle to your SCSI miniport driver
> correctly. There are at least two ways of doing (retreiving the handle of
> SCSI miniport). First one is just walk down the list of the
> device objects
> (you get the pointer to your driver object in DriverEntry() - that’s your
> staring point) associated with your driver object and seek for
> DEVICE_TYPE_CONTROLLER. Second way - you pass the name of the
> SCSI miniport
> (or at least index) from the User Mode control application (you can
> implement the IOCTL_SCSI_MINIPORT call in the SCSI miniport to
> differ your
> SCSI miniport from the others, pass some kind of private structure and
> analyze reponse filled by the SCSI miniport in your User Mode
> application)
> to the SCSI miniport. Then you open the miniport by call to
> ZwCreateFile(…) inside the worker thread and keep the handle value.
> You’ll recycle this value in the serie of the calls to complete SRB.
>
> >Hi Anton,
> >
> >Alright I got by that problem. New problem. I get a STATUS_NO_DEVICE
> >response to my intermediate SRB call. I set a break point in my
> HwStartIo
> >and sure enough, I did not get called. After awhile of searching around
> and
> >debugging. I realized my SRB was headed to my PCI/IDE controller Scsi
> >Miniport driver (atapi.sys). I guess this driver consumed device
> >//device/ScsiPort0. I assumed my Scsi Miniport should be at
> >//device/ScsiPort1 but when I tried I got a STATUS_OBJECT_NAME_NOT_FOUND
> >error when searching for the device object.
> >
> >My virtual miniport was defined as an ISA device. It has nothing to do
> with
> >ISA but I wanted to support the PnP model. Setting my miniport to an
> >Internal device causes the miniport to not support PnP. I want PnP
> support
> >for power management of the system. In particular, hibernation support
> for
> >our system. I also could never get it to call any of my entry points
> after
> >HwFindAdapter was called when setting the miniport to Internal.
> >
> >Any ideas?
> >
> >Thanks,
> >Joe
>
> —
> You are currently subscribed to ntdev as: xxxxx@east.sun.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · September 24, 2001, 4:53pm

> SCSI miniport). First one is just walk down the list of the device objects

(you get the pointer to your driver object in DriverEntry() - that’s your
staring point) associated with your driver object and seek for
DEVICE_TYPE_CONTROLLER.

Another unreliable idea.
This list is protected by a spinlock (IopDatabaseLock) which is not
accessible to you.

Max

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Mark_Roddy · September 24, 2001, 10:12pm

Aw Max, your no fun at all, it’ll work most of the time

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim
S. Shatskih
Sent: Monday, September 24, 2001 12:51 PM
To: NT Developers Interest List
Subject: [ntdev] Re: SCSI miniport handle

> SCSI miniport). First one is just walk down the list of the device
> objects (you get the pointer to your driver object in
DriverEntry() -
> that’s your staring point) associated with your driver
object and seek
> for DEVICE_TYPE_CONTROLLER.

Another unreliable idea.
This list is protected by a spinlock (IopDatabaseLock) which
is not accessible to you.

Max

You are currently subscribed to ntdev as:
xxxxx@hollistech.com To unsubscribe send a blank email to
leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Mark_Roddy · September 24, 2001, 10:33pm

And now back to the original problem, which was that the poster was
trying to create an ‘internal’ pnp scsi miniport driver, but had no luck
in convincing scsiport to let this happen.

Been there, done that. Scsiport (W2K, haven’t tried XP,) appears to have
a BUG (yes I know, unthinkable, but …) in this area. Indeed you cannot
have a PnP scsi miniport that has no resources! A pseudo miniport is
unlikely to have interrupts, IO ports or registers, but there it is,
scsiport says: sorry no resources no PNP, go away. So good enough, I
cooked my inf file to add some resources like so:

;
; bugbugbug - scsiport insists that we have to have some resources if we
are a pnp device
; so allocate 2 bytes of IO space between 0x100 and 0x400
;
[psMini.LogConfig]
ConfigPriority=NORMAL
IOConfig=2@100-400%fff0

OK? Ugly? But guess what? Scsiport decides that if I am ‘internal’ but I
have resources, then I must really be ISA. Yes it does.

At this point I could have conceded defeat and surrendered to the BORG,
but I was determined to have an internal pseudo miniport with pnp
support. So I added the following to my inf file:

[pnpsafe_internal_addreg]
HKR, “Parameters\PnpInterface”, %INTERNAL_BUS%, %REG_DWORD%, 0x00000001
;
;
; bugbugbug our internal interface requires a resource, which makes it
; an ISA interface.
;
HKR, “Parameters\PnpInterface”, %ISA_BUS%, %REG_DWORD%, 0x00000001

HAHAHAHA now I just add both interfaces in driver entry
ScsiPortInitialize! This is very silly, but it works. It still makes me
chuckle when I look at the code Of course you end up with TWO
interfaces, one of which is consigned to the ISA bus. Just don’t ever
find any Lus on the ISA interface

Obviously it would have been much easier to surrender to the BORG and
pretend that the adapter lives on the ISA bus. I have no idea what
happens if your platform doesn’t actually have an ISA bus.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim
S. Shatskih
Sent: Monday, September 24, 2001 12:51 PM
To: NT Developers Interest List
Subject: [ntdev] Re: SCSI miniport handle

> SCSI miniport). First one is just walk down the list of the device
> objects (you get the pointer to your driver object in
DriverEntry() -
> that’s your staring point) associated with your driver
object and seek
> for DEVICE_TYPE_CONTROLLER.

Another unreliable idea.
This list is protected by a spinlock (IopDatabaseLock) which
is not accessible to you.

Max

You are currently subscribed to ntdev as:
xxxxx@hollistech.com To unsubscribe send a blank email to
leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · September 25, 2001, 2:16am

> Another unreliable idea.

What was the first one?

This list is protected by a spinlock (IopDatabaseLock) which is not
accessible to you.

Well… You can go with “civilized” way - just retreiving the handle from
ZwCreateFile(…) as I do myself.

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com