NDIS miniport SurpriseRemoval problem in win2k3

Leonid_Keller · May 23, 2010, 6:11pm

Hi All,

We have a WDF bus driver, which creates as a child an NDIS miniport Ethernet adapter.
When the bus driver Surprise Remove itself, it works the first time, but gets stuck the second time (after disable/enable the bus driver).
DevNode of the Ethernet driver remains in SurpriseRemove state as if it is waiting for releasing some resource.
I run pnpdtest from WDK with “SurpriseRemove” option - the same result: the first time the test passes, the second time it fails to attach the filter driver.
All PnP staff in the bus driver is handled by WDF DLL, in the Ethernet driver - by NDIS DLL.
My question is: what’s the way to debug the problem ?
(To remind: it happens in Windows 2003)

Thank you.

Leonid

Gary_Little-3 · May 23, 2010, 7:01pm

Rather obvious … connect a host running WinDbg, set a breakpoint in the
Driverentry, and the Surprise removal function. When the conditions are met
and your in the surprise removal function step into it and find out what is
going on.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Leonid Keller
Sent: Sunday, May 23, 2010 5:11 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] NDIS miniport SurpriseRemoval problem in win2k3

Hi All,

We have a WDF bus driver, which creates as a child an NDIS miniport Ethernet
adapter.
When the bus driver Surprise Remove itself, it works the first time, but
gets stuck the second time (after disable/enable the bus driver).
DevNode of the Ethernet driver remains in SurpriseRemove state as if it is
waiting for releasing some resource.
I run pnpdtest from WDK with “SurpriseRemove” option - the same result: the
first time the test passes, the second time it fails to attach the filter
driver.
All PnP staff in the bus driver is handled by WDF DLL, in the Ethernet
driver - by NDIS DLL.
My question is: what’s the way to debug the problem ?
(To remind: it happens in Windows 2003)

Thank you.

Leonid

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

__________ Information from ESET Smart Security, version of virus signature
database 5139 (20100523) __________

The message was checked by ESET Smart Security.

http://www.eset.com

__________ Information from ESET Smart Security, version of virus signature
database 5139 (20100523) __________

The message was checked by ESET Smart Security.

http://www.eset.com

Doron_Holan · May 23, 2010, 7:36pm

You get stuck in the surprise removed state when there is an open handle on the device that is not closed. !object on the fdo and pdo for the nic will give the handle count, !devnode 1 1 might give you more info on the orphaned devnode.

d

sent from a phpne with no keynoard

-----Original Message-----
From: Leonid Keller
Sent: May 23, 2010 3:12 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] NDIS miniport SurpriseRemoval problem in win2k3

Hi All,

We have a WDF bus driver, which creates as a child an NDIS miniport Ethernet adapter.
When the bus driver Surprise Remove itself, it works the first time, but gets stuck the second time (after disable/enable the bus driver).
DevNode of the Ethernet driver remains in SurpriseRemove state as if it is waiting for releasing some resource.
I run pnpdtest from WDK with “SurpriseRemove” option - the same result: the first time the test passes, the second time it fails to attach the filter driver.
All PnP staff in the bus driver is handled by WDF DLL, in the Ethernet driver - by NDIS DLL.
My question is: what’s the way to debug the problem ?
(To remind: it happens in Windows 2003)

Thank you.

Leonid

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

David_R_Cattley · May 23, 2010, 11:43pm

Be sure to verify that all resources (packets, etc.) passed across any
active bindings have been properly returned as well. NDIS will not halt the
adapter until all received packets indicated by the adapter have been
returned by bound protocols and all packets sent from bound protocols have
been completed by the adapter. A pending Miniport{Set|Get}Information can
also delay halt as it will also be a reference on the ‘open’ (binding).

The !ndiskd extension can help in diagnosing such things. You might also
try unbinding the adapter from everything (use BindView) and see if that
changes the test result.

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Sunday, May 23, 2010 7:36 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NDIS miniport SurpriseRemoval problem in win2k3

You get stuck in the surprise removed state when there is an open handle on
the device that is not closed. !object on the fdo and pdo for the nic will
give the handle count, !devnode 1 1 might give you more info on the orphaned
devnode.

d

sent from a phpne with no keynoard

-----Original Message-----
From: Leonid Keller
Sent: May 23, 2010 3:12 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] NDIS miniport SurpriseRemoval problem in win2k3

Hi All,

We have a WDF bus driver, which creates as a child an NDIS miniport Ethernet
adapter.
When the bus driver Surprise Remove itself, it works the first time, but
gets stuck the second time (after disable/enable the bus driver).
DevNode of the Ethernet driver remains in SurpriseRemove state as if it is
waiting for releasing some resource.
I run pnpdtest from WDK with “SurpriseRemove” option - the same result: the
first time the test passes, the second time it fails to attach the filter
driver.
All PnP staff in the bus driver is handled by WDF DLL, in the Ethernet
driver - by NDIS DLL.
My question is: what’s the way to debug the problem ?
(To remind: it happens in Windows 2003)

Thank you.

Leonid

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Leonid_Keller · May 24, 2010, 1:19pm

Thank you, Doron.

I tried it.
The problem is that you don’t know who has taken this reference.
Vista gives a ref count tracing facility, but I have the problem on win2k3, which doesn’t have it.

I tried also your idea to set a breakpoint on modifying the ref count with ‘kb’ every time, but it creates an enormous output. It turns out that these counters get changed much more often then one can expect. E.g., every time, when netman sends some request to all Ethernet adapters, someone increase/decrease the ref counters …

Any more ideas ?

-----Original Message-----
From: Doron Holan [mailto:xxxxx@microsoft.com]
Sent: Monday, May 24, 2010 2:36 AM
Subject: RE: NDIS miniport SurpriseRemoval problem in win2k3

You get stuck in the surprise removed state when there is an open
handle on the device that is not closed. !object on the fdo and pdo for
the nic will give the handle count, !devnode 1 1 might give you more
info on the orphaned devnode.

d

sent from a phpne with no keynoard

-----Original Message-----
From: Leonid Keller
> Sent: May 23, 2010 3:12 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] NDIS miniport SurpriseRemoval problem in win2k3
>
>
> Hi All,
>
> We have a WDF bus driver, which creates as a child an NDIS miniport
> Ethernet adapter.
> When the bus driver Surprise Remove itself, it works the first time,
> but gets stuck the second time (after disable/enable the bus driver).
> DevNode of the Ethernet driver remains in SurpriseRemove state as if it
> is waiting for releasing some resource.
> I run pnpdtest from WDK with “SurpriseRemove” option - the same result:
> the first time the test passes, the second time it fails to attach the
> filter driver.
> All PnP staff in the bus driver is handled by WDF DLL, in the Ethernet
> driver - by NDIS DLL.
> My question is: what’s the way to debug the problem ?
> (To remind: it happens in Windows 2003)
>
> Thank you.
>
> Leonid
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

Leonid_Keller · May 24, 2010, 1:43pm

Thank you, David.

I’ll try it, but I’m not too optimistic.
The problem is, that it get stuck somewhere between Halt and Unload.
I mean that both Halt routine of Ethernet driver and EvtReleaseHardware of bus driver get called.
So, from both drivers’ point of view IRP_MN_REMOVE has been handled.
But neither Unload routine is not called.
Devnode of Ethernet driver is left in DeviceNodeRemovePendingCloses state…
Device Manager tells “driver is still in memory. Make reboot”.

-----Original Message-----
From: David R. Cattley [mailto:xxxxx@msn.com]
Sent: Monday, May 24, 2010 6:43 AM
Subject: RE: NDIS miniport SurpriseRemoval problem in win2k3

Be sure to verify that all resources (packets, etc.) passed across any
active bindings have been properly returned as well. NDIS will not
halt the
adapter until all received packets indicated by the adapter have been
returned by bound protocols and all packets sent from bound protocols
have
been completed by the adapter. A pending Miniport{Set|Get}Information
can
also delay halt as it will also be a reference on the ‘open’ (binding).

The !ndiskd extension can help in diagnosing such things. You might
also
try unbinding the adapter from everything (use BindView) and see if
that
changes the test result.

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Sunday, May 23, 2010 7:36 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NDIS miniport SurpriseRemoval problem in win2k3

You get stuck in the surprise removed state when there is an open
handle on
the device that is not closed. !object on the fdo and pdo for the nic
will
give the handle count, !devnode 1 1 might give you more info on the
orphaned
devnode.

d

sent from a phpne with no keynoard

-----Original Message-----
From: Leonid Keller
> Sent: May 23, 2010 3:12 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] NDIS miniport SurpriseRemoval problem in win2k3
>
>
> Hi All,
>
> We have a WDF bus driver, which creates as a child an NDIS miniport
> Ethernet
> adapter.
> When the bus driver Surprise Remove itself, it works the first time,
> but
> gets stuck the second time (after disable/enable the bus driver).
> DevNode of the Ethernet driver remains in SurpriseRemove state as if it
> is
> waiting for releasing some resource.
> I run pnpdtest from WDK with “SurpriseRemove” option - the same result:
> the
> first time the test passes, the second time it fails to attach the
> filter
> driver.
> All PnP staff in the bus driver is handled by WDF DLL, in the Ethernet
> driver - by NDIS DLL.
> My question is: what’s the way to debug the problem ?
> (To remind: it happens in Windows 2003)
>
> Thank you.
>
> Leonid
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

Alex_Grig · May 28, 2010, 1:43pm

Make sure to return all pending packets back to NDIS. Also, if it is a wireless device, WZC app used to be stupid in XP and not release the device handle. I don’t know when that was fixed.

Leonid_Keller · May 31, 2010, 12:55pm

I’d like to bother you once more with this problem, because I can’t find solution so far.
Here is the full story.
We have a HW device, which is handled by WDF bus driver mx4bus and its child, NDIS miniport driver mx4eth.
The HW device can expose several functions, which - from OS’s point of view - are fully independent.
But in fact only one of them is a primary function (PPF), all the rest are secondary ones (PF), which are dependent from PPF.
So for every HW function I have a pair of instances mx4bus/mx4eth, handling it.

If one first removes PFs (secondary devices) and then PPF (the primary one) - all is OK.
But if one first removes PPF, the driver *must* first force removing of all PFs, because they can’t work without PPF.
That was the problem in the first place.
I solved it by sending an event “RemoveItself” to all PFs from PPF, while handling REMOVE_DEVICE IRP (for PPF).
I.e., PPF sends the events and waits for all PFs to exit.
PFs call WdfDeviceSetFailed and remove themselves.
Then PPF happily exits.

It works in Vista, but not in Windows 2003.
As I revealed, Windows 2003 doesn’t start to perform Surprise Removal on PFs before it finishes the removing of PPF.
(Despite they are independent devices from its point of view!)

Then I made another solution.
PFs release all the PPFs resources upon “RemoveItself” event and tells it, they’ve exited.
Then PPF successfully exits and OS starts the surprise removing of all PFs.
Seems like it has to work. But it doesn’t.

What happens?
For some unclear reason, it always works the first time - all the devices get removed.
But if I enable/disable them all once more, all PFs get marked as “Needed reboot” in Device Manager (PPF is removed OK).

What I see in the debugger when it happens:

REMOVE_DEVICE IRP was handled in both drivers (Halt of mx4eth and EvtReleaseHardware of mx4bus were called).
Ethernet devices are removed from the device tree (‘!devnode 0 1’ do not show them)
Neither Unload function is called, so both drivers are still in memory.
!ndiskd.miniports doesn’t shows mx4eth of PFs, but !ndiskd.gminiports does.
!ndiskd.miniport <pf_mx4eth_device> shows no protocols, all counters are zeros, but it shows FDO and PDO.
6. !object on FDO shows PointerCount=2 (OK?), on PDO it shows PointerCount=3 (leak?).
7. !devnode shows:
State = DeviceNodeDeletePendingCloses (0x313)
Previous State = DeviceNodeRemovePendingCloses (0x311)
StateHistory[13] = DeviceNodeRemovePendingCloses (0x311)
StateHistory[12] = DeviceNodeStarted (0x308)
Flags (0x00000120) DNF_IDS_QUERIED, DNF_NO_RESOURCE_REQUIRED
CapabilityFlags (0x00000a01) DeviceD1, SurpriseRemovalOK, WakeFromD1

8. !devnode of its “father” mx4bus shows:
State = DeviceNodeRemovePendingCloses (0x311)
Previous State = DeviceNodeStarted (0x308)
StateHistory[13] = DeviceNodeStarted (0x308)
Flags (0x00000030) DNF_ENUMERATED, DNF_IDS_QUERIED
UserFlags (0x00000004) DNUF_NEED_RESTART
CapabilityFlags (0x00000210) Removable, SurpriseRemovalOK

9. !object on its PDO shows PointerCount=4 (OK?)
10. ‘!devnode 1 1’ returns “Error reading pending relations list entry”

My guess is, that PointerCount=3 (in 6.) is a leak, which causes all the problem.
But I don’t know how to check it and don’t know how to find who made the leak.
Vista has a facility of PointerCount tracing, but Windows 2003 - doesn’t, AFAIK.

Can it be a bug in OS ?
What’s the way to investigate the problem ?
Is there any other solution for the entire problem ?

Thank in advance.

P.S.
1. mx4bus without mx4eth gets removed OK, so mx4eth is somehow “guilty”;
2. mx4eth can be removed with “pnpdtest ‘SurpriseRemoval’” without problem.
3. mx4bus get marked “Need reboot” after first running of “pnpdtest ‘SurpriseRemoval’”.
Maybe there is a bug in pnpdtest, maybe it is the same problem as with surptise removal of PFs.
The latter case is maybe simpler to investigate, because there is only one pair of mx4bus/mx4eth (only PPF).
But how can I do it ?
The test passes OK, but device node of mx4bus gets marked with DNUF_NEED_RESTART…

> -----Original Message-----
> From: Leonid Keller [mailto:xxxxx@mellanox.co.il]
> Sent: Monday, May 24, 2010 8:43 PM
> Subject: RE: NDIS miniport SurpriseRemoval problem in win2k3
>
> Thank you, David.
>
> I’ll try it, but I’m not too optimistic.
> The problem is, that it get stuck somewhere between Halt and Unload.
> I mean that both Halt routine of Ethernet driver and EvtReleaseHardware
> of bus driver get called.
> So, from both drivers’ point of view IRP_MN_REMOVE has been handled.
> But neither Unload routine is not called.
> Devnode of Ethernet driver is left in DeviceNodeRemovePendingCloses
> state…
> Device Manager tells “driver is still in memory. Make reboot”.
>
> > -----Original Message-----
> > From: David R. Cattley [mailto:xxxxx@msn.com]
> > Sent: Monday, May 24, 2010 6:43 AM
> > Subject: RE: NDIS miniport SurpriseRemoval problem in win2k3
> >
> > Be sure to verify that all resources (packets, etc.) passed across
> any
> > active bindings have been properly returned as well. NDIS will not
> > halt the
> > adapter until all received packets indicated by the adapter have been
> > returned by bound protocols and all packets sent from bound protocols
> > have
> > been completed by the adapter. A pending
> Miniport{Set|Get}Information
> > can
> > also delay halt as it will also be a reference on the ‘open’
> (binding).
> >
> > The !ndiskd extension can help in diagnosing such things. You might
> > also
> > try unbinding the adapter from everything (use BindView) and see if
> > that
> > changes the test result.
> >
> > Good Luck,
> > Dave Cattley
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
> > Sent: Sunday, May 23, 2010 7:36 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] NDIS miniport SurpriseRemoval problem in win2k3
> >
> > You get stuck in the surprise removed state when there is an open
> > handle on
> > the device that is not closed. !object on the fdo and pdo for the nic
> > will
> > give the handle count, !devnode 1 1 might give you more info on the
> > orphaned
> > devnode.
> >
> > d
> >
> > sent from a phpne with no keynoard
> >
> > -----Original Message-----
> > From: Leonid Keller
> > Sent: May 23, 2010 3:12 PM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] NDIS miniport SurpriseRemoval problem in win2k3
> >
> >
> > Hi All,
> >
> > We have a WDF bus driver, which creates as a child an NDIS miniport
> > Ethernet
> > adapter.
> > When the bus driver Surprise Remove itself, it works the first time,
> > but
> > gets stuck the second time (after disable/enable the bus driver).
> > DevNode of the Ethernet driver remains in SurpriseRemove state as if
> it
> > is
> > waiting for releasing some resource.
> > I run pnpdtest from WDK with “SurpriseRemove” option - the same
> result:
> > the
> > first time the test passes, the second time it fails to attach the
> > filter
> > driver.
> > All PnP staff in the bus driver is handled by WDF DLL, in the
> Ethernet
> > driver - by NDIS DLL.
> > My question is: what’s the way to debug the problem ?
> > (To remind: it happens in Windows 2003)
> >
> > Thank you.
> >
> > Leonid
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer</pf_mx4eth_device>

Maxim_S_Shatskih · May 31, 2010, 1:03pm

>But if one first removes PPF, the driver *must* first force removing of all PFs, because they can’t work

without PPF.

For me, switching them to the mode where they will fail everything (though still present in the Device Manager) is OK.
Try playing with RemovalRelations.
Try restructure the bus driver so that the SFs will be the PnP children (not siblings) of the PF.

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

Calvin_Guan-3 · May 31, 2010, 1:45pm

It certainly seems some reference leaks somewhere. The ba trick doesn’t work
very well on NDIS miniport’s dev_obj because the stack and some OS WMI junks
love to ref/deref it zillion of times. It can be done if you are desperate
enough. For every bp hit, dump the callstack and go. Do this in a
“composite” command instead of hitting the keyboard. Well, it’s slow and
painful and you have a lot of things to read. You may want to unbind all
protocols, intermediate drivers from your miniport to improve your SNR.

From what you have said, it’s not clear to me if it has anything to do with
your function dependency. I would try to run the test with all secondary
physical function disabled to rule this in or out.

Having dependency between physical PCI functions violate the “Design for
Windows” rule. Your hardware team shouldn’t have delivered such thing in the
first place. From end customer’s perspective, this is very frustrating, say
I wanted to only disable port 0, but it disables 0,1,2,3,4,5,6,7 all without
warning.

If it has not been taped out, fix the RTL. If it has been shipped, fix it in
the next revision. Function dependency should be dealt with in fw and hw,
not Windows. There are many ways doing it.

Good luck,
Calvin

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Leonid Keller
Sent: Monday, May 31, 2010 9:54 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] NDIS miniport SurpriseRemoval problem in win2k3

I’d like to bother you once more with this problem, because I can’t find
solution so far.
Here is the full story.
We have a HW device, which is handled by WDF bus driver mx4bus and its
child, NDIS miniport driver mx4eth.
The HW device can expose several functions, which - from OS’s point of view

are fully independent.
But in fact only one of them is a primary function (PPF), all the rest are
secondary ones (PF), which are dependent from PPF.
So for every HW function I have a pair of instances mx4bus/mx4eth, handling
it.

If one first removes PFs (secondary devices) and then PPF (the primary one)

all is OK.
But if one first removes PPF, the driver *must* first force removing of all
PFs, because they can’t work without PPF.
That was the problem in the first place.
I solved it by sending an event “RemoveItself” to all PFs from PPF, while
handling REMOVE_DEVICE IRP (for PPF).
I.e., PPF sends the events and waits for all PFs to exit.
PFs call WdfDeviceSetFailed and remove themselves.
Then PPF happily exits.

It works in Vista, but not in Windows 2003.
As I revealed, Windows 2003 doesn’t start to perform Surprise Removal on PFs
before it finishes the removing of PPF.
(Despite they are independent devices from its point of view!)

Then I made another solution.
PFs release all the PPFs resources upon “RemoveItself” event and tells it,
they’ve exited.
Then PPF successfully exits and OS starts the surprise removing of all PFs.
Seems like it has to work. But it doesn’t.

What happens?
For some unclear reason, it always works the first time - all the devices
get removed.
But if I enable/disable them all once more, all PFs get marked as “Needed
reboot” in Device Manager (PPF is removed OK).

What I see in the debugger when it happens:

REMOVE_DEVICE IRP was handled in both drivers (Halt of mx4eth and
EvtReleaseHardware of mx4bus were called).
Ethernet devices are removed from the device tree (‘!devnode 0 1’ do not
show them)
Neither Unload function is called, so both drivers are still in memory.
!ndiskd.miniports doesn’t shows mx4eth of PFs, but !ndiskd.gminiports
does.
!ndiskd.miniport <pf_mx4eth_device> shows no protocols, all counters are
zeros, but it shows FDO and PDO.
6. !object on FDO shows PointerCount=2 (OK?), on PDO it shows PointerCount=3
(leak?).
7. !devnode shows:
State = DeviceNodeDeletePendingCloses (0x313)
Previous State = DeviceNodeRemovePendingCloses (0x311)
StateHistory[13] = DeviceNodeRemovePendingCloses (0x311)
StateHistory[12] = DeviceNodeStarted (0x308)
Flags (0x00000120) DNF_IDS_QUERIED, DNF_NO_RESOURCE_REQUIRED
CapabilityFlags (0x00000a01) DeviceD1, SurpriseRemovalOK, WakeFromD1

8. !devnode of its “father” mx4bus shows:
State = DeviceNodeRemovePendingCloses (0x311)
Previous State = DeviceNodeStarted (0x308)
StateHistory[13] = DeviceNodeStarted (0x308)
Flags (0x00000030) DNF_ENUMERATED, DNF_IDS_QUERIED
UserFlags (0x00000004) DNUF_NEED_RESTART
CapabilityFlags (0x00000210) Removable, SurpriseRemovalOK

9. !object on its PDO shows PointerCount=4 (OK?)
10. ‘!devnode 1 1’ returns “Error reading pending relations list entry”

My guess is, that PointerCount=3 (in 6.) is a leak, which causes all the
problem.
But I don’t know how to check it and don’t know how to find who made the
leak.
Vista has a facility of PointerCount tracing, but Windows 2003 - doesn’t,
AFAIK.

Can it be a bug in OS ?
What’s the way to investigate the problem ?
Is there any other solution for the entire problem ?

Thank in advance.

P.S.
1. mx4bus without mx4eth gets removed OK, so mx4eth is somehow “guilty”;
2. mx4eth can be removed with “pnpdtest ‘SurpriseRemoval’” without
problem.
3. mx4bus get marked “Need reboot” after first running of “pnpdtest
‘SurpriseRemoval’”.
Maybe there is a bug in pnpdtest, maybe it is the same problem as with
surptise removal of PFs.
The latter case is maybe simpler to investigate, because there is only
one pair of mx4bus/mx4eth (only PPF).
But how can I do it ?
The test passes OK, but device node of mx4bus gets marked with
DNUF_NEED_RESTART…

> -----Original Message-----
> From: Leonid Keller [mailto:xxxxx@mellanox.co.il]
> Sent: Monday, May 24, 2010 8:43 PM
> Subject: RE: NDIS miniport SurpriseRemoval problem in win2k3
>
> Thank you, David.
>
> I’ll try it, but I’m not too optimistic.
> The problem is, that it get stuck somewhere between Halt and Unload.
> I mean that both Halt routine of Ethernet driver and EvtReleaseHardware
> of bus driver get called.
> So, from both drivers’ point of view IRP_MN_REMOVE has been handled.
> But neither Unload routine is not called.
> Devnode of Ethernet driver is left in DeviceNodeRemovePendingCloses
> state…
> Device Manager tells “driver is still in memory. Make reboot”.
>
> > -----Original Message-----
> > From: David R. Cattley [mailto:xxxxx@msn.com]
> > Sent: Monday, May 24, 2010 6:43 AM
> > Subject: RE: NDIS miniport SurpriseRemoval problem in win2k3
> >
> > Be sure to verify that all resources (packets, etc.) passed across
> any
> > active bindings have been properly returned as well. NDIS will not
> > halt the
> > adapter until all received packets indicated by the adapter have been
> > returned by bound protocols and all packets sent from bound protocols
> > have
> > been completed by the adapter. A pending
> Miniport{Set|Get}Information
> > can
> > also delay halt as it will also be a reference on the ‘open’
> (binding).
> >
> > The !ndiskd extension can help in diagnosing such things. You might
> > also
> > try unbinding the adapter from everything (use BindView) and see if
> > that
> > changes the test result.
> >
> > Good Luck,
> > Dave Cattley
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
> > Sent: Sunday, May 23, 2010 7:36 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] NDIS miniport SurpriseRemoval problem in win2k3
> >
> > You get stuck in the surprise removed state when there is an open
> > handle on
> > the device that is not closed. !object on the fdo and pdo for the nic
> > will
> > give the handle count, !devnode 1 1 might give you more info on the
> > orphaned
> > devnode.
> >
> > d
> >
> > sent from a phpne with no keynoard
> >
> > -----Original Message-----
> > From: Leonid Keller
> > Sent: May 23, 2010 3:12 PM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] NDIS miniport SurpriseRemoval problem in win2k3
> >
> >
> > Hi All,
> >
> > We have a WDF bus driver, which creates as a child an NDIS miniport
> > Ethernet
> > adapter.
> > When the bus driver Surprise Remove itself, it works the first time,
> > but
> > gets stuck the second time (after disable/enable the bus driver).
> > DevNode of the Ethernet driver remains in SurpriseRemove state as if
> it
> > is
> > waiting for releasing some resource.
> > I run pnpdtest from WDK with “SurpriseRemove” option - the same
> result:
> > the
> > first time the test passes, the second time it fails to attach the
> > filter
> > driver.
> > All PnP staff in the bus driver is handled by WDF DLL, in the
> Ethernet
> > driver - by NDIS DLL.
> > My question is: what’s the way to debug the problem ?
> > (To remind: it happens in Windows 2003)
> >
> > Thank you.
> >
> > Leonid
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</pf_mx4eth_device>

OSR_Community_User · May 31, 2010, 3:10pm

> Having dependency between physical PCI functions violate the "Design

for
Windows" rule. Your hardware team shouldn’t have delivered such thing
in the
first place.

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.

This is partially because some hardware folks think Linux and Windows have
the same requirements (and OS is an OS), and since they can look at the
source code of Linux, they can figure out what these hardware requirements
are. Linux is becoming (or has become) the OS model hardware is frequently
designed around. I think this is also partially Microsoft’s fault, for not
having extensive easily available documentation about Windows hardware
requirements. I believe you can’t actually look at the WHQL specs unless you
sign up for a WHQL account, which is WAY down the path of some product
designs.

An example I just wrote about, if you design hardware with PCIe serial
number attributes in the extended config space, you can have a significant
boot image compatibility issue between identical machines. I don’t believe
this is even mentioned in the WHQL docs, and may only be learned when you
start shipping your product to Windows customers. Your Linux customers may
not have any issues.

I think another part of the problem is just a weird belief about what the
installed base of systems is. Here in Silicon Valley, a LOT of people seem
to think Linux has a way bigger market share on servers than Windows. The
assumption must be most corporations run their IT group like Goggle (which
does have like half a million Linux servers). As a result, they design
products based on the that belief, and some get rather rude introduced to
reality when they start shipping their product and find half or more of
their customers exclusively run Windows. The effect though is lots of
products get designed to work well on Linux, and working on Windows is a
kludgy patch, which hurts the Windows ecosystem. I think Microsoft could
help the situation by publishing accurate numbers on things like system
activations, and the mix of systems connecting to system update. I can see
reasons to keep this info secret, but on the other hand, people will make up
the data if they don’t have real data. Curiously, Apple, a pretty secretive
company in general, has no problem making press announcement saying they
have shipped 2 million iPads. I actually have no idea how many copies of
Windows 2008 R2 server Microsoft has sold.

Jan

Calvin_Guan-3 · May 31, 2010, 4:28pm

But if the hardware is designed for PC systems, all one would care is some
big OEMs(counted by fingers in one hand), right? I’m more interested to know
how many non-windows PC systems these OEM would sell? I’m yet to see a
branded PC that “runs Linux” only.

Calvin

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Monday, May 31, 2010 12:10 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NDIS miniport SurpriseRemoval problem in win2k3

Having dependency between physical PCI functions violate the “Design
for
Windows” rule. Your hardware team shouldn’t have delivered such thing
in the
first place.

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.

This is partially because some hardware folks think Linux and Windows have
the same requirements (and OS is an OS), and since they can look at the
source code of Linux, they can figure out what these hardware requirements
are. Linux is becoming (or has become) the OS model hardware is frequently
designed around. I think this is also partially Microsoft’s fault, for not
having extensive easily available documentation about Windows hardware
requirements. I believe you can’t actually look at the WHQL specs unless you
sign up for a WHQL account, which is WAY down the path of some product
designs.

An example I just wrote about, if you design hardware with PCIe serial
number attributes in the extended config space, you can have a significant
boot image compatibility issue between identical machines. I don’t believe
this is even mentioned in the WHQL docs, and may only be learned when you
start shipping your product to Windows customers. Your Linux customers may
not have any issues.

I think another part of the problem is just a weird belief about what the
installed base of systems is. Here in Silicon Valley, a LOT of people seem
to think Linux has a way bigger market share on servers than Windows. The
assumption must be most corporations run their IT group like Goggle (which
does have like half a million Linux servers). As a result, they design
products based on the that belief, and some get rather rude introduced to
reality when they start shipping their product and find half or more of
their customers exclusively run Windows. The effect though is lots of
products get designed to work well on Linux, and working on Windows is a
kludgy patch, which hurts the Windows ecosystem. I think Microsoft could
help the situation by publishing accurate numbers on things like system
activations, and the mix of systems connecting to system update. I can see
reasons to keep this info secret, but on the other hand, people will make up
the data if they don’t have real data. Curiously, Apple, a pretty secretive
company in general, has no problem making press announcement saying they
have shipped 2 million iPads. I actually have no idea how many copies of
Windows 2008 R2 server Microsoft has sold.

Jan

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Pavel_A1 · May 31, 2010, 9:19pm

“Leonid Keller” wrote in message
news:xxxxx@ntdev…
…
> It works in Vista, but not in Windows 2003.
> As I revealed, Windows 2003 doesn’t start to perform Surprise Removal on
> PFs before it finishes the removing of PPF.
> (Despite they are independent devices from its point of view!)

Yes, in NT6, PnP is more parallelized than in NT5.
This is the progress

– pa

Pavel_A1 · May 31, 2010, 9:19pm

“Calvin Guan” wrote in message
news:xxxxx@ntdev…
> But if the hardware is designed for PC systems, all one would care is some
> big OEMs(counted by fingers in one hand), right? I’m more interested to
> know
> how many non-windows PC systems these OEM would sell? I’m yet to see a
> branded PC that “runs Linux” only.
>
> Calvin

Hmm… Rumors are, they will run PalmOS soon.

– pa

Leonid_Keller · June 1, 2010, 5:34am

Thank you for the ideas.
SB

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Monday, May 31, 2010 8:03 PM
Subject: Re: NDIS miniport SurpriseRemoval problem in win2k3

>But if one first removes PPF, the driver *must* first force removing
of all PFs, because they can’t work
>without PPF.

For me, switching them to the mode where they will fail everything
(though still present in the Device Manager) is OK.
[Leonid Keller] I do it really upon getting “RemoveItself” event from the primary device.
But I can’t make OS to remove them completely while the primary device is being removed.

Try playing with RemovalRelations.
[Leonid Keller] I don’t quite understand how it may help.
OS has already queued my Surprise Removal requests …
Maybe I didn’t understand your idea. Could you elaborate ?

Try restructure the bus driver so that the SFs will be the PnP
children (not siblings) of the PF.
[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.

Any ideas of how to track the leakage ?

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

Leonid_Keller · June 1, 2010, 6:38am

Thank you for the response.
See my comments inline.

-----Original Message-----
From: Calvin Guan [mailto:xxxxx@gradovec.com]
Sent: Monday, May 31, 2010 8:45 PM
Subject: RE: NDIS miniport SurpriseRemoval problem in win2k3

It certainly seems some reference leaks somewhere. The ba trick doesn’t
work
very well on NDIS miniport’s dev_obj because the stack and some OS WMI
junks
love to ref/deref it zillion of times. It can be done if you are
desperate
enough. For every bp hit, dump the callstack and go. Do this in a
“composite” command instead of hitting the keyboard. Well, it’s slow
and
painful and you have a lot of things to read.
[Leonid Keller] I tried it also. It’s right you tells - creates enormous output.

You may want to unbind all
protocols, intermediate drivers from your miniport to improve your SNR.

[Leonid Keller] I did it also. It doesn’t help.

From what you have said, it’s not clear to me if it has anything to do
with
your function dependency. I would try to run the test with all
secondary
physical function disabled to rule this in or out.
[Leonid Keller] I told about it in P.S.
“pnpdtest ‘SurpriseRemoval’”, being run on only one device, end up successfully, but marks mx4bus as “needed reboot”.
I don’t know, whether it is the same problem or a bug in test.
If someone from Microsoft could tell that the test is to work OK, then it would be very reasonable first to solve this problem. It’s much simpler: just one pair of mx4bus/mx4eth devices, no special mechanism like “RemoveItself” event.
And a standard test.
What annoys is, that mx4eth can be surprise-removed by the test any times.
Mx4bus, without mx4eth, - the same.
But when they are together (even with no protocols over mx4eth, I’ve unbound them from Network Connections), I get “need reboot” on mx4bus after the first run of the test.
Can you think of a way to investigate the problem ?
What are the reasons for the device node to get marked “need reboot” ?
BTW, ‘pnpdtest’ seems like has no idea about it. It passes OK.

Having dependency between physical PCI functions violate the “Design
for
Windows” rule. Your hardware team shouldn’t have delivered such thing
in the
first place. From end customer’s perspective, this is very frustrating,
say
I wanted to only disable port 0, but it disables 0,1,2,3,4,5,6,7 all
without
warning.
[Leonid Keller] I could have said that if the devices are independent, like they are from the OS point of view, OS has to remove them instantly without serializing. And why does pnpdtest fail on one device ? It seems like a bug in OS, but …
I honestly agree with your statement - the devices should be independent. But they are not for now.
Hopefully, they will be in the next chip.

If it has not been taped out, fix the RTL. If it has been shipped, fix
it in
the next revision. Function dependency should be dealt with in fw and
hw,
not Windows. There are many ways doing it.

Good luck,
Calvin

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Leonid Keller
Sent: Monday, May 31, 2010 9:54 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] NDIS miniport SurpriseRemoval problem in win2k3

I’d like to bother you once more with this problem, because I can’t
find
solution so far.
Here is the full story.
We have a HW device, which is handled by WDF bus driver mx4bus and its
child, NDIS miniport driver mx4eth.
The HW device can expose several functions, which - from OS’s point of
view

are fully independent.
But in fact only one of them is a primary function (PPF), all the rest
are
secondary ones (PF), which are dependent from PPF.
So for every HW function I have a pair of instances mx4bus/mx4eth,
handling
it.

If one first removes PFs (secondary devices) and then PPF (the primary
one)

all is OK.
But if one first removes PPF, the driver *must* first force removing of
all
PFs, because they can’t work without PPF.
That was the problem in the first place.
I solved it by sending an event “RemoveItself” to all PFs from PPF,
while
handling REMOVE_DEVICE IRP (for PPF).
I.e., PPF sends the events and waits for all PFs to exit.
PFs call WdfDeviceSetFailed and remove themselves.
Then PPF happily exits.

It works in Vista, but not in Windows 2003.
As I revealed, Windows 2003 doesn’t start to perform Surprise Removal
on PFs
before it finishes the removing of PPF.
(Despite they are independent devices from its point of view!)

Then I made another solution.
PFs release all the PPFs resources upon “RemoveItself” event and tells
it,
they’ve exited.
Then PPF successfully exits and OS starts the surprise removing of all
PFs.
Seems like it has to work. But it doesn’t.

What happens?
For some unclear reason, it always works the first time - all the
devices
get removed.
But if I enable/disable them all once more, all PFs get marked as
“Needed
reboot” in Device Manager (PPF is removed OK).

What I see in the debugger when it happens:

REMOVE_DEVICE IRP was handled in both drivers (Halt of mx4eth and
EvtReleaseHardware of mx4bus were called).

Ethernet devices are removed from the device tree (‘!devnode 0 1’ do
not
show them)

Neither Unload function is called, so both drivers are still in
memory.

!ndiskd.miniports doesn’t shows mx4eth of PFs, but
!ndiskd.gminiports
does.

!ndiskd.miniport <pf_mx4eth_device> shows no protocols, all counters
> are
> zeros, but it shows FDO and PDO.
> 6. !object on FDO shows PointerCount=2 (OK?), on PDO it shows
> PointerCount=3
> (leak?).
> 7. !devnode shows:
> State = DeviceNodeDeletePendingCloses (0x313)
> Previous State = DeviceNodeRemovePendingCloses (0x311)
> StateHistory[13] = DeviceNodeRemovePendingCloses (0x311)
> StateHistory[12] = DeviceNodeStarted (0x308)
> Flags (0x00000120) DNF_IDS_QUERIED, DNF_NO_RESOURCE_REQUIRED
> CapabilityFlags (0x00000a01) DeviceD1, SurpriseRemovalOK, WakeFromD1
>
> 8. !devnode of its “father” mx4bus shows:
> State = DeviceNodeRemovePendingCloses (0x311)
> Previous State = DeviceNodeStarted (0x308)
> StateHistory[13] = DeviceNodeStarted (0x308)
> Flags (0x00000030) DNF_ENUMERATED, DNF_IDS_QUERIED
> UserFlags (0x00000004) DNUF_NEED_RESTART
> CapabilityFlags (0x00000210) Removable, SurpriseRemovalOK
>
> 9. !object on its PDO shows PointerCount=4 (OK?)
> 10. ‘!devnode 1 1’ returns “Error reading pending relations list entry”
>
> My guess is, that PointerCount=3 (in 6.) is a leak, which causes all
> the
> problem.
> But I don’t know how to check it and don’t know how to find who made
> the
> leak.
> Vista has a facility of PointerCount tracing, but Windows 2003 -
> doesn’t,
> AFAIK.
>
> Can it be a bug in OS ?
> What’s the way to investigate the problem ?
> Is there any other solution for the entire problem ?
>
> Thank in advance.
>
> P.S.
> 1. mx4bus without mx4eth gets removed OK, so mx4eth is somehow
> “guilty”;
> 2. mx4eth can be removed with “pnpdtest ‘SurpriseRemoval’” without
> problem.
> 3. mx4bus get marked “Need reboot” after first running of “pnpdtest
> ‘SurpriseRemoval’”.
> Maybe there is a bug in pnpdtest, maybe it is the same problem as
> with
> surptise removal of PFs.
> The latter case is maybe simpler to investigate, because there is
> only
> one pair of mx4bus/mx4eth (only PPF).
> But how can I do it ?
> The test passes OK, but device node of mx4bus gets marked with
> DNUF_NEED_RESTART…
>
>
>
> > -----Original Message-----
> > From: Leonid Keller [mailto:xxxxx@mellanox.co.il]
> > Sent: Monday, May 24, 2010 8:43 PM
> > Subject: RE: NDIS miniport SurpriseRemoval problem in win2k3
> >
> > Thank you, David.
> >
> > I’ll try it, but I’m not too optimistic.
> > The problem is, that it get stuck somewhere between Halt and Unload.
> > I mean that both Halt routine of Ethernet driver and
> EvtReleaseHardware
> > of bus driver get called.
> > So, from both drivers’ point of view IRP_MN_REMOVE has been handled.
> > But neither Unload routine is not called.
> > Devnode of Ethernet driver is left in DeviceNodeRemovePendingCloses
> > state…
> > Device Manager tells “driver is still in memory. Make reboot”.
> >
> > > -----Original Message-----
> > > From: David R. Cattley [mailto:xxxxx@msn.com]
> > > Sent: Monday, May 24, 2010 6:43 AM
> > > Subject: RE: NDIS miniport SurpriseRemoval problem in win2k3
> > >
> > > Be sure to verify that all resources (packets, etc.) passed across
> > any
> > > active bindings have been properly returned as well. NDIS will not
> > > halt the
> > > adapter until all received packets indicated by the adapter have
> been
> > > returned by bound protocols and all packets sent from bound
> protocols
> > > have
> > > been completed by the adapter. A pending
> > Miniport{Set|Get}Information
> > > can
> > > also delay halt as it will also be a reference on the ‘open’
> > (binding).
> > >
> > > The !ndiskd extension can help in diagnosing such things. You
> might
> > > also
> > > try unbinding the adapter from everything (use BindView) and see if
> > > that
> > > changes the test result.
> > >
> > > Good Luck,
> > > Dave Cattley
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
> > > Sent: Sunday, May 23, 2010 7:36 PM
> > > To: Windows System Software Devs Interest List
> > > Subject: RE: [ntdev] NDIS miniport SurpriseRemoval problem in
> win2k3
> > >
> > > You get stuck in the surprise removed state when there is an open
> > > handle on
> > > the device that is not closed. !object on the fdo and pdo for the
> nic
> > > will
> > > give the handle count, !devnode 1 1 might give you more info on the
> > > orphaned
> > > devnode.
> > >
> > > d
> > >
> > > sent from a phpne with no keynoard
> > >
> > > -----Original Message-----
> > > From: Leonid Keller
> > > Sent: May 23, 2010 3:12 PM
> > > To: Windows System Software Devs Interest List
>
> > > Subject: [ntdev] NDIS miniport SurpriseRemoval problem in win2k3
> > >
> > >
> > > Hi All,
> > >
> > > We have a WDF bus driver, which creates as a child an NDIS miniport
> > > Ethernet
> > > adapter.
> > > When the bus driver Surprise Remove itself, it works the first
> time,
> > > but
> > > gets stuck the second time (after disable/enable the bus driver).
> > > DevNode of the Ethernet driver remains in SurpriseRemove state as
> if
> > it
> > > is
> > > waiting for releasing some resource.
> > > I run pnpdtest from WDK with “SurpriseRemove” option - the same
> > result:
> > > the
> > > first time the test passes, the second time it fails to attach the
> > > filter
> > > driver.
> > > All PnP staff in the bus driver is handled by WDF DLL, in the
> > Ethernet
> > > driver - by NDIS DLL.
> > > My question is: what’s the way to debug the problem ?
> > > (To remind: it happens in Windows 2003)
> > >
> > > Thank you.
> > >
> > > Leonid
> > >
> > >
> > > —
> > > NTDEV is sponsored by OSR
> > >
> > > For our schedule of WDF, WDM, debugging and other seminars visit:
> > > http://www.osr.com/seminars
> > >
> > > To unsubscribe, visit the List Server section of OSR Online at
> > > http://www.osronline.com/page.cfm?name=ListServer
> > >
> > >
> > > —
> > > NTDEV is sponsored by OSR
> > >
> > > For our schedule of WDF, WDM, debugging and other seminars visit:
> > > http://www.osr.com/seminars
> > >
> > > To unsubscribe, visit the List Server section of OSR Online at
> > > http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer</pf_mx4eth_device>

Maxim_S_Shatskih · June 1, 2010, 12:27pm

> But if the hardware is designed for PC systems, all one would care is some

big OEMs(counted by fingers in one hand), right?

Desktop PC market is not this monopolized, lots of PCs are assembled at the retail sales points from components. Actually, you buy a set of components and pay some additional money for the computer to be assembled.

In some parts of the world this method of desktop PC sales is dominant.

But yes, the motherboard determines everything in these PCs, and the MB market is the same monopolized as laptop market (Asus and Gigabyte are 2 major MB sellers).

As about the original topic - this is what occurs if the engineers are thinking about technical issues only and not marketing issues.

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

Maxim_S_Shatskih · June 1, 2010, 12:27pm

> Hmm… Rumors are, they will run PalmOS soon.

Is it still existing and not out of business?

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

Maxim_S_Shatskih · June 1, 2010, 12:32pm

>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

Calvin_Guan-3 · June 1, 2010, 12:36pm

>> “pnpdtest ‘SurpriseRemoval’”, being run on only one device, end up
successfully,

> but marks mx4bus as “needed reboot”.
> I don’t know, whether it is the same problem or a bug in test.
> If someone from Microsoft could tell that the test is to work OK,

[cguan] This is a smoking gun! I don’t work for MSFT but I’m *very* familiar
with pnptest in production and its in-house version. And I also have a bus
driver and miniports (storage and net) architecture. A successful run of
PNPtest never asks to reboot unless your driver is designed to “need a
reboot”, i.e. by marking it using a class/coinstaller.

> then it would be very reasonable first to solve this
> problem. It’s much simpler: just one pair of mx4bus/mx4eth devices,
> no special mechanism like “RemoveItself” event.
> And a standard test.

[cguan] I would certainly look after this first.

> What are the reasons for the device node to get marked “need reboot” ?

[cguan] It simply means there is(are) dangling device objects(s) and/or
driver object that prevents the driver image from being unmapped from system
memory.

> Can you think of a way to investigate the problem ?

[cguan] I would divide the problem into smaller pieces and hammer them in
the order on increasing complexity.

First, run PNPtest on the miniport. If it’s clear, then
Second, run the pnptest on the bus driver without enumerating any PDO (pure
FDO mode).
Third, run the pnptest on bus driver with eth PDO enumerated, but miniport
disable or not installing driver on it
Fourth, run the pnptest with bus and MP like what you are doing now.

The earlier it starts to fail, the easier you could fix it.

Good luck!
Calvin Guan
Broadcom Corp.
Connecting Everything(r)