Query Remove

NTDEV
1

Hi,

This is more about peace of mind really…

"A driver must fail a query-remove IRP if any of the following are true:
If removing the device could result in losing data… "

A solution I inherited (from an OSR sample) is to count ALL the irps
‘active’ on my driver. Pretty robust I thought! But then I changed the
sample.

The question I have is at the design/conceptual level.

Does this approach oblige me to put completion routines on all requests
that might go pending on lower drivers? Or is it safe to count down the
active irps after IoSkip… & IoCallDriver.

In other words if I return OK, will the system attempt a device removal
from a stack while there are irps active beneath me on the stack (and
presumably crash)?

In my driver this condition could (theoretically) occur if a lower driver
returns pending to IoCallDriver, though I ASSERT that it doesn’t do this
and in practice it seems OK.

Thanks for any advice on this matter.

Jack

PS Actually its the undefined non-wmi system control that I can’t find
assurances for, everything else I chain is OK, one way or another. So
either:

a) “SYSCTL never goes pending” or
b) “devices aren’t removed with Irps active on their stack”

is what I want to hear, and will get me design sign-off.

2

Jack Heeley wrote:

A solution I inherited (from an OSR sample) is to count ALL the irps
‘active’ on my driver. Pretty robust I thought! But then I changed the
sample.

This is a pretty complex question, actually. I suggest reading pp.
328-337 of my WDM book, where I try to explain it.

–
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

3

> a) “SYSCTL never goes pending” or

b) “devices aren’t removed with Irps active on their stack”

Surprise removal. A device can certainly be *physically* removed with IRPs
in process.
Now, how this pertains to your actual question, I’m not sure.

Loren

4

Not so relevent to my worry really…

I got a fairly complete PnP model from OSR’s AMCC sample a while back,
revised it for clarity, fixed a problem or two that became apparent, and
incorporated it into a reusable driver framework for WDM devices. The
framework architecture (for want of a better description) is effectively a
wrapper for a WDM “miniport”.

The ‘miniport’ gets the mandatory PnP Power Management WMI and DMA support
done for it quite transparently, while it can register its own simple
callbacks for sytem event handling, device operations, or to extend and/or
override the default solution provided in the wrapper. This makes it ideal
for our novice driver developers here at work, and we have even reused the
minport code on Linux (spit).

I’m very confident about that framework in the current context, in
particular when removing a device. I’ve tested it extensively with a
PCMCIA device, pulling and pushing card(s) at the most inopportune moments
and it has never let us down. Cancel handling is solid as a rock too.

There is an irritating issue with query remove (non-)notification and
applications with open handles on the driver, but that’s just the way
Windows is right now.

So, I’m looking forward to a couple of years of effortless churning out of
WDM drivers on demand using this code. But I need it to be completely
reliable.

The problem I see doesn’t relate to the routine open, close, read, write
or ioctl irps (dealt with), but rather to power, pnp and sysctl irps.

These are forced upon us by the need to provide “mandatory” minimal PnP,
WMI, and Power Management requirements. Here we’re obliged, now and again,
to chain on the Irp.

Now for PnP, WMI, and PM, I’m already convinced of my design. The DDK
gives all the assurances I need in order to be able to rely on the
approach I’m taking.

The real issue lies with IRP_MJ_SYSTEM_CONTROL that is something OTHER
than WMI. I can’t find any soothing words of comfort about these requests
(in fact I can’t find anything much except for sample code that glibly
chains them through.

So my choices are:-

a) bounce all SYSCTL that isn’t WMI (a non-starter)
b) chain it and *hope* (ASSERT) that it doesn’t go pending (what I do now)
c) add a completion routine and do my active Irp countdown there.

Hmm. I guess, if I’m worried, then the solution is always c)

GEE, THANKS!!!

5

Thanks Walter,

I meant to order it a while back then forgot all about it.

This one I presume?

Programming the Microsoft® Windows® Driver Model
Author Walter Oney
Pages 640
Disk 1 Companion CD(s)
Level Intermediate
Published 10/13/1999
ISBN 0-7356-0588-2
Price $49.99

6

That’s the first edition. The second edition ISBN is 0-7356-1803-8.
Price printed on the cover is US$59.99.

Jack Heeley wrote:

This one I presume?

ISBN 0-7356-0588-2

–
If replying by e-mail, please remove “nospam.” from the address.

James Antognini
Windows DDK MVP