WdfChildListUpdateChildDescriptionAsMissing generates IRP_MN_SURPRISE_REMOVAL

OSR_Community_User · January 14, 2008, 2:44pm

Hi folks,

Having fun with WDF Dynamic enumeration. I have a bus driver which
dynamically enumerates children. It all works fine, apart from one
little niggle - WdfChildListUpdateChildDescriptionAsMissing generates
surprise removals, which results in an “error” in the Event Log. Is
there any way to perform a more orderly “QueryRemove, then Remove”
process - I could probably expand / improve state machines in the bus
driver to handle a failed query, if only I could get the information back.

The nitty gritty:

If a child device is removed as a result of disabling the child in
device manager, we get a query removal, followed by a removal (In the
log “Child” = Bus driver PDO):

[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d4f608 (Child) Cmd: IRP_MN_QUERY_DEVICE_RELATIONS
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d4f608 (Child) Cmd: IRP_MN_QUERY_REMOVE_DEVICE
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d4f608 (Child) Cmd: IRP_MN_REMOVE_DEVICE

If the child device is removed as a result of the whole stack being torn
down because of disabling the parent FDO in device manager, we get the
following log, and an “error” in the system event log:

[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d88c68 (Child) Cmd: IRP_MN_QUERY_DEVICE_RELATIONS
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x77a56ff8 (Physical) Cmd: IRP_MN_QUERY_DEVICE_RELATIONS
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_COMPLETE: ERROR Dev: 0x77a56ff8 Cmd: IRP_MN_QUERY_DEVICE_RELATIONS Status: 0xc00000bb
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d88c68 (Child) Cmd: IRP_MN_QUERY_REMOVE_DEVICE
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x77a56ff8 (Physical) Cmd: IRP_MN_QUERY_REMOVE_DEVICE
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_COMPLETE: SUCCESS Dev: 0x77a56ff8 Cmd: IRP_MN_QUERY_REMOVE_DEVICE Status: 0x2
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d88c68 (Child) Cmd: IRP_MN_REMOVE_DEVICE
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x77a56ff8 (Physical) Cmd: IRP_MN_REMOVE_DEVICE
…
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_COMPLETE: SUCCESS Dev: 0x77a56ff8 Cmd: IRP_MN_REMOVE_DEVICE Status: 0x2

However, if we call WdfChildListUpdateChildDescriptionAsMissing, then we
get:

[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x77aebd30 (Singleton) Cmd: IRP_MN_QUERY_DEVICE_RELATIONS
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_COMPLETE: SUCCESS Dev: 0x77aebd30 Cmd: IRP_MN_QUERY_DEVICE_RELATIONS Status: 0x2
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d4f608 (Child) Cmd: IRP_MN_QUERY_DEVICE_RELATIONS
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d4f608 (Child) Cmd: IRP_MN_QUERY_DEVICE_RELATIONS
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d4f608 (Child) Cmd: IRP_MN_SURPRISE_REMOVAL
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d4f608 (Child) Cmd: IRP_MN_REMOVE_DEVICE

The event log then contains:

The device ‘Solarflare Virtual Adapter’ ({C641C770-FAAC-44ED-9C73-48D1B5E59200}\NDIS_VIRTUAL\PG_ID_V_1_NA_ID_1) disappeared from the system without first being prepared for removal.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Any way of doing a cleaner removal, or getting rid of the error would be nice.

MH.

OSR_Community_User · January 14, 2008, 3:05pm

Martin Harvey wrote:

Having fun with WDF Dynamic enumeration. I have a bus driver which
dynamically enumerates children. It all works fine, apart from one
little niggle - WdfChildListUpdateChildDescriptionAsMissing generates
surprise removals, which results in an “error” in the Event Log. Is
there any way to perform a more orderly “QueryRemove, then Remove”
process - I could probably expand / improve state machines in the bus
driver to handle a failed query, if only I could get the information
back.

I should mention, that I’m aware the answer is in
WDF_DEVICE_PNP_CAPABILITIES, however, I can’t find the magic combination
that will force a “slow” remove without putting my child devices in the
“safely remove hardware” GUI box, which is definitely_not what I want.

MH.

Doron_Holan · January 14, 2008, 3:33pm

Yes, this is by design. No, there is no way for a driver to initiate a graceful remove on itself or one of its PDOs. How about marking your PDO as SurpriseRemovalOK with WdfDeviceSetPnpCapabilities right after you create it? you are surprise removing a device which is not marked as such which is why the OS is putting something into the log.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Martin Harvey
Sent: Monday, January 14, 2008 11:43 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] WdfChildListUpdateChildDescriptionAsMissing generates IRP_MN_SURPRISE_REMOVAL

Hi folks,

Having fun with WDF Dynamic enumeration. I have a bus driver which
dynamically enumerates children. It all works fine, apart from one
little niggle - WdfChildListUpdateChildDescriptionAsMissing generates
surprise removals, which results in an “error” in the Event Log. Is
there any way to perform a more orderly “QueryRemove, then Remove”
process - I could probably expand / improve state machines in the bus
driver to handle a failed query, if only I could get the information back.

The nitty gritty:

If a child device is removed as a result of disabling the child in
device manager, we get a query removal, followed by a removal (In the
log “Child” = Bus driver PDO):

[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d4f608 (Child) Cmd: IRP_MN_QUERY_DEVICE_RELATIONS
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d4f608 (Child) Cmd: IRP_MN_QUERY_REMOVE_DEVICE
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d4f608 (Child) Cmd: IRP_MN_REMOVE_DEVICE

If the child device is removed as a result of the whole stack being torn
down because of disabling the parent FDO in device manager, we get the
following log, and an “error” in the system event log:

[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d88c68 (Child) Cmd: IRP_MN_QUERY_DEVICE_RELATIONS
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x77a56ff8 (Physical) Cmd: IRP_MN_QUERY_DEVICE_RELATIONS
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_COMPLETE: ERROR Dev: 0x77a56ff8 Cmd: IRP_MN_QUERY_DEVICE_RELATIONS Status: 0xc00000bb
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d88c68 (Child) Cmd: IRP_MN_QUERY_REMOVE_DEVICE
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x77a56ff8 (Physical) Cmd: IRP_MN_QUERY_REMOVE_DEVICE
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_COMPLETE: SUCCESS Dev: 0x77a56ff8 Cmd: IRP_MN_QUERY_REMOVE_DEVICE Status: 0x2
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d88c68 (Child) Cmd: IRP_MN_REMOVE_DEVICE
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x77a56ff8 (Physical) Cmd: IRP_MN_REMOVE_DEVICE
…
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_COMPLETE: SUCCESS Dev: 0x77a56ff8 Cmd: IRP_MN_REMOVE_DEVICE Status: 0x2

However, if we call WdfChildListUpdateChildDescriptionAsMissing, then we
get:

[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x77aebd30 (Singleton) Cmd: IRP_MN_QUERY_DEVICE_RELATIONS
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_COMPLETE: SUCCESS Dev: 0x77aebd30 Cmd: IRP_MN_QUERY_DEVICE_RELATIONS Status: 0x2
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d4f608 (Child) Cmd: IRP_MN_QUERY_DEVICE_RELATIONS
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d4f608 (Child) Cmd: IRP_MN_QUERY_DEVICE_RELATIONS
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d4f608 (Child) Cmd: IRP_MN_SURPRISE_REMOVAL
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d4f608 (Child) Cmd: IRP_MN_REMOVE_DEVICE

The event log then contains:

The device ‘Solarflare Virtual Adapter’ ({C641C770-FAAC-44ED-9C73-48D1B5E59200}\NDIS_VIRTUAL\PG_ID_V_1_NA_ID_1) disappeared from the system without first being prepared for removal.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Any way of doing a cleaner removal, or getting rid of the error would be nice.

MH.

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

Doron_Holan · January 14, 2008, 4:12pm

If you mark your pdo as surprise removal OK you do not show up in the safely remove hw box and surprise removal does not log an event.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Martin Harvey
Sent: Monday, January 14, 2008 12:05 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WdfChildListUpdateChildDescriptionAsMissing generates IRP_MN_SURPRISE_REMOVAL

Martin Harvey wrote:

Having fun with WDF Dynamic enumeration. I have a bus driver which
dynamically enumerates children. It all works fine, apart from one
little niggle - WdfChildListUpdateChildDescriptionAsMissing generates
surprise removals, which results in an “error” in the Event Log. Is
there any way to perform a more orderly “QueryRemove, then Remove”
process - I could probably expand / improve state machines in the bus
driver to handle a failed query, if only I could get the information
back.

I should mention, that I’m aware the answer is in
WDF_DEVICE_PNP_CAPABILITIES, however, I can’t find the magic combination
that will force a “slow” remove without putting my child devices in the
“safely remove hardware” GUI box, which is definitely_not what I want.

MH.

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

Maxim_S_Shatskih · January 14, 2008, 4:20pm

>Yes, this is by design. No, there is no way for a driver to initiate a
graceful remove

on itself or one of its PDOs.

Is there any WDF wrapper for IoInvalidateDeviceState?

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

Jonathan_Ludwig · January 14, 2008, 4:47pm

Doron,

This actually relates to questions I have that I don’t fully understand
about KMDF’s default PnP handling code. When my device gets a surprise
remove IRP, does the framework clean out my I/O queues for me? What
about manual dispatch queues? Do I need to synchronize surprise removal
with any code in my driver? My hardware isn’t real anyway and my FDO
implements the virtual hardware anyway. Can I assume that KMDF will
tear down my FDO in response to the surprise remove so I don’t have to
handle the device tear down because of surprise remove specially?

I just read this post, looked at my system event log and noticed the
surprise remove error logs. Id’ like to work around this too. In my
case I may just take the removable device in the safely remove hardware
list. That’s not the big a deal to me. That’s how I first implemented
my bus driver anyway. I would still prefer for them not to show up there.

Thanks,

Jonathan

Doron Holan wrote:

If you mark your pdo as surprise removal OK you do not show up in the safely remove hw box and surprise removal does not log an event.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Martin Harvey
Sent: Monday, January 14, 2008 12:05 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WdfChildListUpdateChildDescriptionAsMissing generates IRP_MN_SURPRISE_REMOVAL

Martin Harvey wrote:

> Having fun with WDF Dynamic enumeration. I have a bus driver which
> dynamically enumerates children. It all works fine, apart from one
> little niggle - WdfChildListUpdateChildDescriptionAsMissing generates
> surprise removals, which results in an “error” in the Event Log. Is
> there any way to perform a more orderly “QueryRemove, then Remove”
> process - I could probably expand / improve state machines in the bus
> driver to handle a failed query, if only I could get the information
> back.
>
I should mention, that I’m aware the answer is in
WDF_DEVICE_PNP_CAPABILITIES, however, I can’t find the magic combination
that will force a “slow” remove without putting my child devices in the
“safely remove hardware” GUI box, which is definitely_not what I want.

MH.

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

OSR_Community_User · January 14, 2008, 4:49pm

There is no way to trigger an “orderly removal” (query-remove/remove) from your driver. However if you set the “surprise removal okay” flag in your PDO’s capabilities and the event log entry should go away when the device is surprise removed.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Martin Harvey
Sent: Monday, January 14, 2008 11:43 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] WdfChildListUpdateChildDescriptionAsMissing generates IRP_MN_SURPRISE_REMOVAL

Hi folks,

Having fun with WDF Dynamic enumeration. I have a bus driver which
dynamically enumerates children. It all works fine, apart from one
little niggle - WdfChildListUpdateChildDescriptionAsMissing generates
surprise removals, which results in an “error” in the Event Log. Is
there any way to perform a more orderly “QueryRemove, then Remove”
process - I could probably expand / improve state machines in the bus
driver to handle a failed query, if only I could get the information back.

The nitty gritty:

If a child device is removed as a result of disabling the child in
device manager, we get a query removal, followed by a removal (In the
log “Child” = Bus driver PDO):

[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d4f608 (Child) Cmd: IRP_MN_QUERY_DEVICE_RELATIONS
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d4f608 (Child) Cmd: IRP_MN_QUERY_REMOVE_DEVICE
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d4f608 (Child) Cmd: IRP_MN_REMOVE_DEVICE

If the child device is removed as a result of the whole stack being torn
down because of disabling the parent FDO in device manager, we get the
following log, and an “error” in the system event log:

[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d88c68 (Child) Cmd: IRP_MN_QUERY_DEVICE_RELATIONS
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x77a56ff8 (Physical) Cmd: IRP_MN_QUERY_DEVICE_RELATIONS
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_COMPLETE: ERROR Dev: 0x77a56ff8 Cmd: IRP_MN_QUERY_DEVICE_RELATIONS Status: 0xc00000bb
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d88c68 (Child) Cmd: IRP_MN_QUERY_REMOVE_DEVICE
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x77a56ff8 (Physical) Cmd: IRP_MN_QUERY_REMOVE_DEVICE
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_COMPLETE: SUCCESS Dev: 0x77a56ff8 Cmd: IRP_MN_QUERY_REMOVE_DEVICE Status: 0x2
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d88c68 (Child) Cmd: IRP_MN_REMOVE_DEVICE
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x77a56ff8 (Physical) Cmd: IRP_MN_REMOVE_DEVICE
…
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_COMPLETE: SUCCESS Dev: 0x77a56ff8 Cmd: IRP_MN_REMOVE_DEVICE Status: 0x2

However, if we call WdfChildListUpdateChildDescriptionAsMissing, then we
get:

[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x77aebd30 (Singleton) Cmd: IRP_MN_QUERY_DEVICE_RELATIONS
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_COMPLETE: SUCCESS Dev: 0x77aebd30 Cmd: IRP_MN_QUERY_DEVICE_RELATIONS Status: 0x2
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d4f608 (Child) Cmd: IRP_MN_QUERY_DEVICE_RELATIONS
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d4f608 (Child) Cmd: IRP_MN_QUERY_DEVICE_RELATIONS
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d4f608 (Child) Cmd: IRP_MN_SURPRISE_REMOVAL
[sfcbus] BusDriverPrintPnPIrpDetails: PNP_IRP_START: Dev: 0x78d4f608 (Child) Cmd: IRP_MN_REMOVE_DEVICE

The event log then contains:

The device ‘Solarflare Virtual Adapter’ ({C641C770-FAAC-44ED-9C73-48D1B5E59200}\NDIS_VIRTUAL\PG_ID_V_1_NA_ID_1) disappeared from the system without first being prepared for removal.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Any way of doing a cleaner removal, or getting rid of the error would be nice.

MH.

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

Doron_Holan · January 14, 2008, 5:16pm

Yes, WdfDeviceSetDeviceState() … and any of the states you set that can affect pnp state (Removed, Failed, Disabled) will not result in a graceful (query remove->remove) of the pnp stack.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Monday, January 14, 2008 1:20 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WdfChildListUpdateChildDescriptionAsMissing generates IRP_MN_SURPRISE_REMOVAL

Yes, this is by design. No, there is no way for a driver to initiate a
graceful remove
on itself or one of its PDOs.

Is there any WDF wrapper for IoInvalidateDeviceState?

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

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

Doron_Holan · January 14, 2008, 6:23pm

Kmdf handles surprise removal for you, you should not have to track this state at all (virtual hardware or real hardware). On a surprise removal, KMDF will purge all power managed queues. When the final remove comes, it will purge all non power managed queues. In a graceful remove, these 2 steps follow one another immediately, while there may be a (lengthy) delay between them on surprise remove.

If you do not want your devices to be in the “Safe removal” UI, mark them as surprise removal OK in the PDO code of your bus driver or in the FDO that you load on your bus’s PDOs

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jonathan Ludwig
Sent: Monday, January 14, 2008 1:47 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WdfChildListUpdateChildDescriptionAsMissing generates IRP_MN_SURPRISE_REMOVAL

Doron,

This actually relates to questions I have that I don’t fully understand
about KMDF’s default PnP handling code. When my device gets a surprise
remove IRP, does the framework clean out my I/O queues for me? What
about manual dispatch queues? Do I need to synchronize surprise removal
with any code in my driver? My hardware isn’t real anyway and my FDO
implements the virtual hardware anyway. Can I assume that KMDF will
tear down my FDO in response to the surprise remove so I don’t have to
handle the device tear down because of surprise remove specially?

I just read this post, looked at my system event log and noticed the
surprise remove error logs. Id’ like to work around this too. In my
case I may just take the removable device in the safely remove hardware
list. That’s not the big a deal to me. That’s how I first implemented
my bus driver anyway. I would still prefer for them not to show up there.

Thanks,

Jonathan

Doron Holan wrote:

If you mark your pdo as surprise removal OK you do not show up in the safely remove hw box and surprise removal does not log an event.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Martin Harvey
Sent: Monday, January 14, 2008 12:05 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WdfChildListUpdateChildDescriptionAsMissing generates IRP_MN_SURPRISE_REMOVAL

Martin Harvey wrote:

> Having fun with WDF Dynamic enumeration. I have a bus driver which
> dynamically enumerates children. It all works fine, apart from one
> little niggle - WdfChildListUpdateChildDescriptionAsMissing generates
> surprise removals, which results in an “error” in the Event Log. Is
> there any way to perform a more orderly “QueryRemove, then Remove”
> process - I could probably expand / improve state machines in the bus
> driver to handle a failed query, if only I could get the information
> back.
>
I should mention, that I’m aware the answer is in
WDF_DEVICE_PNP_CAPABILITIES, however, I can’t find the magic combination
that will force a “slow” remove without putting my child devices in the
“safely remove hardware” GUI box, which is definitely_not what I want.

MH.

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

OSR_Community_User · January 14, 2008, 7:00pm

Doron Holan wrote:

If you mark your pdo as surprise removal OK you do not show up in the safely remove hw box and surprise removal does not log an event.

Ah. Well that’s what I’m currently doing, and it seems not to have the
desired effect. Perhaps I want to set Removable to WdfTrue? Well …
I’ll give that a try tomorrow (it’s late!).

O.S. is:

Windows Server 2003 Kernel Version 3790 (Service Pack 2) MP (2 procs)
Free x86 compatible
Product: Server, suite: TerminalServer SingleUserTS
Built by: 3790.srv03_sp2_gdr.070304-2240

Code is:

…

status = WdfDeviceCreate(&ChildInit, &PdoAttributes, &Child);
if (!NT_SUCCESS(status)) {
…
}

…

WDF_DEVICE_PNP_CAPABILITIES_INIT(&PnpCaps);
PnpCaps.Removable = WdfFalse;
PnpCaps.EjectSupported = WdfFalse;
PnpCaps.SurpriseRemovalOK = WdfTrue;
PnpCaps.SilentInstall = WdfTrue;
/* Instance ID’s generated by the teaming module are now strings that
should be system wide unique (concat of PG id and NA id) */
PnpCaps.UniqueID = WdfTrue;

PnpCaps.Address = -1;
PnpCaps.UINumber = -1;

WdfDeviceSetPnpCapabilities(Child, &PnpCaps);

WDF_DEVICE_POWER_CAPABILITIES_INIT(&PowerCaps);

PowerCaps.DeviceD1 = WdfTrue;
PowerCaps.WakeFromD1 = WdfTrue;
PowerCaps.DeviceWake = PowerDeviceD1;

PowerCaps.DeviceState[PowerSystemWorking] = PowerDeviceD0;
PowerCaps.DeviceState[PowerSystemSleeping1] = PowerDeviceD1;
PowerCaps.DeviceState[PowerSystemSleeping2] = PowerDeviceD3;
PowerCaps.DeviceState[PowerSystemSleeping3] = PowerDeviceD3;
PowerCaps.DeviceState[PowerSystemHibernate] = PowerDeviceD3;
PowerCaps.DeviceState[PowerSystemShutdown] = PowerDeviceD3;

WdfDeviceSetPowerCapabilities(Child, &PowerCaps);

David_R_Cattley · January 14, 2008, 10:54pm

Is this true only in XP & later? I had a similar issue with a bus driver
that was to target W2KSP4 & later and I could not make the surprise removal
notification go away. I eventually added code to disable in the usermode
components to work around this by disabling the devnode before the (sofware
action of) removing the device.

did I miss some facilitiy in KMDF’s PDO support? i surely set the flag that
surprise removal was OK (it worked just fine in XP & later).

-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, January 14, 2008 4:10 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] WdfChildListUpdateChildDescriptionAsMissing
generates IRP_MN_SURPRISE_REMOVAL

If you mark your pdo as surprise removal OK you do not show up in the safely
remove hw box and surprise removal does not log an event.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin Harvey
Sent: Monday, January 14, 2008 12:05 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WdfChildListUpdateChildDescriptionAsMissing generates
IRP_MN_SURPRISE_REMOVAL

Martin Harvey wrote:

Having fun with WDF Dynamic enumeration. I have a bus driver which
dynamically enumerates children. It all works fine, apart from one
little niggle - WdfChildListUpdateChildDescriptionAsMissing generates
surprise removals, which results in an “error” in the Event Log. Is
there any way to perform a more orderly “QueryRemove, then Remove”
process - I could probably expand / improve state machines in the bus
driver to handle a failed query, if only I could get the information
back.

I should mention, that I’m aware the answer is in
WDF_DEVICE_PNP_CAPABILITIES, however, I can’t find the magic combination
that will force a “slow” remove without putting my child devices in the
“safely remove hardware” GUI box, which is definitely_not what I want.

MH.

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

Doron_Holan · January 14, 2008, 11:45pm

Remember that while you can set properties in a PDO, the FDO layered on your bus’s PDO can set/clear any properties the PDO sets/clears, e.g. the FDO can undo anything the PDO does in terms of these properties. For any device which you *think* should not be in the dialog, open up device manager, open up the properties for the device, goto the details tab and view the capabilities. What are the reported caps?

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Monday, January 14, 2008 7:53 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] WdfChildListUpdateChildDescriptionAsMissing generates IRP_MN_SURPRISE_REMOVAL

Is this true only in XP & later? I had a similar issue with a bus driver
that was to target W2KSP4 & later and I could not make the surprise removal
notification go away. I eventually added code to disable in the usermode
components to work around this by disabling the devnode before the (sofware
action of) removing the device.

did I miss some facilitiy in KMDF’s PDO support? i surely set the flag that
surprise removal was OK (it worked just fine in XP & later).

-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, January 14, 2008 4:10 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] WdfChildListUpdateChildDescriptionAsMissing
generates IRP_MN_SURPRISE_REMOVAL

If you mark your pdo as surprise removal OK you do not show up in the safely
remove hw box and surprise removal does not log an event.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin Harvey
Sent: Monday, January 14, 2008 12:05 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WdfChildListUpdateChildDescriptionAsMissing generates
IRP_MN_SURPRISE_REMOVAL

Martin Harvey wrote:

Having fun with WDF Dynamic enumeration. I have a bus driver which
dynamically enumerates children. It all works fine, apart from one
little niggle - WdfChildListUpdateChildDescriptionAsMissing generates
surprise removals, which results in an “error” in the Event Log. Is
there any way to perform a more orderly “QueryRemove, then Remove”
process - I could probably expand / improve state machines in the bus
driver to handle a failed query, if only I could get the information
back.

I should mention, that I’m aware the answer is in
WDF_DEVICE_PNP_CAPABILITIES, however, I can’t find the magic combination
that will force a “slow” remove without putting my child devices in the
“safely remove hardware” GUI box, which is definitely_not what I want.

MH.

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

David_R_Cattley · January 15, 2008, 7:40am

Doron,

Thanks for the reply. The FDO is an NDIS Miniport. It looks like KB298504
implies that NDIS (W2K) does not want to play along and allow a surprise
remove on a miniport since AFAIK NDIS_ATTRIBUTE_SURPRISE_REMOVE_OK for a
miniport is supported in XP+ only.

I did not try an upper filter to modify the
IPR_MJ_PNP/IRP_MN_QUERY_CAPABILITIES result ‘above’ NDIS.

-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, January 14, 2008 11:42 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] WdfChildListUpdateChildDescriptionAsMissing
generates IRP_MN_SURPRISE_REMOVAL

Remember that while you can set properties in a PDO, the FDO layered on your
bus’s PDO can set/clear any properties the PDO sets/clears, e.g. the FDO can
undo anything the PDO does in terms of these properties. For any device
which you *think* should not be in the dialog, open up device manager, open
up the properties for the device, goto the details tab and view the
capabilities. What are the reported caps?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Monday, January 14, 2008 7:53 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] WdfChildListUpdateChildDescriptionAsMissing
generates IRP_MN_SURPRISE_REMOVAL

Is this true only in XP & later? I had a similar issue with a bus driver
that was to target W2KSP4 & later and I could not make the surprise removal
notification go away. I eventually added code to disable in the usermode
components to work around this by disabling the devnode before the (sofware
action of) removing the device.

did I miss some facilitiy in KMDF’s PDO support? i surely set the flag that
surprise removal was OK (it worked just fine in XP & later).

-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, January 14, 2008 4:10 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] WdfChildListUpdateChildDescriptionAsMissing
generates IRP_MN_SURPRISE_REMOVAL

If you mark your pdo as surprise removal OK you do not show up in the safely
remove hw box and surprise removal does not log an event.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin Harvey
Sent: Monday, January 14, 2008 12:05 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WdfChildListUpdateChildDescriptionAsMissing generates
IRP_MN_SURPRISE_REMOVAL

Martin Harvey wrote:

Having fun with WDF Dynamic enumeration. I have a bus driver which
dynamically enumerates children. It all works fine, apart from one
little niggle - WdfChildListUpdateChildDescriptionAsMissing generates
surprise removals, which results in an “error” in the Event Log. Is
there any way to perform a more orderly “QueryRemove, then Remove”
process - I could probably expand / improve state machines in the bus
driver to handle a failed query, if only I could get the information
back.

I should mention, that I’m aware the answer is in
WDF_DEVICE_PNP_CAPABILITIES, however, I can’t find the magic combination
that will force a “slow” remove without putting my child devices in the
“safely remove hardware” GUI box, which is definitely_not what I want.

MH.

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

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

OSR_Community_User · January 15, 2008, 7:50am

Doron Holan wrote:

Remember that while you can set properties in a PDO, the FDO layered on your bus’s PDO can set/clear any properties the PDO sets/clears,

In my case, appropriate flags to NdisMSetMiniportAttributes sorted the
problem. Many thanks!

MH.

Doron_Holan · January 15, 2008, 4:58pm

Btw, writing such a filter (to be above NDIS and make sure the surprise removal OK bit is set) in KMDF is less than a page of code

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Tuesday, January 15, 2008 4:40 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] WdfChildListUpdateChildDescriptionAsMissing generates IRP_MN_SURPRISE_REMOVAL

Doron,

Thanks for the reply. The FDO is an NDIS Miniport. It looks like KB298504
implies that NDIS (W2K) does not want to play along and allow a surprise
remove on a miniport since AFAIK NDIS_ATTRIBUTE_SURPRISE_REMOVE_OK for a
miniport is supported in XP+ only.

I did not try an upper filter to modify the
IPR_MJ_PNP/IRP_MN_QUERY_CAPABILITIES result ‘above’ NDIS.

-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, January 14, 2008 11:42 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] WdfChildListUpdateChildDescriptionAsMissing
generates IRP_MN_SURPRISE_REMOVAL

Remember that while you can set properties in a PDO, the FDO layered on your
bus’s PDO can set/clear any properties the PDO sets/clears, e.g. the FDO can
undo anything the PDO does in terms of these properties. For any device
which you *think* should not be in the dialog, open up device manager, open
up the properties for the device, goto the details tab and view the
capabilities. What are the reported caps?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Monday, January 14, 2008 7:53 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] WdfChildListUpdateChildDescriptionAsMissing
generates IRP_MN_SURPRISE_REMOVAL

Is this true only in XP & later? I had a similar issue with a bus driver
that was to target W2KSP4 & later and I could not make the surprise removal
notification go away. I eventually added code to disable in the usermode
components to work around this by disabling the devnode before the (sofware
action of) removing the device.

did I miss some facilitiy in KMDF’s PDO support? i surely set the flag that
surprise removal was OK (it worked just fine in XP & later).

-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, January 14, 2008 4:10 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] WdfChildListUpdateChildDescriptionAsMissing
generates IRP_MN_SURPRISE_REMOVAL

If you mark your pdo as surprise removal OK you do not show up in the safely
remove hw box and surprise removal does not log an event.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin Harvey
Sent: Monday, January 14, 2008 12:05 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WdfChildListUpdateChildDescriptionAsMissing generates
IRP_MN_SURPRISE_REMOVAL

Martin Harvey wrote:

Having fun with WDF Dynamic enumeration. I have a bus driver which
dynamically enumerates children. It all works fine, apart from one
little niggle - WdfChildListUpdateChildDescriptionAsMissing generates
surprise removals, which results in an “error” in the Event Log. Is
there any way to perform a more orderly “QueryRemove, then Remove”
process - I could probably expand / improve state machines in the bus
driver to handle a failed query, if only I could get the information
back.

I should mention, that I’m aware the answer is in
WDF_DEVICE_PNP_CAPABILITIES, however, I can’t find the magic combination
that will force a “slow” remove without putting my child devices in the
“safely remove hardware” GUI box, which is definitely_not what I want.

MH.

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

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