NDIS miniport SurpriseRemoval problem in win2k3

Jan Bottorff wrote:

I’ve seen a depressing number of hardware designs where the hardware folks
know nothing about Windows requirements. It’s not until drivers are being
written for Windows or even WHQL tests are being run that the hardware
issues become apparent.

I generally dislike “me too” posts, but allow me to say a big AMEN to this.

As a consultant, I cannot tell you how many times I have been called in
at the very end of a project, with marketing champing at the bit to get
the thing out the door, only to find that the hardware and software
teams have never been in a room together. The hardware team throws a
spec and a hacked up diagnostic tool over a brick wall saying “well, it
worked once for us, therefore it has to work for you and any problems
must be yours, now we’re designing rev 2, don’t bother us” without any
understanding of the real world that Windows devices must inhabit.

It’s depressing.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

This problem is not unique to hardware; it’s also quite common in virtualization, in my opinion.

mm

> The OS is designed to not support such scenarios except by using RemovalRelations.
Thank you a lot!
RemovalRelations solved the problem.

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Tuesday, June 01, 2010 7:32 PM
Subject: Re: NDIS miniport SurpriseRemoval problem in win2k3

>Maybe I didn’t understand your idea. Could you elaborate ?

The “slave” device should return its “master” device in
RemovalRelations.

Then, if the “master” device is being removed, the OS mandates the
“slave” device removal sequence to be executed first.

This is how, for instance, the VHDMP’s storage port’s virtual disk
device is tied to the physical disk on which the .vhd file resides.

>[Leonid Keller] I can’t. These are separate *physical* functions, they
have to have their own drivers,
>possessing their HW resources. And the customer has to be able to
disable any of them.

This is not how PnP works. The OS is designed to not support such
scenarios except by using RemovalRelations.

Once more: you need the “slave” devices to be mandatory removed when
the “master” device is removed. The only two ways PnP provides for this
are a) parent-child relationship in the PnP tree, i.e. BusRelations b)
RemovalRelations.

No other reliable way.

Note that, with BusRelations, the master lists its slaves, and with
RemovalRelations, it’s vice versa - the master is just not aware of the
fact it is the master, but the slaves do know about who their master
is.

Also, there can be probable Windows versions restrictions on
RemovalRelations (Doron can tell more). If RemovalRelations are not
supported on some OS version - then sorry, parent-child relationship is
the only way to go.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com