Query about WdfChildListUpdateChildDescriptionAsMissing

NTDEV
1

Hi folks,

Simple query about WdfChildListUpdateChildDescriptionAsMissing. In some
cases it returns STATUS_WDF_DEVICE_NOT_CREATED.

Looks to me that this is in order to handle set-up/tear-down races,
which is exactly what I’m currently trying to do, however I need to
check my assumptions are right:

Is it correct that in the case of the return code
STATUS_WDF_DEVICE_NOT_CREATED, then I’ll *never* get the EvtDeviceAdd
for the PDO? i.e. I’ve managed to “catch” the enumeration process early
enough that that device will not be enumerated?

Conversely is it correct that if I *don’t* get
STATUS_WDF_DEVICE_NOT_CREATED, but some other NT_SUCCESS() code, then I
*will* get the EvtDeviceAdd, even if I have *not yet* had it.

So if I have some “management code” that wants to do a blocking teardown
of some PDO:

  1. If EvtDeviceAdd has been called, then I can wait on an Event that I
    set either in EvtCleanupCallback or EvtDestroyCallback.
  2. If EvtDeviceAdd has not been called but the status is
    STATUS_WDF_DEVICE_NOT_CREATED, then I don’t need to wait.
  3. If EvtDeviceAdd has not been called, but the status is not
    STATUS_WDF_DEVICE_NOT_CREATED, then I need to either:
    a) Fail EvtDeviceAdd, which is not my preferred option.
    b) Wait for EvtDeviceAdd to be called, and then subsequently Wait
    for the EvtCleanupCallback or EvtDestroyCallback to be called on that
    PDO - it’ll be created and then destroyed.

MH.

2

If STATUS_WDF_DEVICE_NOT_CREATED is returned, yes, the PDO was never
created, will never be created and it has ceased to exist in the list of
devices to create. If you get NT_SUCCESS, the start of the long process
of tearing down a PDO will start.

BUT, I strongly *strongly* encourage you not to block and wait for the
PDO to get removed. A ton of things could prevent that from happening
in a timely manner or at all. For instance, an application which does
not release its handle to the PDOs stack will keep the PDO in a surprise
removed (but not removed) state. EvtCleanupCallack only occurs in the
removed state. Why do you need to know when the PDO is actually
deleted?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin Harvey
Sent: Wednesday, July 18, 2007 9:12 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Query about WdfChildListUpdateChildDescriptionAsMissing

Hi folks,

Simple query about WdfChildListUpdateChildDescriptionAsMissing. In some
cases it returns STATUS_WDF_DEVICE_NOT_CREATED.

Looks to me that this is in order to handle set-up/tear-down races,
which is exactly what I’m currently trying to do, however I need to
check my assumptions are right:

Is it correct that in the case of the return code
STATUS_WDF_DEVICE_NOT_CREATED, then I’ll *never* get the EvtDeviceAdd
for the PDO? i.e. I’ve managed to “catch” the enumeration process early
enough that that device will not be enumerated?

Conversely is it correct that if I *don’t* get
STATUS_WDF_DEVICE_NOT_CREATED, but some other NT_SUCCESS() code, then I
*will* get the EvtDeviceAdd, even if I have *not yet* had it.

So if I have some “management code” that wants to do a blocking teardown

of some PDO:

  1. If EvtDeviceAdd has been called, then I can wait on an Event that I
    set either in EvtCleanupCallback or EvtDestroyCallback.
  2. If EvtDeviceAdd has not been called but the status is
    STATUS_WDF_DEVICE_NOT_CREATED, then I don’t need to wait.
  3. If EvtDeviceAdd has not been called, but the status is not
    STATUS_WDF_DEVICE_NOT_CREATED, then I need to either:
    a) Fail EvtDeviceAdd, which is not my preferred option.
    b) Wait for EvtDeviceAdd to be called, and then subsequently Wait
    for the EvtCleanupCallback or EvtDestroyCallback to be called on that
    PDO - it’ll be created and then destroyed.

MH.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

3

Martin-

>
Simple query about WdfChildListUpdateChildDescriptionAsMissing. In some
cases it returns STATUS_WDF_DEVICE_NOT_CREATED.
<<

This is a doc error (I’m filing a bug to that effect]. That status code does not exist [it isn’t even defined].

It probably existed in 1.0, but I’m pretty sure from the date of the change (October 2005) that removed it that it’s been gone since then. It appears that when it did exist, it was not reliable [not all potential races were detected].

The rest I’ll leave to someone else- I don’t know all the potential races well enough to hazard an opinion.

4

Ah, now I remember. Bob, thx for clarifying. STATUS_NO_SUCH_DEVICE is
returned when the PDO being reported as missing is not in the list,
STATUS_SUCCESS is returned in all other cases (reported as missing+pdo
created or reported as missing+pdo not created). Essentially you cannot
distinguish between any of these cases. This goes back to why I think
it is a bad idea to wait for the pnp change. The reported state of the
pdo is by its very nature asynchronous and you should not block on it
happening based on state

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bob Kjelgaard
Sent: Wednesday, July 18, 2007 10:54 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Query about
WdfChildListUpdateChildDescriptionAsMissing

Martin-

>
Simple query about WdfChildListUpdateChildDescriptionAsMissing. In some
cases it returns STATUS_WDF_DEVICE_NOT_CREATED.
<<

This is a doc error (I’m filing a bug to that effect]. That status code
does not exist [it isn’t even defined].

It probably existed in 1.0, but I’m pretty sure from the date of the
change (October 2005) that removed it that it’s been gone since then.
It appears that when it did exist, it was not reliable [not all
potential races were detected].

The rest I’ll leave to someone else- I don’t know all the potential
races well enough to hazard an opinion.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

5

Doron Holan wrote:

BUT, I strongly *strongly* encourage you not to block and wait for the
PDO to get removed. A ton of things could prevent that from happening
in a timely manner or at all. For instance, an application which does
not release its handle to the PDOs stack will keep the PDO in a surprise
removed (but not removed) state. EvtCleanupCallack only occurs in the
removed state. Why do you need to know when the PDO is actually
deleted?

Well, to be fair, the blocking behaviour is not particularly for “my”
benefit:

I agree the way most of the kernel works is asynchronous and event
based, and it’s better to leave data in memory than to block threads in
the kernel which may never get unblocked.

At the moment, the blocking behaviour is simply to handle a cleanup case
where I have:

Datastructure X
^ (1)
|
v (*)
Datastructure Y (contains WDF_CHILD_IDENTIFICATION_DESCRIPTION_HEADER)
^ (1)
|
v (0 or 1)
PDO

There are some cases where I want to clean up a datastructure X, which
involves getting rid of a whole bunch of Y’s which involves ripping down
lots of PDO’s.

Really I have the blocking behaviour for 2 reasons:

  1. It “looks” like the code is easier (although I’m coming slowly to the
    conclusion that this is not true, and ref-counts are better).
  2. It means that for people interacting with the driver via WMI, they
    can do various sorts of cleanup operation in a blocking manner, and
    don’t need to deal with transient (or not so transient) destroying
    states. Having said that I can get around this by allowing the transient
    destroying states, and then changing the way external WMI queries “see”
    my internal objects.

MH.

6

I personally would use ref counts. It makes things much easier to deal
with and there should be no blocking involved.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin Harvey
Sent: Friday, July 20, 2007 3:50 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Query about
WdfChildListUpdateChildDescriptionAsMissing

Doron Holan wrote:

BUT, I strongly *strongly* encourage you not to block and wait for the
PDO to get removed. A ton of things could prevent that from happening
in a timely manner or at all. For instance, an application which does
not release its handle to the PDOs stack will keep the PDO in a
surprise
removed (but not removed) state. EvtCleanupCallack only occurs in the
removed state. Why do you need to know when the PDO is actually
deleted?

Well, to be fair, the blocking behaviour is not particularly for “my”
benefit:

I agree the way most of the kernel works is asynchronous and event
based, and it’s better to leave data in memory than to block threads in
the kernel which may never get unblocked.

At the moment, the blocking behaviour is simply to handle a cleanup case

where I have:

Datastructure X
^ (1)
|
v (*)
Datastructure Y (contains WDF_CHILD_IDENTIFICATION_DESCRIPTION_HEADER)
^ (1)
|
v (0 or 1)
PDO

There are some cases where I want to clean up a datastructure X, which
involves getting rid of a whole bunch of Y’s which involves ripping down

lots of PDO’s.

Really I have the blocking behaviour for 2 reasons:

  1. It “looks” like the code is easier (although I’m coming slowly to the

conclusion that this is not true, and ref-counts are better).
2) It means that for people interacting with the driver via WMI, they
can do various sorts of cleanup operation in a blocking manner, and
don’t need to deal with transient (or not so transient) destroying
states. Having said that I can get around this by allowing the transient

destroying states, and then changing the way external WMI queries “see”
my internal objects.

MH.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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