surprise removal in kmdf

Gianluca_Varenni · October 23, 2007, 9:26pm

In a blog post regarding surprise removal, Doron Holan said

http://blogs.msdn.com/doronh/archive/2007/02/26/which-callback-is-called-on-surprise-or-graceful-removal.aspx

Another potential solution is to register for EvtDeviceSurpriseRemoval or
implement IPnpCallback::OnSurpriseRemoval. This provides you with half the
solution, but ignores the other half of the problem, graceful removal. You
could track state in the surprise removal callback and then check this state
in your device’s cleanup routine/destructor. This does have the benefit of
working within the framework and its contracts, but it still requires you to
track state. Furthermore, the surprise removal callback is not synchronized
with the other power up/down callbacks which is another detractor.

I read this as “EvtDeviceSurpriseRemoval is not synchronized with
EvtDeviceD0Exit”.

But the WDK documentation also says

A user unplugs a device unexpectedly. The bus driver for the device’s bus
discovers that the device is missing and calls
WdfChildListUpdateChildDescriptionAsMissing.
For each function and filter driver that supports the device, the framework
does the following, in sequence, one driver at a time, starting with the
driver that is highest in the driver stack:

The framework calls the driver’s EvtDeviceSurpriseRemoval callback
function (if it exists).
…
The framework calls the driver’s EvtDeviceD0Exit callback function (if it
exists).

Am I missing something?

Have a nice day
GV

Doron_Holan · October 24, 2007, 2:05am

EvtDeviceSurpriseRemoval is not synchronized with EvtDeviceD0Exit. If the device stack does not support s0 idle, then the 2 cannot overlap b/c a system power down (and thus a dx irp sent to the stack) cannot occur while there is a state changing pnp irp pending. If s0 idle is enabled on the device a dx irp can be sent during a pnp state changing irp (b/c it is sent spontaneously by the power policy owner without relation to an Sx irp) and the 2 can overlap. If you are the FDO, you control S0 idle policy and can make assumptions. If you are the bus driver, you do not control s0 idle on the child device and must not make any assumptions about s0 idle.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Tuesday, October 23, 2007 6:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] surprise removal in kmdf

In a blog post regarding surprise removal, Doron Holan said

http://blogs.msdn.com/doronh/archive/2007/02/26/which-callback-is-called-on-surprise-or-graceful-removal.aspx

Another potential solution is to register for EvtDeviceSurpriseRemoval or
implement IPnpCallback::OnSurpriseRemoval. This provides you with half the
solution, but ignores the other half of the problem, graceful removal. You
could track state in the surprise removal callback and then check this state
in your device’s cleanup routine/destructor. This does have the benefit of
working within the framework and its contracts, but it still requires you to
track state. Furthermore, the surprise removal callback is not synchronized
with the other power up/down callbacks which is another detractor.

I read this as “EvtDeviceSurpriseRemoval is not synchronized with
EvtDeviceD0Exit”.

But the WDK documentation also says

A user unplugs a device unexpectedly. The bus driver for the device’s bus
discovers that the device is missing and calls
WdfChildListUpdateChildDescriptionAsMissing.
For each function and filter driver that supports the device, the framework
does the following, in sequence, one driver at a time, starting with the
driver that is highest in the driver stack:

The framework calls the driver’s EvtDeviceSurpriseRemoval callback
function (if it exists).
…
The framework calls the driver’s EvtDeviceD0Exit callback function (if it
exists).

Am I missing something?

Have a nice day
GV

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

Gianluca_Varenni · October 24, 2007, 12:53pm

I’m the FDO and I don’t support S0 idle, so I can safely assume that the two
cannot overlap (can I assume that they are called in the
SurpriseRemoval…DeviceD0Exit order?).

My point is that the WDK documentation seems wrong

http://msdn2.microsoft.com/en-us/library/aa490095.aspx (Surprise Removal
paragraph)

Have a nice day
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, October 23, 2007 11:02 PM
Subject: RE: [ntdev] surprise removal in kmdf

EvtDeviceSurpriseRemoval is not synchronized with EvtDeviceD0Exit. If the
device stack does not support s0 idle, then the 2 cannot overlap b/c a
system power down (and thus a dx irp sent to the stack) cannot occur while
there is a state changing pnp irp pending. If s0 idle is enabled on the
device a dx irp can be sent during a pnp state changing irp (b/c it is sent
spontaneously by the power policy owner without relation to an Sx irp) and
the 2 can overlap. If you are the FDO, you control S0 idle policy and can
make assumptions. If you are the bus driver, you do not control s0 idle on
the child device and must not make any assumptions about s0 idle.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Tuesday, October 23, 2007 6:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] surprise removal in kmdf

In a blog post regarding surprise removal, Doron Holan said

----
http://blogs.msdn.com/doronh/archive/2007/02/26/which-callback-is-called-on-surprise-or-graceful-removal.aspx

Another potential solution is to register for EvtDeviceSurpriseRemoval or
implement IPnpCallback::OnSurpriseRemoval. This provides you with half the
solution, but ignores the other half of the problem, graceful removal. You
could track state in the surprise removal callback and then check this state
in your device’s cleanup routine/destructor. This does have the benefit of
working within the framework and its contracts, but it still requires you to
track state. Furthermore, the surprise removal callback is not synchronized
with the other power up/down callbacks which is another detractor.
----

I read this as “EvtDeviceSurpriseRemoval is not synchronized with
EvtDeviceD0Exit”.

But the WDK documentation also says

----
A user unplugs a device unexpectedly. The bus driver for the device’s bus
discovers that the device is missing and calls
WdfChildListUpdateChildDescriptionAsMissing.
For each function and filter driver that supports the device, the framework
does the following, in sequence, one driver at a time, starting with the
driver that is highest in the driver stack:
- The framework calls the driver’s EvtDeviceSurpriseRemoval callback
function (if it exists).
…
- The framework calls the driver’s EvtDeviceD0Exit callback function (if it
exists).
----

Am I missing something?

Have a nice day
GV

—
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 · October 24, 2007, 1:38pm

Why do you need to register for EvtDeviceSurpriseREmoval in the first place? What callback abstraction in KMDF is not tracking the state that you need on your behalf?

The docs need a little bit of clarification, I will fwd that to the doc writer

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 9:52 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

I’m the FDO and I don’t support S0 idle, so I can safely assume that the two
cannot overlap (can I assume that they are called in the
SurpriseRemoval…DeviceD0Exit order?).

My point is that the WDK documentation seems wrong

http://msdn2.microsoft.com/en-us/library/aa490095.aspx (Surprise Removal
paragraph)

Have a nice day
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, October 23, 2007 11:02 PM
Subject: RE: [ntdev] surprise removal in kmdf

EvtDeviceSurpriseRemoval is not synchronized with EvtDeviceD0Exit. If the
device stack does not support s0 idle, then the 2 cannot overlap b/c a
system power down (and thus a dx irp sent to the stack) cannot occur while
there is a state changing pnp irp pending. If s0 idle is enabled on the
device a dx irp can be sent during a pnp state changing irp (b/c it is sent
spontaneously by the power policy owner without relation to an Sx irp) and
the 2 can overlap. If you are the FDO, you control S0 idle policy and can
make assumptions. If you are the bus driver, you do not control s0 idle on
the child device and must not make any assumptions about s0 idle.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Tuesday, October 23, 2007 6:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] surprise removal in kmdf

In a blog post regarding surprise removal, Doron Holan said

----
http://blogs.msdn.com/doronh/archive/2007/02/26/which-callback-is-called-on-surprise-or-graceful-removal.aspx

Another potential solution is to register for EvtDeviceSurpriseRemoval or
implement IPnpCallback::OnSurpriseRemoval. This provides you with half the
solution, but ignores the other half of the problem, graceful removal. You
could track state in the surprise removal callback and then check this state
in your device’s cleanup routine/destructor. This does have the benefit of
working within the framework and its contracts, but it still requires you to
track state. Furthermore, the surprise removal callback is not synchronized
with the other power up/down callbacks which is another detractor.
----

I read this as “EvtDeviceSurpriseRemoval is not synchronized with
EvtDeviceD0Exit”.

But the WDK documentation also says

----
A user unplugs a device unexpectedly. The bus driver for the device’s bus
discovers that the device is missing and calls
WdfChildListUpdateChildDescriptionAsMissing.
For each function and filter driver that supports the device, the framework
does the following, in sequence, one driver at a time, starting with the
driver that is highest in the driver stack:
- The framework calls the driver’s EvtDeviceSurpriseRemoval callback
function (if it exists).
…
- The framework calls the driver’s EvtDeviceD0Exit callback function (if it
exists).
----

Am I missing something?

Have a nice day
GV

—
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

Gianluca_Varenni · October 24, 2007, 2:47pm

An IoTarget has callbacks for the QueryRemove, RemoveCanceled and
RemoveComplete, but it doesn’t have a specific callback for SurpriseRemoval.
But as I write, it just came to my mind that I know if a surprise removal
happened because QueryRemove+RemoveCanceled (or none) got called before the
RemoveComplete

QueryRemove (with removal_ok), RemoveComplete –> graceful
removal
QueryRemove (with removal_ok), RemoveCanceled, RemoveComplete –> surprise
removal
Remove Complete –> surprise
removal

I’m still putting a lot of pieces of the PnP puzzle (in my mind) together.

As to what I’m trying to achieve, it’s a sort of driver-to-driver
communication issue (although there’s only one driver). The driver I’m
developing (an FDO driver) uses a driver thread to have two FDOs (managed by
the driver) exchange data between each other (a lot of data). I’m now
dealing with the problem of the two devices being added/removed/surprise
removed. I don’t have a definitive solution to it, mostly spending time in
trying different approaches (and reading a lot of documentation).

Thanks for the help
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 24, 2007 10:35 AM
Subject: RE: [ntdev] surprise removal in kmdf

Why do you need to register for EvtDeviceSurpriseREmoval in the first place?
What callback abstraction in KMDF is not tracking the state that you need on
your behalf?

The docs need a little bit of clarification, I will fwd that to the doc
writer

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 9:52 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

I’m the FDO and I don’t support S0 idle, so I can safely assume that the two
cannot overlap (can I assume that they are called in the
SurpriseRemoval…DeviceD0Exit order?).

My point is that the WDK documentation seems wrong

http://msdn2.microsoft.com/en-us/library/aa490095.aspx (Surprise Removal
paragraph)

Have a nice day
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, October 23, 2007 11:02 PM
Subject: RE: [ntdev] surprise removal in kmdf

EvtDeviceSurpriseRemoval is not synchronized with EvtDeviceD0Exit. If the
device stack does not support s0 idle, then the 2 cannot overlap b/c a
system power down (and thus a dx irp sent to the stack) cannot occur while
there is a state changing pnp irp pending. If s0 idle is enabled on the
device a dx irp can be sent during a pnp state changing irp (b/c it is sent
spontaneously by the power policy owner without relation to an Sx irp) and
the 2 can overlap. If you are the FDO, you control S0 idle policy and can
make assumptions. If you are the bus driver, you do not control s0 idle on
the child device and must not make any assumptions about s0 idle.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Tuesday, October 23, 2007 6:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] surprise removal in kmdf

In a blog post regarding surprise removal, Doron Holan said

----
http://blogs.msdn.com/doronh/archive/2007/02/26/which-callback-is-called-on-surprise-or-graceful-removal.aspx

Another potential solution is to register for EvtDeviceSurpriseRemoval or
implement IPnpCallback::OnSurpriseRemoval. This provides you with half the
solution, but ignores the other half of the problem, graceful removal. You
could track state in the surprise removal callback and then check this state
in your device’s cleanup routine/destructor. This does have the benefit of
working within the framework and its contracts, but it still requires you to
track state. Furthermore, the surprise removal callback is not synchronized
with the other power up/down callbacks which is another detractor.
----

I read this as “EvtDeviceSurpriseRemoval is not synchronized with
EvtDeviceD0Exit”.

But the WDK documentation also says

----
A user unplugs a device unexpectedly. The bus driver for the device’s bus
discovers that the device is missing and calls
WdfChildListUpdateChildDescriptionAsMissing.
For each function and filter driver that supports the device, the framework
does the following, in sequence, one driver at a time, starting with the
driver that is highest in the driver stack:
- The framework calls the driver’s EvtDeviceSurpriseRemoval callback
function (if it exists).
…
- The framework calls the driver’s EvtDeviceD0Exit callback function (if it
exists).
----

Am I missing something?

Have a nice day
GV

—
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

Doron_Holan · October 24, 2007, 3:26pm

if the device you have an io target against is surprise removed, you get a remove completed callback without the query remove callback. Failing an iotarget query remove callback will not cause a surprise remove to occur. The component which has the io target open should not care that the target is surprise removed, only that it can get a RemoveComplete w/out a query remove and then do the cleanup in the RemoveComplete that would have happened in QueryRemove

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 11:42 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

An IoTarget has callbacks for the QueryRemove, RemoveCanceled and
RemoveComplete, but it doesn’t have a specific callback for SurpriseRemoval.
But as I write, it just came to my mind that I know if a surprise removal
happened because QueryRemove+RemoveCanceled (or none) got called before the
RemoveComplete

QueryRemove (with removal_ok), RemoveComplete –> graceful
removal
QueryRemove (with removal_ok), RemoveCanceled, RemoveComplete –> surprise
removal
Remove Complete –> surprise
removal

I’m still putting a lot of pieces of the PnP puzzle (in my mind) together.

As to what I’m trying to achieve, it’s a sort of driver-to-driver
communication issue (although there’s only one driver). The driver I’m
developing (an FDO driver) uses a driver thread to have two FDOs (managed by
the driver) exchange data between each other (a lot of data). I’m now
dealing with the problem of the two devices being added/removed/surprise
removed. I don’t have a definitive solution to it, mostly spending time in
trying different approaches (and reading a lot of documentation).

Thanks for the help
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 24, 2007 10:35 AM
Subject: RE: [ntdev] surprise removal in kmdf

Why do you need to register for EvtDeviceSurpriseREmoval in the first place?
What callback abstraction in KMDF is not tracking the state that you need on
your behalf?

The docs need a little bit of clarification, I will fwd that to the doc
writer

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 9:52 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

I’m the FDO and I don’t support S0 idle, so I can safely assume that the two
cannot overlap (can I assume that they are called in the
SurpriseRemoval…DeviceD0Exit order?).

My point is that the WDK documentation seems wrong

http://msdn2.microsoft.com/en-us/library/aa490095.aspx (Surprise Removal
paragraph)

Have a nice day
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, October 23, 2007 11:02 PM
Subject: RE: [ntdev] surprise removal in kmdf

EvtDeviceSurpriseRemoval is not synchronized with EvtDeviceD0Exit. If the
device stack does not support s0 idle, then the 2 cannot overlap b/c a
system power down (and thus a dx irp sent to the stack) cannot occur while
there is a state changing pnp irp pending. If s0 idle is enabled on the
device a dx irp can be sent during a pnp state changing irp (b/c it is sent
spontaneously by the power policy owner without relation to an Sx irp) and
the 2 can overlap. If you are the FDO, you control S0 idle policy and can
make assumptions. If you are the bus driver, you do not control s0 idle on
the child device and must not make any assumptions about s0 idle.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Tuesday, October 23, 2007 6:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] surprise removal in kmdf

In a blog post regarding surprise removal, Doron Holan said

----
http://blogs.msdn.com/doronh/archive/2007/02/26/which-callback-is-called-on-surprise-or-graceful-removal.aspx

Another potential solution is to register for EvtDeviceSurpriseRemoval or
implement IPnpCallback::OnSurpriseRemoval. This provides you with half the
solution, but ignores the other half of the problem, graceful removal. You
could track state in the surprise removal callback and then check this state
in your device’s cleanup routine/destructor. This does have the benefit of
working within the framework and its contracts, but it still requires you to
track state. Furthermore, the surprise removal callback is not synchronized
with the other power up/down callbacks which is another detractor.
----

I read this as “EvtDeviceSurpriseRemoval is not synchronized with
EvtDeviceD0Exit”.

But the WDK documentation also says

----
A user unplugs a device unexpectedly. The bus driver for the device’s bus
discovers that the device is missing and calls
WdfChildListUpdateChildDescriptionAsMissing.
For each function and filter driver that supports the device, the framework
does the following, in sequence, one driver at a time, starting with the
driver that is highest in the driver stack:
- The framework calls the driver’s EvtDeviceSurpriseRemoval callback
function (if it exists).
…
- The framework calls the driver’s EvtDeviceD0Exit callback function (if it
exists).
----

Am I missing something?

Have a nice day
GV

—
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

Gianluca_Varenni · October 24, 2007, 3:36pm

I think I was not clear in my message. I meant exactly what you said (and i
think that lately my ability to clearly explain things has become worse and
worse…)

GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 24, 2007 12:24 PM
Subject: RE: [ntdev] surprise removal in kmdf

if the device you have an io target against is surprise removed, you get a
remove completed callback without the query remove callback. Failing an
iotarget query remove callback will not cause a surprise remove to occur.
The component which has the io target open should not care that the target
is surprise removed, only that it can get a RemoveComplete w/out a query
remove and then do the cleanup in the RemoveComplete that would have
happened in QueryRemove

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 11:42 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

An IoTarget has callbacks for the QueryRemove, RemoveCanceled and
RemoveComplete, but it doesn’t have a specific callback for SurpriseRemoval.
But as I write, it just came to my mind that I know if a surprise removal
happened because QueryRemove+RemoveCanceled (or none) got called before the
RemoveComplete

QueryRemove (with removal_ok), RemoveComplete –> graceful
removal
QueryRemove (with removal_ok), RemoveCanceled, RemoveComplete –> surprise
removal
Remove Complete –> surprise
removal

I’m still putting a lot of pieces of the PnP puzzle (in my mind) together.

As to what I’m trying to achieve, it’s a sort of driver-to-driver
communication issue (although there’s only one driver). The driver I’m
developing (an FDO driver) uses a driver thread to have two FDOs (managed by
the driver) exchange data between each other (a lot of data). I’m now
dealing with the problem of the two devices being added/removed/surprise
removed. I don’t have a definitive solution to it, mostly spending time in
trying different approaches (and reading a lot of documentation).

Thanks for the help
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 24, 2007 10:35 AM
Subject: RE: [ntdev] surprise removal in kmdf

Why do you need to register for EvtDeviceSurpriseREmoval in the first place?
What callback abstraction in KMDF is not tracking the state that you need on
your behalf?

The docs need a little bit of clarification, I will fwd that to the doc
writer

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 9:52 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

I’m the FDO and I don’t support S0 idle, so I can safely assume that the two
cannot overlap (can I assume that they are called in the
SurpriseRemoval…DeviceD0Exit order?).

My point is that the WDK documentation seems wrong

http://msdn2.microsoft.com/en-us/library/aa490095.aspx (Surprise Removal
paragraph)

Have a nice day
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, October 23, 2007 11:02 PM
Subject: RE: [ntdev] surprise removal in kmdf

EvtDeviceSurpriseRemoval is not synchronized with EvtDeviceD0Exit. If the
device stack does not support s0 idle, then the 2 cannot overlap b/c a
system power down (and thus a dx irp sent to the stack) cannot occur while
there is a state changing pnp irp pending. If s0 idle is enabled on the
device a dx irp can be sent during a pnp state changing irp (b/c it is sent
spontaneously by the power policy owner without relation to an Sx irp) and
the 2 can overlap. If you are the FDO, you control S0 idle policy and can
make assumptions. If you are the bus driver, you do not control s0 idle on
the child device and must not make any assumptions about s0 idle.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Tuesday, October 23, 2007 6:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] surprise removal in kmdf

In a blog post regarding surprise removal, Doron Holan said

----
http://blogs.msdn.com/doronh/archive/2007/02/26/which-callback-is-called-on-surprise-or-graceful-removal.aspx

Another potential solution is to register for EvtDeviceSurpriseRemoval or
implement IPnpCallback::OnSurpriseRemoval. This provides you with half the
solution, but ignores the other half of the problem, graceful removal. You
could track state in the surprise removal callback and then check this state
in your device’s cleanup routine/destructor. This does have the benefit of
working within the framework and its contracts, but it still requires you to
track state. Furthermore, the surprise removal callback is not synchronized
with the other power up/down callbacks which is another detractor.
----

I read this as “EvtDeviceSurpriseRemoval is not synchronized with
EvtDeviceD0Exit”.

But the WDK documentation also says

----
A user unplugs a device unexpectedly. The bus driver for the device’s bus
discovers that the device is missing and calls
WdfChildListUpdateChildDescriptionAsMissing.
For each function and filter driver that supports the device, the framework
does the following, in sequence, one driver at a time, starting with the
driver that is highest in the driver stack:
- The framework calls the driver’s EvtDeviceSurpriseRemoval callback
function (if it exists).
…
- The framework calls the driver’s EvtDeviceD0Exit callback function (if it
exists).
----

Am I missing something?

Have a nice day
GV

—
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

—
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 · October 24, 2007, 3:42pm

So why do you need to register for EvtDeviceSurpriseRemoval?

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 12:35 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

I think I was not clear in my message. I meant exactly what you said (and i
think that lately my ability to clearly explain things has become worse and
worse…)

GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 24, 2007 12:24 PM
Subject: RE: [ntdev] surprise removal in kmdf

if the device you have an io target against is surprise removed, you get a
remove completed callback without the query remove callback. Failing an
iotarget query remove callback will not cause a surprise remove to occur.
The component which has the io target open should not care that the target
is surprise removed, only that it can get a RemoveComplete w/out a query
remove and then do the cleanup in the RemoveComplete that would have
happened in QueryRemove

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 11:42 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

An IoTarget has callbacks for the QueryRemove, RemoveCanceled and
RemoveComplete, but it doesn’t have a specific callback for SurpriseRemoval.
But as I write, it just came to my mind that I know if a surprise removal
happened because QueryRemove+RemoveCanceled (or none) got called before the
RemoveComplete

QueryRemove (with removal_ok), RemoveComplete –> graceful
removal
QueryRemove (with removal_ok), RemoveCanceled, RemoveComplete –> surprise
removal
Remove Complete –> surprise
removal

I’m still putting a lot of pieces of the PnP puzzle (in my mind) together.

As to what I’m trying to achieve, it’s a sort of driver-to-driver
communication issue (although there’s only one driver). The driver I’m
developing (an FDO driver) uses a driver thread to have two FDOs (managed by
the driver) exchange data between each other (a lot of data). I’m now
dealing with the problem of the two devices being added/removed/surprise
removed. I don’t have a definitive solution to it, mostly spending time in
trying different approaches (and reading a lot of documentation).

Thanks for the help
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 24, 2007 10:35 AM
Subject: RE: [ntdev] surprise removal in kmdf

Why do you need to register for EvtDeviceSurpriseREmoval in the first place?
What callback abstraction in KMDF is not tracking the state that you need on
your behalf?

The docs need a little bit of clarification, I will fwd that to the doc
writer

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 9:52 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

I’m the FDO and I don’t support S0 idle, so I can safely assume that the two
cannot overlap (can I assume that they are called in the
SurpriseRemoval…DeviceD0Exit order?).

My point is that the WDK documentation seems wrong

http://msdn2.microsoft.com/en-us/library/aa490095.aspx (Surprise Removal
paragraph)

Have a nice day
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, October 23, 2007 11:02 PM
Subject: RE: [ntdev] surprise removal in kmdf

EvtDeviceSurpriseRemoval is not synchronized with EvtDeviceD0Exit. If the
device stack does not support s0 idle, then the 2 cannot overlap b/c a
system power down (and thus a dx irp sent to the stack) cannot occur while
there is a state changing pnp irp pending. If s0 idle is enabled on the
device a dx irp can be sent during a pnp state changing irp (b/c it is sent
spontaneously by the power policy owner without relation to an Sx irp) and
the 2 can overlap. If you are the FDO, you control S0 idle policy and can
make assumptions. If you are the bus driver, you do not control s0 idle on
the child device and must not make any assumptions about s0 idle.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Tuesday, October 23, 2007 6:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] surprise removal in kmdf

In a blog post regarding surprise removal, Doron Holan said

----
http://blogs.msdn.com/doronh/archive/2007/02/26/which-callback-is-called-on-surprise-or-graceful-removal.aspx

Another potential solution is to register for EvtDeviceSurpriseRemoval or
implement IPnpCallback::OnSurpriseRemoval. This provides you with half the
solution, but ignores the other half of the problem, graceful removal. You
could track state in the surprise removal callback and then check this state
in your device’s cleanup routine/destructor. This does have the benefit of
working within the framework and its contracts, but it still requires you to
track state. Furthermore, the surprise removal callback is not synchronized
with the other power up/down callbacks which is another detractor.
----

I read this as “EvtDeviceSurpriseRemoval is not synchronized with
EvtDeviceD0Exit”.

But the WDK documentation also says

----
A user unplugs a device unexpectedly. The bus driver for the device’s bus
discovers that the device is missing and calls
WdfChildListUpdateChildDescriptionAsMissing.
For each function and filter driver that supports the device, the framework
does the following, in sequence, one driver at a time, starting with the
driver that is highest in the driver stack:
- The framework calls the driver’s EvtDeviceSurpriseRemoval callback
function (if it exists).
…
- The framework calls the driver’s EvtDeviceD0Exit callback function (if it
exists).
----

Am I missing something?

Have a nice day
GV

—
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

—
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

Gianluca_Varenni · October 24, 2007, 4:29pm

Well, RemoveComplete gets invoked too late in my case. By the time
RemoveComplete is invoked, the EvtDeviceD0Exit and EvtDeviceReleaseHardware
have already run, thus the resources of the device has been already
released. If the device that holds the io target got some pointers from the
device being surprise removed (e.g. through an internal I/O control, and
those pointers are related to some DMA memory), those pointers are no longer
valid way before RemoveComplete gets called. I don’t know if I explained my
point. A solution that came to my mind is using an inverted call on the io
target to notify the device holding the io target that the other device got
surprise removed.

Having said that, I think that the current mockup I have is getting
complicated, I’m starting from the whiteboard again…

Thanks for the help!
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 24, 2007 12:24 PM
Subject: RE: [ntdev] surprise removal in kmdf

if the device you have an io target against is surprise removed, you get a
remove completed callback without the query remove callback. Failing an
iotarget query remove callback will not cause a surprise remove to occur.
The component which has the io target open should not care that the target
is surprise removed, only that it can get a RemoveComplete w/out a query
remove and then do the cleanup in the RemoveComplete that would have
happened in QueryRemove

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 11:42 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

An IoTarget has callbacks for the QueryRemove, RemoveCanceled and
RemoveComplete, but it doesn’t have a specific callback for SurpriseRemoval.
But as I write, it just came to my mind that I know if a surprise removal
happened because QueryRemove+RemoveCanceled (or none) got called before the
RemoveComplete

QueryRemove (with removal_ok), RemoveComplete –> graceful
removal
QueryRemove (with removal_ok), RemoveCanceled, RemoveComplete –> surprise
removal
Remove Complete –> surprise
removal

I’m still putting a lot of pieces of the PnP puzzle (in my mind) together.

As to what I’m trying to achieve, it’s a sort of driver-to-driver
communication issue (although there’s only one driver). The driver I’m
developing (an FDO driver) uses a driver thread to have two FDOs (managed by
the driver) exchange data between each other (a lot of data). I’m now
dealing with the problem of the two devices being added/removed/surprise
removed. I don’t have a definitive solution to it, mostly spending time in
trying different approaches (and reading a lot of documentation).

Thanks for the help
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 24, 2007 10:35 AM
Subject: RE: [ntdev] surprise removal in kmdf

Why do you need to register for EvtDeviceSurpriseREmoval in the first place?
What callback abstraction in KMDF is not tracking the state that you need on
your behalf?

The docs need a little bit of clarification, I will fwd that to the doc
writer

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 9:52 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

I’m the FDO and I don’t support S0 idle, so I can safely assume that the two
cannot overlap (can I assume that they are called in the
SurpriseRemoval…DeviceD0Exit order?).

My point is that the WDK documentation seems wrong

http://msdn2.microsoft.com/en-us/library/aa490095.aspx (Surprise Removal
paragraph)

Have a nice day
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, October 23, 2007 11:02 PM
Subject: RE: [ntdev] surprise removal in kmdf

EvtDeviceSurpriseRemoval is not synchronized with EvtDeviceD0Exit. If the
device stack does not support s0 idle, then the 2 cannot overlap b/c a
system power down (and thus a dx irp sent to the stack) cannot occur while
there is a state changing pnp irp pending. If s0 idle is enabled on the
device a dx irp can be sent during a pnp state changing irp (b/c it is sent
spontaneously by the power policy owner without relation to an Sx irp) and
the 2 can overlap. If you are the FDO, you control S0 idle policy and can
make assumptions. If you are the bus driver, you do not control s0 idle on
the child device and must not make any assumptions about s0 idle.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Tuesday, October 23, 2007 6:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] surprise removal in kmdf

In a blog post regarding surprise removal, Doron Holan said

----
http://blogs.msdn.com/doronh/archive/2007/02/26/which-callback-is-called-on-surprise-or-graceful-removal.aspx

Another potential solution is to register for EvtDeviceSurpriseRemoval or
implement IPnpCallback::OnSurpriseRemoval. This provides you with half the
solution, but ignores the other half of the problem, graceful removal. You
could track state in the surprise removal callback and then check this state
in your device’s cleanup routine/destructor. This does have the benefit of
working within the framework and its contracts, but it still requires you to
track state. Furthermore, the surprise removal callback is not synchronized
with the other power up/down callbacks which is another detractor.
----

I read this as “EvtDeviceSurpriseRemoval is not synchronized with
EvtDeviceD0Exit”.

But the WDK documentation also says

----
A user unplugs a device unexpectedly. The bus driver for the device’s bus
discovers that the device is missing and calls
WdfChildListUpdateChildDescriptionAsMissing.
For each function and filter driver that supports the device, the framework
does the following, in sequence, one driver at a time, starting with the
driver that is highest in the driver stack:
- The framework calls the driver’s EvtDeviceSurpriseRemoval callback
function (if it exists).
…
- The framework calls the driver’s EvtDeviceD0Exit callback function (if it
exists).
----

Am I missing something?

Have a nice day
GV

—
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

—
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

Gianluca_Varenni · October 24, 2007, 4:45pm

I’m looking for a way to notify the owner of an io target that the target
device received a surprise removal before the target device itself executes
the sequence of operations to tear down everything (EvtIoStop,
EvtDeviceD0Exit and such).

Sorry for getting you so confused (I’m confused as well as to what I’m
doing, ouch).

Thanks again
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 24, 2007 12:39 PM
Subject: RE: [ntdev] surprise removal in kmdf

So why do you need to register for EvtDeviceSurpriseRemoval?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 12:35 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

I think I was not clear in my message. I meant exactly what you said (and i
think that lately my ability to clearly explain things has become worse and
worse…)

GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 24, 2007 12:24 PM
Subject: RE: [ntdev] surprise removal in kmdf

if the device you have an io target against is surprise removed, you get a
remove completed callback without the query remove callback. Failing an
iotarget query remove callback will not cause a surprise remove to occur.
The component which has the io target open should not care that the target
is surprise removed, only that it can get a RemoveComplete w/out a query
remove and then do the cleanup in the RemoveComplete that would have
happened in QueryRemove

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 11:42 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

An IoTarget has callbacks for the QueryRemove, RemoveCanceled and
RemoveComplete, but it doesn’t have a specific callback for SurpriseRemoval.
But as I write, it just came to my mind that I know if a surprise removal
happened because QueryRemove+RemoveCanceled (or none) got called before the
RemoveComplete

QueryRemove (with removal_ok), RemoveComplete –> graceful
removal
QueryRemove (with removal_ok), RemoveCanceled, RemoveComplete –> surprise
removal
Remove Complete –> surprise
removal

I’m still putting a lot of pieces of the PnP puzzle (in my mind) together.

As to what I’m trying to achieve, it’s a sort of driver-to-driver
communication issue (although there’s only one driver). The driver I’m
developing (an FDO driver) uses a driver thread to have two FDOs (managed by
the driver) exchange data between each other (a lot of data). I’m now
dealing with the problem of the two devices being added/removed/surprise
removed. I don’t have a definitive solution to it, mostly spending time in
trying different approaches (and reading a lot of documentation).

Thanks for the help
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 24, 2007 10:35 AM
Subject: RE: [ntdev] surprise removal in kmdf

Why do you need to register for EvtDeviceSurpriseREmoval in the first place?
What callback abstraction in KMDF is not tracking the state that you need on
your behalf?

The docs need a little bit of clarification, I will fwd that to the doc
writer

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 9:52 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

I’m the FDO and I don’t support S0 idle, so I can safely assume that the two
cannot overlap (can I assume that they are called in the
SurpriseRemoval…DeviceD0Exit order?).

My point is that the WDK documentation seems wrong

http://msdn2.microsoft.com/en-us/library/aa490095.aspx (Surprise Removal
paragraph)

Have a nice day
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, October 23, 2007 11:02 PM
Subject: RE: [ntdev] surprise removal in kmdf

EvtDeviceSurpriseRemoval is not synchronized with EvtDeviceD0Exit. If the
device stack does not support s0 idle, then the 2 cannot overlap b/c a
system power down (and thus a dx irp sent to the stack) cannot occur while
there is a state changing pnp irp pending. If s0 idle is enabled on the
device a dx irp can be sent during a pnp state changing irp (b/c it is sent
spontaneously by the power policy owner without relation to an Sx irp) and
the 2 can overlap. If you are the FDO, you control S0 idle policy and can
make assumptions. If you are the bus driver, you do not control s0 idle on
the child device and must not make any assumptions about s0 idle.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Tuesday, October 23, 2007 6:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] surprise removal in kmdf

In a blog post regarding surprise removal, Doron Holan said

----
http://blogs.msdn.com/doronh/archive/2007/02/26/which-callback-is-called-on-surprise-or-graceful-removal.aspx

Another potential solution is to register for EvtDeviceSurpriseRemoval or
implement IPnpCallback::OnSurpriseRemoval. This provides you with half the
solution, but ignores the other half of the problem, graceful removal. You
could track state in the surprise removal callback and then check this state
in your device’s cleanup routine/destructor. This does have the benefit of
working within the framework and its contracts, but it still requires you to
track state. Furthermore, the surprise removal callback is not synchronized
with the other power up/down callbacks which is another detractor.
----

I read this as “EvtDeviceSurpriseRemoval is not synchronized with
EvtDeviceD0Exit”.

But the WDK documentation also says

----
A user unplugs a device unexpectedly. The bus driver for the device’s bus
discovers that the device is missing and calls
WdfChildListUpdateChildDescriptionAsMissing.
For each function and filter driver that supports the device, the framework
does the following, in sequence, one driver at a time, starting with the
driver that is highest in the driver stack:
- The framework calls the driver’s EvtDeviceSurpriseRemoval callback
function (if it exists).
…
- The framework calls the driver’s EvtDeviceD0Exit callback function (if it
exists).
----

Am I missing something?

Have a nice day
GV

—
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

—
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

Doron_Holan · October 24, 2007, 7:01pm

Here you go, this should help.

http://blogs.msdn.com/doronh/archive/2007/10/24/how-to-share-hw-resources-with-another-driver-not-in-the-same-pnp-hierarchy.aspx

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 1:45 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

I’m looking for a way to notify the owner of an io target that the target
device received a surprise removal before the target device itself executes
the sequence of operations to tear down everything (EvtIoStop,
EvtDeviceD0Exit and such).

Sorry for getting you so confused (I’m confused as well as to what I’m
doing, ouch).

Thanks again
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 24, 2007 12:39 PM
Subject: RE: [ntdev] surprise removal in kmdf

So why do you need to register for EvtDeviceSurpriseRemoval?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 12:35 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

I think I was not clear in my message. I meant exactly what you said (and i
think that lately my ability to clearly explain things has become worse and
worse…)

GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 24, 2007 12:24 PM
Subject: RE: [ntdev] surprise removal in kmdf

if the device you have an io target against is surprise removed, you get a
remove completed callback without the query remove callback. Failing an
iotarget query remove callback will not cause a surprise remove to occur.
The component which has the io target open should not care that the target
is surprise removed, only that it can get a RemoveComplete w/out a query
remove and then do the cleanup in the RemoveComplete that would have
happened in QueryRemove

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 11:42 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

An IoTarget has callbacks for the QueryRemove, RemoveCanceled and
RemoveComplete, but it doesn’t have a specific callback for SurpriseRemoval.
But as I write, it just came to my mind that I know if a surprise removal
happened because QueryRemove+RemoveCanceled (or none) got called before the
RemoveComplete

QueryRemove (with removal_ok), RemoveComplete –> graceful
removal
QueryRemove (with removal_ok), RemoveCanceled, RemoveComplete –> surprise
removal
Remove Complete –> surprise
removal

I’m still putting a lot of pieces of the PnP puzzle (in my mind) together.

As to what I’m trying to achieve, it’s a sort of driver-to-driver
communication issue (although there’s only one driver). The driver I’m
developing (an FDO driver) uses a driver thread to have two FDOs (managed by
the driver) exchange data between each other (a lot of data). I’m now
dealing with the problem of the two devices being added/removed/surprise
removed. I don’t have a definitive solution to it, mostly spending time in
trying different approaches (and reading a lot of documentation).

Thanks for the help
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 24, 2007 10:35 AM
Subject: RE: [ntdev] surprise removal in kmdf

Why do you need to register for EvtDeviceSurpriseREmoval in the first place?
What callback abstraction in KMDF is not tracking the state that you need on
your behalf?

The docs need a little bit of clarification, I will fwd that to the doc
writer

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 9:52 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

I’m the FDO and I don’t support S0 idle, so I can safely assume that the two
cannot overlap (can I assume that they are called in the
SurpriseRemoval…DeviceD0Exit order?).

My point is that the WDK documentation seems wrong

http://msdn2.microsoft.com/en-us/library/aa490095.aspx (Surprise Removal
paragraph)

Have a nice day
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, October 23, 2007 11:02 PM
Subject: RE: [ntdev] surprise removal in kmdf

EvtDeviceSurpriseRemoval is not synchronized with EvtDeviceD0Exit. If the
device stack does not support s0 idle, then the 2 cannot overlap b/c a
system power down (and thus a dx irp sent to the stack) cannot occur while
there is a state changing pnp irp pending. If s0 idle is enabled on the
device a dx irp can be sent during a pnp state changing irp (b/c it is sent
spontaneously by the power policy owner without relation to an Sx irp) and
the 2 can overlap. If you are the FDO, you control S0 idle policy and can
make assumptions. If you are the bus driver, you do not control s0 idle on
the child device and must not make any assumptions about s0 idle.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Tuesday, October 23, 2007 6:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] surprise removal in kmdf

In a blog post regarding surprise removal, Doron Holan said

----
http://blogs.msdn.com/doronh/archive/2007/02/26/which-callback-is-called-on-surprise-or-graceful-removal.aspx

Another potential solution is to register for EvtDeviceSurpriseRemoval or
implement IPnpCallback::OnSurpriseRemoval. This provides you with half the
solution, but ignores the other half of the problem, graceful removal. You
could track state in the surprise removal callback and then check this state
in your device’s cleanup routine/destructor. This does have the benefit of
working within the framework and its contracts, but it still requires you to
track state. Furthermore, the surprise removal callback is not synchronized
with the other power up/down callbacks which is another detractor.
----

I read this as “EvtDeviceSurpriseRemoval is not synchronized with
EvtDeviceD0Exit”.

But the WDK documentation also says

----
A user unplugs a device unexpectedly. The bus driver for the device’s bus
discovers that the device is missing and calls
WdfChildListUpdateChildDescriptionAsMissing.
For each function and filter driver that supports the device, the framework
does the following, in sequence, one driver at a time, starting with the
driver that is highest in the driver stack:
- The framework calls the driver’s EvtDeviceSurpriseRemoval callback
function (if it exists).
…
- The framework calls the driver’s EvtDeviceD0Exit callback function (if it
exists).
----

Am I missing something?

Have a nice day
GV

—
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

—
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

Gianluca_Varenni · October 24, 2007, 8:04pm

Wow, thanks!

I actually spent the afternoon with whiteboard+KISS (keep-it-simple-stupid).
I redesigned everything from scratch using a different approach: since I
have a driver thread who is actually the one dealing with the hw resources
of the two devices (and the thread is managed by a message queue), I just
send a DEVICE_ADDED message to my thread when a new device is ready to be
used (in EvtDeviceSelfManagedIoInit and Restart) and a DEVICE_REMOVED
message when the device is getting removed (in
EvtDeviceSelfManagedIoSuspend). The send message operation is blocking, so
by the time the send_message(DEVICE_REMOVED) returns, the driver thread is
no longer accessing the device hw resources.
Simple, it works so far (it’s under pnpdtest all the time).

I don’t know if this would be considered a “blessed design pattern”.

Thanks again for the help
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 24, 2007 3:57 PM
Subject: RE: [ntdev] surprise removal in kmdf

Here you go, this should help.

http://blogs.msdn.com/doronh/archive/2007/10/24/how-to-share-hw-resources-with-another-driver-not-in-the-same-pnp-hierarchy.aspx

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 1:45 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

I’m looking for a way to notify the owner of an io target that the target
device received a surprise removal before the target device itself executes
the sequence of operations to tear down everything (EvtIoStop,
EvtDeviceD0Exit and such).

Sorry for getting you so confused (I’m confused as well as to what I’m
doing, ouch).

Thanks again
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 24, 2007 12:39 PM
Subject: RE: [ntdev] surprise removal in kmdf

So why do you need to register for EvtDeviceSurpriseRemoval?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 12:35 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

I think I was not clear in my message. I meant exactly what you said (and i
think that lately my ability to clearly explain things has become worse and
worse…)

GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 24, 2007 12:24 PM
Subject: RE: [ntdev] surprise removal in kmdf

if the device you have an io target against is surprise removed, you get a
remove completed callback without the query remove callback. Failing an
iotarget query remove callback will not cause a surprise remove to occur.
The component which has the io target open should not care that the target
is surprise removed, only that it can get a RemoveComplete w/out a query
remove and then do the cleanup in the RemoveComplete that would have
happened in QueryRemove

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 11:42 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

An IoTarget has callbacks for the QueryRemove, RemoveCanceled and
RemoveComplete, but it doesn’t have a specific callback for SurpriseRemoval.
But as I write, it just came to my mind that I know if a surprise removal
happened because QueryRemove+RemoveCanceled (or none) got called before the
RemoveComplete

QueryRemove (with removal_ok), RemoveComplete –> graceful
removal
QueryRemove (with removal_ok), RemoveCanceled, RemoveComplete –> surprise
removal
Remove Complete –> surprise
removal

I’m still putting a lot of pieces of the PnP puzzle (in my mind) together.

As to what I’m trying to achieve, it’s a sort of driver-to-driver
communication issue (although there’s only one driver). The driver I’m
developing (an FDO driver) uses a driver thread to have two FDOs (managed by
the driver) exchange data between each other (a lot of data). I’m now
dealing with the problem of the two devices being added/removed/surprise
removed. I don’t have a definitive solution to it, mostly spending time in
trying different approaches (and reading a lot of documentation).

Thanks for the help
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 24, 2007 10:35 AM
Subject: RE: [ntdev] surprise removal in kmdf

Why do you need to register for EvtDeviceSurpriseREmoval in the first place?
What callback abstraction in KMDF is not tracking the state that you need on
your behalf?

The docs need a little bit of clarification, I will fwd that to the doc
writer

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 9:52 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

I’m the FDO and I don’t support S0 idle, so I can safely assume that the two
cannot overlap (can I assume that they are called in the
SurpriseRemoval…DeviceD0Exit order?).

My point is that the WDK documentation seems wrong

http://msdn2.microsoft.com/en-us/library/aa490095.aspx (Surprise Removal
paragraph)

Have a nice day
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, October 23, 2007 11:02 PM
Subject: RE: [ntdev] surprise removal in kmdf

EvtDeviceSurpriseRemoval is not synchronized with EvtDeviceD0Exit. If the
device stack does not support s0 idle, then the 2 cannot overlap b/c a
system power down (and thus a dx irp sent to the stack) cannot occur while
there is a state changing pnp irp pending. If s0 idle is enabled on the
device a dx irp can be sent during a pnp state changing irp (b/c it is sent
spontaneously by the power policy owner without relation to an Sx irp) and
the 2 can overlap. If you are the FDO, you control S0 idle policy and can
make assumptions. If you are the bus driver, you do not control s0 idle on
the child device and must not make any assumptions about s0 idle.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Tuesday, October 23, 2007 6:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] surprise removal in kmdf

In a blog post regarding surprise removal, Doron Holan said

----
http://blogs.msdn.com/doronh/archive/2007/02/26/which-callback-is-called-on-surprise-or-graceful-removal.aspx

Another potential solution is to register for EvtDeviceSurpriseRemoval or
implement IPnpCallback::OnSurpriseRemoval. This provides you with half the
solution, but ignores the other half of the problem, graceful removal. You
could track state in the surprise removal callback and then check this state
in your device’s cleanup routine/destructor. This does have the benefit of
working within the framework and its contracts, but it still requires you to
track state. Furthermore, the surprise removal callback is not synchronized
with the other power up/down callbacks which is another detractor.
----

I read this as “EvtDeviceSurpriseRemoval is not synchronized with
EvtDeviceD0Exit”.

But the WDK documentation also says

----
A user unplugs a device unexpectedly. The bus driver for the device’s bus
discovers that the device is missing and calls
WdfChildListUpdateChildDescriptionAsMissing.
For each function and filter driver that supports the device, the framework
does the following, in sequence, one driver at a time, starting with the
driver that is highest in the driver stack:
- The framework calls the driver’s EvtDeviceSurpriseRemoval callback
function (if it exists).
…
- The framework calls the driver’s EvtDeviceD0Exit callback function (if it
exists).
----

Am I missing something?

Have a nice day
GV

—
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

—
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

Doron_Holan · October 24, 2007, 8:28pm

If sending a message requires the allocation of memory, what do you do when you cannot allocate a DEVICE_REMOVED message?

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 5:03 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

Wow, thanks!

I actually spent the afternoon with whiteboard+KISS (keep-it-simple-stupid).
I redesigned everything from scratch using a different approach: since I
have a driver thread who is actually the one dealing with the hw resources
of the two devices (and the thread is managed by a message queue), I just
send a DEVICE_ADDED message to my thread when a new device is ready to be
used (in EvtDeviceSelfManagedIoInit and Restart) and a DEVICE_REMOVED
message when the device is getting removed (in
EvtDeviceSelfManagedIoSuspend). The send message operation is blocking, so
by the time the send_message(DEVICE_REMOVED) returns, the driver thread is
no longer accessing the device hw resources.
Simple, it works so far (it’s under pnpdtest all the time).

I don’t know if this would be considered a “blessed design pattern”.

Thanks again for the help
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 24, 2007 3:57 PM
Subject: RE: [ntdev] surprise removal in kmdf

Here you go, this should help.

http://blogs.msdn.com/doronh/archive/2007/10/24/how-to-share-hw-resources-with-another-driver-not-in-the-same-pnp-hierarchy.aspx

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 1:45 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

I’m looking for a way to notify the owner of an io target that the target
device received a surprise removal before the target device itself executes
the sequence of operations to tear down everything (EvtIoStop,
EvtDeviceD0Exit and such).

Sorry for getting you so confused (I’m confused as well as to what I’m
doing, ouch).

Thanks again
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 24, 2007 12:39 PM
Subject: RE: [ntdev] surprise removal in kmdf

So why do you need to register for EvtDeviceSurpriseRemoval?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 12:35 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

I think I was not clear in my message. I meant exactly what you said (and i
think that lately my ability to clearly explain things has become worse and
worse…)

GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 24, 2007 12:24 PM
Subject: RE: [ntdev] surprise removal in kmdf

if the device you have an io target against is surprise removed, you get a
remove completed callback without the query remove callback. Failing an
iotarget query remove callback will not cause a surprise remove to occur.
The component which has the io target open should not care that the target
is surprise removed, only that it can get a RemoveComplete w/out a query
remove and then do the cleanup in the RemoveComplete that would have
happened in QueryRemove

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 11:42 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

An IoTarget has callbacks for the QueryRemove, RemoveCanceled and
RemoveComplete, but it doesn’t have a specific callback for SurpriseRemoval.
But as I write, it just came to my mind that I know if a surprise removal
happened because QueryRemove+RemoveCanceled (or none) got called before the
RemoveComplete

QueryRemove (with removal_ok), RemoveComplete –> graceful
removal
QueryRemove (with removal_ok), RemoveCanceled, RemoveComplete –> surprise
removal
Remove Complete –> surprise
removal

I’m still putting a lot of pieces of the PnP puzzle (in my mind) together.

As to what I’m trying to achieve, it’s a sort of driver-to-driver
communication issue (although there’s only one driver). The driver I’m
developing (an FDO driver) uses a driver thread to have two FDOs (managed by
the driver) exchange data between each other (a lot of data). I’m now
dealing with the problem of the two devices being added/removed/surprise
removed. I don’t have a definitive solution to it, mostly spending time in
trying different approaches (and reading a lot of documentation).

Thanks for the help
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 24, 2007 10:35 AM
Subject: RE: [ntdev] surprise removal in kmdf

Why do you need to register for EvtDeviceSurpriseREmoval in the first place?
What callback abstraction in KMDF is not tracking the state that you need on
your behalf?

The docs need a little bit of clarification, I will fwd that to the doc
writer

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 9:52 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

I’m the FDO and I don’t support S0 idle, so I can safely assume that the two
cannot overlap (can I assume that they are called in the
SurpriseRemoval…DeviceD0Exit order?).

My point is that the WDK documentation seems wrong

http://msdn2.microsoft.com/en-us/library/aa490095.aspx (Surprise Removal
paragraph)

Have a nice day
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, October 23, 2007 11:02 PM
Subject: RE: [ntdev] surprise removal in kmdf

EvtDeviceSurpriseRemoval is not synchronized with EvtDeviceD0Exit. If the
device stack does not support s0 idle, then the 2 cannot overlap b/c a
system power down (and thus a dx irp sent to the stack) cannot occur while
there is a state changing pnp irp pending. If s0 idle is enabled on the
device a dx irp can be sent during a pnp state changing irp (b/c it is sent
spontaneously by the power policy owner without relation to an Sx irp) and
the 2 can overlap. If you are the FDO, you control S0 idle policy and can
make assumptions. If you are the bus driver, you do not control s0 idle on
the child device and must not make any assumptions about s0 idle.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Tuesday, October 23, 2007 6:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] surprise removal in kmdf

In a blog post regarding surprise removal, Doron Holan said

----
http://blogs.msdn.com/doronh/archive/2007/02/26/which-callback-is-called-on-surprise-or-graceful-removal.aspx

Another potential solution is to register for EvtDeviceSurpriseRemoval or
implement IPnpCallback::OnSurpriseRemoval. This provides you with half the
solution, but ignores the other half of the problem, graceful removal. You
could track state in the surprise removal callback and then check this state
in your device’s cleanup routine/destructor. This does have the benefit of
working within the framework and its contracts, but it still requires you to
track state. Furthermore, the surprise removal callback is not synchronized
with the other power up/down callbacks which is another detractor.
----

I read this as “EvtDeviceSurpriseRemoval is not synchronized with
EvtDeviceD0Exit”.

But the WDK documentation also says

----
A user unplugs a device unexpectedly. The bus driver for the device’s bus
discovers that the device is missing and calls
WdfChildListUpdateChildDescriptionAsMissing.
For each function and filter driver that supports the device, the framework
does the following, in sequence, one driver at a time, starting with the
driver that is highest in the driver stack:
- The framework calls the driver’s EvtDeviceSurpriseRemoval callback
function (if it exists).
…
- The framework calls the driver’s EvtDeviceD0Exit callback function (if it
exists).
----

Am I missing something?

Have a nice day
GV

—
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

—
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

—
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

Gianluca_Varenni · October 24, 2007, 9:13pm

No allocation is required to send such messages. Sending messages cannot
fail. The msg queue is actually a ring buffer and the worst thing that can
happen is sendmessage needing to wait a little bit for a slot in the queue
to be available (which is something that should never happen in practice,
given that messages are not used frequently in the driver).

Have a nice day
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 24, 2007 5:25 PM
Subject: RE: [ntdev] surprise removal in kmdf

If sending a message requires the allocation of memory, what do you do when
you cannot allocate a DEVICE_REMOVED message?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 5:03 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

Wow, thanks!

I actually spent the afternoon with whiteboard+KISS (keep-it-simple-stupid).
I redesigned everything from scratch using a different approach: since I
have a driver thread who is actually the one dealing with the hw resources
of the two devices (and the thread is managed by a message queue), I just
send a DEVICE_ADDED message to my thread when a new device is ready to be
used (in EvtDeviceSelfManagedIoInit and Restart) and a DEVICE_REMOVED
message when the device is getting removed (in
EvtDeviceSelfManagedIoSuspend). The send message operation is blocking, so
by the time the send_message(DEVICE_REMOVED) returns, the driver thread is
no longer accessing the device hw resources.
Simple, it works so far (it’s under pnpdtest all the time).

I don’t know if this would be considered a “blessed design pattern”.

Thanks again for the help
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 24, 2007 3:57 PM
Subject: RE: [ntdev] surprise removal in kmdf

Here you go, this should help.

http://blogs.msdn.com/doronh/archive/2007/10/24/how-to-share-hw-resources-with-another-driver-not-in-the-same-pnp-hierarchy.aspx

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 1:45 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

I’m looking for a way to notify the owner of an io target that the target
device received a surprise removal before the target device itself executes
the sequence of operations to tear down everything (EvtIoStop,
EvtDeviceD0Exit and such).

Sorry for getting you so confused (I’m confused as well as to what I’m
doing, ouch).

Thanks again
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 24, 2007 12:39 PM
Subject: RE: [ntdev] surprise removal in kmdf

So why do you need to register for EvtDeviceSurpriseRemoval?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 12:35 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

I think I was not clear in my message. I meant exactly what you said (and i
think that lately my ability to clearly explain things has become worse and
worse…)

GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 24, 2007 12:24 PM
Subject: RE: [ntdev] surprise removal in kmdf

if the device you have an io target against is surprise removed, you get a
remove completed callback without the query remove callback. Failing an
iotarget query remove callback will not cause a surprise remove to occur.
The component which has the io target open should not care that the target
is surprise removed, only that it can get a RemoveComplete w/out a query
remove and then do the cleanup in the RemoveComplete that would have
happened in QueryRemove

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 11:42 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

An IoTarget has callbacks for the QueryRemove, RemoveCanceled and
RemoveComplete, but it doesn’t have a specific callback for SurpriseRemoval.
But as I write, it just came to my mind that I know if a surprise removal
happened because QueryRemove+RemoveCanceled (or none) got called before the
RemoveComplete

QueryRemove (with removal_ok), RemoveComplete –> graceful
removal
QueryRemove (with removal_ok), RemoveCanceled, RemoveComplete –> surprise
removal
Remove Complete –> surprise
removal

I’m still putting a lot of pieces of the PnP puzzle (in my mind) together.

As to what I’m trying to achieve, it’s a sort of driver-to-driver
communication issue (although there’s only one driver). The driver I’m
developing (an FDO driver) uses a driver thread to have two FDOs (managed by
the driver) exchange data between each other (a lot of data). I’m now
dealing with the problem of the two devices being added/removed/surprise
removed. I don’t have a definitive solution to it, mostly spending time in
trying different approaches (and reading a lot of documentation).

Thanks for the help
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 24, 2007 10:35 AM
Subject: RE: [ntdev] surprise removal in kmdf

Why do you need to register for EvtDeviceSurpriseREmoval in the first place?
What callback abstraction in KMDF is not tracking the state that you need on
your behalf?

The docs need a little bit of clarification, I will fwd that to the doc
writer

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Wednesday, October 24, 2007 9:52 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] surprise removal in kmdf

I’m the FDO and I don’t support S0 idle, so I can safely assume that the two
cannot overlap (can I assume that they are called in the
SurpriseRemoval…DeviceD0Exit order?).

My point is that the WDK documentation seems wrong

http://msdn2.microsoft.com/en-us/library/aa490095.aspx (Surprise Removal
paragraph)

Have a nice day
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, October 23, 2007 11:02 PM
Subject: RE: [ntdev] surprise removal in kmdf

EvtDeviceSurpriseRemoval is not synchronized with EvtDeviceD0Exit. If the
device stack does not support s0 idle, then the 2 cannot overlap b/c a
system power down (and thus a dx irp sent to the stack) cannot occur while
there is a state changing pnp irp pending. If s0 idle is enabled on the
device a dx irp can be sent during a pnp state changing irp (b/c it is sent
spontaneously by the power policy owner without relation to an Sx irp) and
the 2 can overlap. If you are the FDO, you control S0 idle policy and can
make assumptions. If you are the bus driver, you do not control s0 idle on
the child device and must not make any assumptions about s0 idle.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Tuesday, October 23, 2007 6:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] surprise removal in kmdf

In a blog post regarding surprise removal, Doron Holan said

----
http://blogs.msdn.com/doronh/archive/2007/02/26/which-callback-is-called-on-surprise-or-graceful-removal.aspx

Another potential solution is to register for EvtDeviceSurpriseRemoval or
implement IPnpCallback::OnSurpriseRemoval. This provides you with half the
solution, but ignores the other half of the problem, graceful removal. You
could track state in the surprise removal callback and then check this state
in your device’s cleanup routine/destructor. This does have the benefit of
working within the framework and its contracts, but it still requires you to
track state. Furthermore, the surprise removal callback is not synchronized
with the other power up/down callbacks which is another detractor.
----

I read this as “EvtDeviceSurpriseRemoval is not synchronized with
EvtDeviceD0Exit”.

But the WDK documentation also says

----
A user unplugs a device unexpectedly. The bus driver for the device’s bus
discovers that the device is missing and calls
WdfChildListUpdateChildDescriptionAsMissing.
For each function and filter driver that supports the device, the framework
does the following, in sequence, one driver at a time, starting with the
driver that is highest in the driver stack:
- The framework calls the driver’s EvtDeviceSurpriseRemoval callback
function (if it exists).
…
- The framework calls the driver’s EvtDeviceD0Exit callback function (if it
exists).
----

Am I missing something?

Have a nice day
GV

—
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

—
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

—
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

Maxim_S_Shatskih · October 25, 2007, 5:55am

> of the two devices (and the thread is managed by a message queue), I just

send a DEVICE_ADDED message to my thread when a new device is ready to be
used (in EvtDeviceSelfManagedIoInit and Restart) and a DEVICE_REMOVED
message when the device is getting removed (in
EvtDeviceSelfManagedIoSuspend). The send message operation is blocking,

Why not use device interface arrival/removal notifications instead? they are
the same and are already implemented in the OS.

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

Doron_Holan · October 25, 2007, 12:00pm

Max, please read the entire thread as to why interface notifications is not sufficient. He needs to notify the external driver on every device power up/down and interface notifications are only sent when the device appears and disappears. I would agree that the names of the messages make this confusing, but in this case DEVICE_ADDED == device has power, DEVICE_REMOVED == device has no power.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Thursday, October 25, 2007 2:55 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] surprise removal in kmdf

of the two devices (and the thread is managed by a message queue), I just
send a DEVICE_ADDED message to my thread when a new device is ready to be
used (in EvtDeviceSelfManagedIoInit and Restart) and a DEVICE_REMOVED
message when the device is getting removed (in
EvtDeviceSelfManagedIoSuspend). The send message operation is blocking,

Why not use device interface arrival/removal notifications instead? they are
the same and are already implemented in the OS.

–
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

Gianluca_Varenni · October 25, 2007, 12:14pm

The device interface removal notification gets sent too late, *after* the
REMOVE_DEVICE has been processed (or even, the two notifications are not
synchronized at all).

GV

----- Original Message -----
From: “Maxim S. Shatskih”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Thursday, October 25, 2007 2:55 AM
Subject: Re:[ntdev] surprise removal in kmdf

>> of the two devices (and the thread is managed by a message queue), I just
>> send a DEVICE_ADDED message to my thread when a new device is ready to be
>> used (in EvtDeviceSelfManagedIoInit and Restart) and a DEVICE_REMOVED
>> message when the device is getting removed (in
>> EvtDeviceSelfManagedIoSuspend). The send message operation is blocking,
>
> Why not use device interface arrival/removal notifications instead? they
> are
> the same and are already implemented in the OS.
>
> –
> 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

Gianluca_Varenni · October 25, 2007, 12:16pm

My bad, I used confusing names in the mail. The actual names of the messages
are POWER_UP_FDO and POWER_DOWN_FDO.

GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Thursday, October 25, 2007 8:56 AM
Subject: RE: Re:[ntdev] surprise removal in kmdf

Max, please read the entire thread as to why interface notifications is not
sufficient. He needs to notify the external driver on every device power
up/down and interface notifications are only sent when the device appears
and disappears. I would agree that the names of the messages make this
confusing, but in this case DEVICE_ADDED == device has power, DEVICE_REMOVED
== device has no power.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Thursday, October 25, 2007 2:55 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] surprise removal in kmdf

> of the two devices (and the thread is managed by a message queue), I just
> send a DEVICE_ADDED message to my thread when a new device is ready to be
> used (in EvtDeviceSelfManagedIoInit and Restart) and a DEVICE_REMOVED
> message when the device is getting removed (in
> EvtDeviceSelfManagedIoSuspend). The send message operation is blocking,

Why not use device interface arrival/removal notifications instead? they are
the same and are already implemented in the OS.

–
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

—
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