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/
IRPS: Create and Close question
OSR_Community_User
Member Posts: 110,217
in NTDEV
Hello all,
I have a new client that doesn't want to behave like previous ones and has
his own driver always working (or almost) at DPC level. This means he will
call my Create and Close Irps at DPC level!
I've looked at the DDK and different web ressources to get the answer to
this question:
Are Create and Close Irps actually allowed to be called at DPC level?
Is there a guideline that says you should not?
If you return pending to a Create at DPC level, and then complete the irp in
a working thread will this work? I mean since the caller is at DPC level,
won't this create a problem where he might have to wait on an event (which
is not allowed at DPC level)?
Anyhow, thanks for all the help that I've received directly and indirectly
from all you people out there!
Steve.
I have a new client that doesn't want to behave like previous ones and has
his own driver always working (or almost) at DPC level. This means he will
call my Create and Close Irps at DPC level!
I've looked at the DDK and different web ressources to get the answer to
this question:
Are Create and Close Irps actually allowed to be called at DPC level?
Is there a guideline that says you should not?
If you return pending to a Create at DPC level, and then complete the irp in
a working thread will this work? I mean since the caller is at DPC level,
won't this create a problem where he might have to wait on an event (which
is not allowed at DPC level)?
Anyhow, thanks for all the help that I've received directly and indirectly
from all you people out there!
Steve.
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
driver' calls you at DISPATCH_LEVEL then he can't expect to block on any
events after your call returns as he will still be at DISPATCH_LEVEL, so its
like his problem if you return STATUS_PENDING.
> -----Original Message-----
> From: Steve Goddyn [mailto:[email protected]]
> Sent: Wednesday, March 29, 2000 11:42 AM
> To: NT Developers Interest List
> Subject: [ntdev] IRPS: Create and Close question
>
>
> Hello all,
>
> I have a new client that doesn't want to behave like previous
> ones and has
> his own driver always working (or almost) at DPC level. This
> means he will
> call my Create and Close Irps at DPC level!
>
> I've looked at the DDK and different web ressources to get
> the answer to
> this question:
>
> Are Create and Close Irps actually allowed to be called at DPC level?
>
> Is there a guideline that says you should not?
>
> If you return pending to a Create at DPC level, and then
> complete the irp in
> a working thread will this work? I mean since the caller is
> at DPC level,
> won't this create a problem where he might have to wait on an
> event (which
> is not allowed at DPC level)?
>
> Anyhow, thanks for all the help that I've received directly
> and indirectly
> from all you people out there!
>
> Steve.
>
> ---
> You are currently subscribed to ntdev as: [email protected]
> To unsubscribe send a blank email to $subst('Email.Unsub')
>
Do you think it's possible?
Create is sent by the IO manager's function IopParseDevice - executed at
PASSIVE_LEVEL.
Close is sent by the IO manager's function IopCloseFile - also executed at
PASSIVE_LEVEL (called by ObDerefenceObject).
Max
also possible that for some reason the driver above him is passing such an
irp down to him at DISPATCH_LEVEL. I mean, this was reported as what was
happening, so for the sake of argument I'll believe him. I also note that
returning STATUS_PENDING from create or close is generally not a good idea
either. It certainly can happen with read/write/ioctl irps.
I'd suggest asking the client driver developers to not do this.
I
> -----Original Message-----
> From: Maxim S. Shatskih [mailto:[email protected]]
> Sent: Wednesday, March 29, 2000 12:39 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: IRPS: Create and Close question
>
>
> > call my Create and Close Irps at DPC level!
>
> Do you think it's possible?
> Create is sent by the IO manager's function IopParseDevice -
> executed at
> PASSIVE_LEVEL.
> Close is sent by the IO manager's function IopCloseFile -
> also executed at
> PASSIVE_LEVEL (called by ObDerefenceObject).
>
> Max
>
>
> ---
> You are currently subscribed to ntdev as: [email protected]
> To unsubscribe send a blank email to $subst('Email.Unsub')
>
> irp down to him at DISPATCH_LEVEL.
Very strange. Create/close are not those requests which can be sent by
IoAllocateIrp etc. They seem to be sent by IO manager internals only - and I
don't think that sending them directly is a good idea.
Max
said, it may need to call a wait function, for instance, in the network
filesystem driver. It has to block the current thread while it waits for a
response from the remote host telling it if there is such a file to open or
not, and if the user should be allowed. It could not do this obviously at
DISPATCH_LEVEL. Further, I can only think of 2 times a thread should be at
DISPATCH_LEVEL, 1) it is in a DPC and 2) it grabbed a spin lock. Obviously
the first case is in an arbitrary thread context. One should never issue
IO requests from an arbitrary thread context that the dpc is running in,
even if the underlying driver could handle them because the IRP would be
tied to this arbitrary thread context and if say, that thread terminated,
it would cancel the IRP.
Anyhow, bottom line is that it can't be called at
DISPATCH_LEVEL. APC_LEVEL probobly, but not dispatch.
At 01:29 PM 3/29/00 -0500, you wrote:
>Yeah I agree that create/close originally happen at PASSIVE_LEVEL but it is
>also possible that for some reason the driver above him is passing such an
>irp down to him at DISPATCH_LEVEL. I mean, this was reported as what was
>happening, so for the sake of argument I'll believe him. I also note that
>returning STATUS_PENDING from create or close is generally not a good idea
>either. It certainly can happen with read/write/ioctl irps.
>
>I'd suggest asking the client driver developers to not do this.
>I
>
> > -----Original Message-----
> > From: Maxim S. Shatskih [mailto:[email protected]]
> > Sent: Wednesday, March 29, 2000 12:39 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] Re: IRPS: Create and Close question
> >
> >
> > > call my Create and Close Irps at DPC level!
> >
> > Do you think it's possible?
> > Create is sent by the IO manager's function IopParseDevice -
> > executed at
> > PASSIVE_LEVEL.
> > Close is sent by the IO manager's function IopCloseFile -
> > also executed at
> > PASSIVE_LEVEL (called by ObDerefenceObject).
> >
> > Max
> >
> >
> > ---
> > You are currently subscribed to ntdev as: [email protected]
> > To unsubscribe send a blank email to $subst('Email.Unsub')
> >
>
>---
>You are currently subscribed to ntdev as: [email protected]
>To unsubscribe send a blank email to $subst('Email.Unsub')
the following:
DispatchCreate(dev, irp)
{
// do some stuff
KeAcquireSpinLock(&myBigOldLock, ...);
// do some more stuff...
status = IoCallDriver(lowerDev, irp);
// continue doing stuff...
KeReleaseSpinLock(&myBigOldLock, ..);
// do some final stuff...
return status;
}
Nothing strictly illegal has happened.
> -----Original Message-----
> From: Maxim S. Shatskih [mailto:[email protected]]
> Sent: Friday, March 31, 2000 11:08 AM
> To: NT Developers Interest List
> Subject: [ntdev] Re: IRPS: Create and Close question
>
>
> > also possible that for some reason the driver above him is
> passing such an
> > irp down to him at DISPATCH_LEVEL.
>
> Very strange. Create/close are not those requests which can be sent by
> IoAllocateIrp etc. They seem to be sent by IO manager
> internals only - and I
> don't think that sending them directly is a good idea.
>
> Max
>
>
> ---
> You are currently subscribed to ntdev as: [email protected]
> To unsubscribe send a blank email to $subst('Email.Unsub')
>
dumb thing to do, so DO NOT DO THIS and we will not have any problems
Jamey
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Roddy, Mark
> Sent: Friday, March 31, 2000 8:24 AM
> To: NT Developers Interest List
> Subject: [ntdev] Re: IRPS: Create and Close question
>
>
> I'm not disagreeing with you. However, suppose that the upper driver does
> the following:
>
> DispatchCreate(dev, irp)
> {
> // do some stuff
>
> KeAcquireSpinLock(&myBigOldLock, ...);
>
> // do some more stuff...
>
> status = IoCallDriver(lowerDev, irp);
>
> // continue doing stuff...
>
> KeReleaseSpinLock(&myBigOldLock, ..);
>
> // do some final stuff...
>
> return status;
> }
>
> Nothing strictly illegal has happened.
>
> > -----Original Message-----
> > From: Maxim S. Shatskih [mailto:[email protected]]
> > Sent: Friday, March 31, 2000 11:08 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] Re: IRPS: Create and Close question
> >
> >
> > > also possible that for some reason the driver above him is
> > passing such an
> > > irp down to him at DISPATCH_LEVEL.
> >
> > Very strange. Create/close are not those requests which can be sent by
> > IoAllocateIrp etc. They seem to be sent by IO manager
> > internals only - and I
> > don't think that sending them directly is a good idea.
> >
> > Max
> >
> >
> > ---
> > You are currently subscribed to ntdev as: [email protected]
> > To unsubscribe send a blank email to $subst('Email.Unsub')
> >
>
> ---
> You are currently subscribed to ntdev as: [email protected]
> To unsubscribe send a blank email to $subst('Email.Unsub')
>
>
that supposedly was doing this, or something else that raised the create
thread to dispatch level. And who knows, perhaps they have a very good
reason. It is not illegal. Nor does it pose any insurmountable problems, as
long as the lower driver understands the rules.
> -----Original Message-----
> From: Jamey Kirby [mailto:[email protected]]
> Sent: Friday, March 31, 2000 12:02 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: IRPS: Create and Close question
>
>
> I would suspect that holding a spinlock on a create request
> like this is a
> dumb thing to do, so DO NOT DO THIS and we will not have any
> problems
>
> Jamey
>
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]]On Behalf Of Roddy, Mark
> > Sent: Friday, March 31, 2000 8:24 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] Re: IRPS: Create and Close question
> >
> >
> > I'm not disagreeing with you. However, suppose that the
> upper driver does
> > the following:
> >
> > DispatchCreate(dev, irp)
> > {
> > // do some stuff
> >
> > KeAcquireSpinLock(&myBigOldLock, ...);
> >
> > // do some more stuff...
> >
> > status = IoCallDriver(lowerDev, irp);
> >
> > // continue doing stuff...
> >
> > KeReleaseSpinLock(&myBigOldLock, ..);
> >
> > // do some final stuff...
> >
> > return status;
> > }
> >
> > Nothing strictly illegal has happened.
> >
> > > -----Original Message-----
> > > From: Maxim S. Shatskih [mailto:[email protected]]
> > > Sent: Friday, March 31, 2000 11:08 AM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] Re: IRPS: Create and Close question
> > >
> > >
> > > > also possible that for some reason the driver above him is
> > > passing such an
> > > > irp down to him at DISPATCH_LEVEL.
> > >
> > > Very strange. Create/close are not those requests which
> can be sent by
> > > IoAllocateIrp etc. They seem to be sent by IO manager
> > > internals only - and I
> > > don't think that sending them directly is a good idea.
> > >
> > > Max
> > >
> > >
> > > ---
> > > You are currently subscribed to ntdev as: [email protected]
> > > To unsubscribe send a blank email to
> $subst('Email.Unsub')
> > >
> >
> > ---
> > You are currently subscribed to ntdev as: [email protected]
> > To unsubscribe send a blank email to $subst('Email.Unsub')
> >
> >
>
>
> ---
> You are currently subscribed to ntdev as: [email protected]
> To unsubscribe send a blank email to $subst('Email.Unsub')
>
But calling anything complex while holding a spinlock is a bad idea.
The more well-known way of the dispatch functions to be called at
DISPATCH_LEVEL is calling IoCallDriver from the completion routine to
resubmit a request.
Max