Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.More Info on Driver Writing and Debugging
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
Miniport driver IOCTL related...
OSR_Community_User
Member Posts: 110,217
in NTDEV
Hi,
Here is the problem ....
In our Win NT SCSI miniport driver asynchronous event reporting from the
hardware is implemented in the following way....
An upper level application (one and only one such app) interested in
events
reported by the SCSI miniport driver posts a custom IOCTL termed as an
"event IOCTL" to the miniport driver. The miniport receives this (SRB
with
function IO Control) and holds onto this "event IOCTL" until such a time
as
an event occurs - at which time appropriate event related data is sent
back
to the application by "completing" this (event IOCTL) SRB request. While
the
miniport driver is holding onto this "event IOCTL", other regular IOCTLs
may
be issued to the miniport driver by the same application. These are
serviced synchronously.
The same miniport driver has been re-compiled with Win 2000 DDK and run
in
Win 2000 (Professional and Advanced Server). We observed that when the
app
has sent in the "event IOCTL" then follows it with a regular IOCTL, the
second IOCTL never seems to reach the miniport - so never gets complete
UNTIL an event occurs and the "event IOCTL" is completed. If we disable
issuing of this "event IOCTL" by the app then everything works fine.
Is this mechanism allowed. Can the miniport driver hold onto an IOCTL
(SRB
with SRB function as IO control ) and still receive more IOCTLs - or is
there some upper layer (FSD, Disk Class Driver, SCSI Port Driver)
restriction that prevents multiple SRBs with function IO control being
sent
to the miniport driver . This does not SEEM to be the case in Win NT
4.0,
however, if we run NT Cluster Server on NT 4 - the same thing seems to
happen..
Regards
Murali Ramanathan.
Here is the problem ....
In our Win NT SCSI miniport driver asynchronous event reporting from the
hardware is implemented in the following way....
An upper level application (one and only one such app) interested in
events
reported by the SCSI miniport driver posts a custom IOCTL termed as an
"event IOCTL" to the miniport driver. The miniport receives this (SRB
with
function IO Control) and holds onto this "event IOCTL" until such a time
as
an event occurs - at which time appropriate event related data is sent
back
to the application by "completing" this (event IOCTL) SRB request. While
the
miniport driver is holding onto this "event IOCTL", other regular IOCTLs
may
be issued to the miniport driver by the same application. These are
serviced synchronously.
The same miniport driver has been re-compiled with Win 2000 DDK and run
in
Win 2000 (Professional and Advanced Server). We observed that when the
app
has sent in the "event IOCTL" then follows it with a regular IOCTL, the
second IOCTL never seems to reach the miniport - so never gets complete
UNTIL an event occurs and the "event IOCTL" is completed. If we disable
issuing of this "event IOCTL" by the app then everything works fine.
Is this mechanism allowed. Can the miniport driver hold onto an IOCTL
(SRB
with SRB function as IO control ) and still receive more IOCTLs - or is
there some upper layer (FSD, Disk Class Driver, SCSI Port Driver)
restriction that prevents multiple SRBs with function IO control being
sent
to the miniport driver . This does not SEEM to be the case in Win NT
4.0,
however, if we run NT Cluster Server on NT 4 - the same thing seems to
happen..
Regards
Murali Ramanathan.
Howdy, Stranger!
| Upcoming OSR Seminars | ||
|---|---|---|
| OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead! | ||
| Internals & Software Drivers | 7 February 2022 | Live, Online |
| Kernel Debugging | 21 March 2022 | Live, Online |
| Developing Minifilters | 23 May 2022 | Live, Online |
| Writing WDF Drivers | 12 September 2022 | Live, Online |
Comments
for
'Exclusive' parameter. Otherwise you will not be able to call IOCTL with
several threads
at the same time.
Inaki.
> -----Original Message-----
> From: Eshanye.K.P
> Sent: mi?rcoles 29 de marzo de 2000 16:30
> To: NT Developers Interest List
> Subject: [ntdev] Miniport driver IOCTL related...
>
>
> Hi,
>
> Here is the problem ....
>
> In our Win NT SCSI miniport driver asynchronous event reporting from the
>
> hardware is implemented in the following way....
>
> An upper level application (one and only one such app) interested in
> events
> reported by the SCSI miniport driver posts a custom IOCTL termed as an
> "event IOCTL" to the miniport driver. The miniport receives this (SRB
> with
> function IO Control) and holds onto this "event IOCTL" until such a time
> as
> an event occurs - at which time appropriate event related data is sent
> back
> to the application by "completing" this (event IOCTL) SRB request. While
> the
> miniport driver is holding onto this "event IOCTL", other regular IOCTLs
> may
> be issued to the miniport driver by the same application. These are
> serviced synchronously.
>
> The same miniport driver has been re-compiled with Win 2000 DDK and run
> in
> Win 2000 (Professional and Advanced Server). We observed that when the
> app
> has sent in the "event IOCTL" then follows it with a regular IOCTL, the
> second IOCTL never seems to reach the miniport - so never gets complete
> UNTIL an event occurs and the "event IOCTL" is completed. If we disable
> issuing of this "event IOCTL" by the app then everything works fine.
>
> Is this mechanism allowed. Can the miniport driver hold onto an IOCTL
> (SRB
> with SRB function as IO control ) and still receive more IOCTLs - or is
> there some upper layer (FSD, Disk Class Driver, SCSI Port Driver)
> restriction that prevents multiple SRBs with function IO control being
> sent
> to the miniport driver . This does not SEEM to be the case in Win NT
> 4.0,
> however, if we run NT Cluster Server on NT 4 - the same thing seems to
> happen..
>
>
> Regards
> Murali Ramanathan.
>
>
> ---
> You are currently subscribed to ntdev as: [email protected]
> To unsubscribe send a blank email to $subst('Email.Unsub')