Selective suspend and surpsise removal

Michal_Vodicka-2 · October 6, 2005, 12:03am

Year before I posted here a decription of the problem which causes OS deadlock at XP SP2 when USB selective suspend is used and device is surprise removed in the "right" moment. We discussed it but no solution was found and I postponed it because of other work. Now the updated driver should be signed again and I'd like to solve the problem before.

Basically, my questions are:

How should USB driver correctly handle SS cancellation?
How WDF handles SS cancellation and how it behaves in below scenario?
Is there any solution which'd work for both XP SP2 and pre-SP2 USB versions?

Currently, my driver handles SS cancellation as I was adviced by USB core team member:

Once your callback is invoked do not cancel your IDLE irp.

If your callback is invoked and you want to cancel your IDLE irp,
etc, stay in D0, do not go to D2.

If you want to cancel your IDLE irp after going to D2 in your
callback send a D0 irp to the bus driver.

It differs from DDK samples; I had to change them because there were race conditions leading to non-functional device at pre-SP2 XP. Also, DDK samples, which cancel IDLE IRP, violate what DDK docs says (basically #1 above). The deadlock I mentioned occurs because OS never completes D0 IRP sent to cancel IDLE IRP (#3) when surpsise removal occurs in parallel. I'll cite the scenario from my original mail:

Normal situation:

IDLE notification callback is called
callback sends D2 IRP and waits until completed
IDLE notification callback finishes
device is physically disconnected
IDLE IRP completion routine is called
completion routine sends D0 IRP
D0 IRP is completed
driver receives few PnP IRPs and finally surprise removal
driver waits until all requests complete, makes cleanup and passes IRP below
driver receives device removal IRP, finishes processing and everything is OK

Now remove device a bit sooner:

IDLE notification callback is called
2 - 3. callback sends D2 IRP and waits until completed
2 - 3. device is physically disconnected
driver receives the first PnP IRP from the removal series (IRP_MN_QUERY_DEVICE_RELATIONS)
driver finds IDLE IRP isn't completed, yet and tries to cancel it. Because callback was already called, it sends D0 IRP down the stack to achieve it.
driver receives next PnP IRP and finally surprise removal
driver waits until both D0 and IDLE IRPs are completed and waits forever because they aren't.

OK, postpone waiting as late as possible:
7. driver doesn't wait, makes cleanup and passes IRP below, instead
8. driver receives device removal IRP, finishes processing and waits for D0 and IDLE IRPs
9. IDLE IRP is completed
10. driver still waits for D0 IRP completion and waits forever

Some times I measured:

Typical order of event with boundary timing (correct run). Device disconnect is scheduled circa 700 ms after idle IRP submit:

T + 0: driver submits idle IRP
T + 650 ms: idle callback starts and sends D2 IRP
T + 660 ms: D2 IRP is completed and idle callback finishes
T + 700 ms: device is physically disconnected
T + 900 ms: idle IRP is completed with cancelled status
T + 1400 ms: surprise removal IRP is received

Now the same scenario when device disconnect is scheduled to T + 600 ms:

T + 0: driver submits idle IRP
T + 600 ms: device is physically disconnected
T + 700 ms: idle callback starts and sends D2 IRP
T + 1200 ms: D2 IRP is completed and idle callback finishes
T + 1600 ms: surprise removal IRP is received

IDLE IRP isn't completed by system so PnP IRP handler has to cancel it. I follow DDK docs and above advice and send D0 IRP instead of its cancellation. D0 IRP is never completed in this situation which finally causes OS deadlock.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Michal_Vodicka-2 · October 6, 2005, 3:52pm

Nobody? OK, I have a crazy idea. What if my driver detects deacklock (device removal IRP received and D0 still pending) and tries to solve it? Is it possible and safe to cancel D0 IRP which is blocked by some OS driver below mine?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Michal Vodicka[SMTP:xxxxx@upek.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, October 06, 2005 6:03 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Selective suspend and surpsise removal

Year before I posted here a decription of the problem which causes OS deadlock at XP SP2 when USB selective suspend is used and device is surprise removed in the “right” moment. We discussed it but no solution was found and I postponed it because of other work. Now the updated driver should be signed again and I’d like to solve the problem before.

Basically, my questions are:

How should USB driver correctly handle SS cancellation?

How WDF handles SS cancellation and how it behaves in below scenario?

Is there any solution which’d work for both XP SP2 and pre-SP2 USB versions?

Currently, my driver handles SS cancellation as I was adviced by USB core team member:

> 1) Once your callback is invoked do not cancel your IDLE irp.
> 2) If your callback is invoked and you want to cancel your IDLE irp,
> etc, stay in D0, do not go to D2.
> 3) If you want to cancel your IDLE irp after going to D2 in your
> callback send a D0 irp to the bus driver.
>
It differs from DDK samples; I had to change them because there were race conditions leading to non-functional device at pre-SP2 XP. Also, DDK samples, which cancel IDLE IRP, violate what DDK docs says (basically #1 above). The deadlock I mentioned occurs because OS never completes D0 IRP sent to cancel IDLE IRP (#3) when surpsise removal occurs in parallel. I’ll cite the scenario from my original mail:

Normal situation:

IDLE notification callback is called

callback sends D2 IRP and waits until completed

IDLE notification callback finishes

device is physically disconnected

IDLE IRP completion routine is called

completion routine sends D0 IRP

D0 IRP is completed

driver receives few PnP IRPs and finally surprise removal

driver waits until all requests complete, makes cleanup and passes IRP below

driver receives device removal IRP, finishes processing and everything is OK

Now remove device a bit sooner:

IDLE notification callback is called
2 - 3. callback sends D2 IRP and waits until completed
2 - 3. device is physically disconnected

driver receives the first PnP IRP from the removal series (IRP_MN_QUERY_DEVICE_RELATIONS)

driver finds IDLE IRP isn’t completed, yet and tries to cancel it. Because callback was already called, it sends D0 IRP down the stack to achieve it.

driver receives next PnP IRP and finally surprise removal

driver waits until both D0 and IDLE IRPs are completed and waits forever because they aren’t.

OK, postpone waiting as late as possible:
7. driver doesn’t wait, makes cleanup and passes IRP below, instead
8. driver receives device removal IRP, finishes processing and waits for D0 and IDLE IRPs
9. IDLE IRP is completed
10. driver still waits for D0 IRP completion and waits forever

Some times I measured:

Typical order of event with boundary timing (correct run). Device disconnect is scheduled circa 700 ms after idle IRP submit:

T + 0: driver submits idle IRP
T + 650 ms: idle callback starts and sends D2 IRP
T + 660 ms: D2 IRP is completed and idle callback finishes
T + 700 ms: device is physically disconnected
T + 900 ms:> idle IRP is completed with cancelled status
T + 1400 ms: surprise removal IRP is received

Now the same scenario when device disconnect is scheduled to T + 600 ms:

T + 0: driver submits idle IRP
T + 600 ms: device is physically disconnected
T + 700 ms: idle callback starts and sends D2 IRP
T + 1200 ms: D2 IRP is completed and idle callback finishes
T + 1600 ms: surprise removal IRP is received

IDLE IRP isn’t completed by system so PnP IRP handler has to cancel it. I follow DDK docs and above advice and send D0 IRP instead of its cancellation. D0 IRP is never completed in this situation which finally causes OS deadlock.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Doron_Holan · October 6, 2005, 4:00pm

I have never heard of canceling a device power irp (while it is common
to do for a wait wake irp), but I guess it could be done. You would
probably run into very untested territory b/c no client before will have
done this.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, October 06, 2005 12:52 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

Nobody? OK, I have a crazy idea. What if my driver detects deacklock
(device removal IRP received and D0 still pending) and tries to solve
it? Is it possible and safe to cancel D0 IRP which is blocked by some OS
driver below mine?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Michal Vodicka[SMTP:xxxxx@upek.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, October 06, 2005 6:03 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Selective suspend and surpsise removal

Year before I posted here a decription of the problem which causes OS
deadlock at XP SP2 when USB selective suspend is used and device is
surprise removed in the “right” moment. We discussed it but no solution
was found and I postponed it because of other work. Now the updated
driver should be signed again and I’d like to solve the problem before.

Basically, my questions are:

How should USB driver correctly handle SS cancellation?

How WDF handles SS cancellation and how it behaves in below
scenario?

Is there any solution which’d work for both XP SP2 and pre-SP2 USB
versions?

Currently, my driver handles SS cancellation as I was adviced by USB
core team member:

> 1) Once your callback is invoked do not cancel your IDLE irp.
> 2) If your callback is invoked and you want to cancel your IDLE irp,
> etc, stay in D0, do not go to D2.
> 3) If you want to cancel your IDLE irp after going to D2 in your
> callback send a D0 irp to the bus driver.
>
It differs from DDK samples; I had to change them because there were
race conditions leading to non-functional device at pre-SP2 XP. Also,
DDK samples, which cancel IDLE IRP, violate what DDK docs says
(basically #1 above). The deadlock I mentioned occurs because OS never
completes D0 IRP sent to cancel IDLE IRP (#3) when surpsise removal
occurs in parallel. I’ll cite the scenario from my original mail:

Normal situation:

IDLE notification callback is called

callback sends D2 IRP and waits until completed

IDLE notification callback finishes

device is physically disconnected

IDLE IRP completion routine is called

completion routine sends D0 IRP

D0 IRP is completed

driver receives few PnP IRPs and finally surprise removal

driver waits until all requests complete, makes cleanup and passes
IRP below

driver receives device removal IRP, finishes processing and
everything is OK

Now remove device a bit sooner:

IDLE notification callback is called
2 - 3. callback sends D2 IRP and waits until completed
2 - 3. device is physically disconnected

driver receives the first PnP IRP from the removal series
(IRP_MN_QUERY_DEVICE_RELATIONS)

driver finds IDLE IRP isn’t completed, yet and tries to cancel it.
Because callback was already called, it sends D0 IRP down the stack to
achieve it.

driver receives next PnP IRP and finally surprise removal

driver waits until both D0 and IDLE IRPs are completed and waits
forever because they aren’t.

OK, postpone waiting as late as possible:
7. driver doesn’t wait, makes cleanup and passes IRP below, instead
8. driver receives device removal IRP, finishes processing and waits
for D0 and IDLE IRPs
9. IDLE IRP is completed
10. driver still waits for D0 IRP completion and waits forever

Some times I measured:

Typical order of event with boundary timing (correct run). Device
disconnect is scheduled circa 700 ms after idle IRP submit:

T + 0: driver submits idle IRP
T + 650 ms: idle callback starts and sends D2 IRP
T + 660 ms: D2 IRP is completed and idle callback finishes
T + 700 ms: device is physically disconnected
T + 900 ms:> idle IRP is completed with cancelled status
T + 1400 ms: surprise removal IRP is received

Now the same scenario when device disconnect is scheduled to T + 600
ms:

T + 0: driver submits idle IRP
T + 600 ms: device is physically disconnected
T + 700 ms: idle callback starts and sends D2 IRP
T + 1200 ms: D2 IRP is completed and idle callback finishes
T + 1600 ms: surprise removal IRP is received

IDLE IRP isn’t completed by system so PnP IRP handler has to cancel
it. I follow DDK docs and above advice and send D0 IRP instead of its
cancellation. D0 IRP is never completed in this situation which finally
causes OS deadlock.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Michal_Vodicka-2 · October 6, 2005, 4:36pm

Well, I’ll try it and expect nice BSOD Seriously, this is rather desperate attempt to make a workaround. Do you have an answer to questions in the original mail? The problem is what is in the DDK doesn’t work, the advice I got doesn’t work and DDK samples don’t work so I feel a bit unsupported… How did you solve it in WDF?

Problem is rare but serious as the deadlock in power path causes inability to change power state and in turn power drain in notebooks when user expects suspend or hibernation when lid is closed. Ironically, we as firmware developers are most affected because every firmware update needs device reset and surprise removal. Everything depends on timing and machine or HC so somebody has few deadlocks per week and others never saw deadlock at all.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, October 06, 2005 9:57 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

I have never heard of canceling a device power irp (while it is common
to do for a wait wake irp), but I guess it could be done. You would
probably run into very untested territory b/c no client before will have
done this.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, October 06, 2005 12:52 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

Nobody? OK, I have a crazy idea. What if my driver detects deacklock
(device removal IRP received and D0 still pending) and tries to solve
it? Is it possible and safe to cancel D0 IRP which is blocked by some OS
driver below mine?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

> ----------
> From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Michal Vodicka[SMTP:xxxxx@upek.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Thursday, October 06, 2005 6:03 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Selective suspend and surpsise removal
>
> Year before I posted here a decription of the problem which causes OS
deadlock at XP SP2 when USB selective suspend is used and device is
surprise removed in the “right” moment. We discussed it but no solution
was found and I postponed it because of other work. Now the updated
driver should be signed again and I’d like to solve the problem before.
>
> Basically, my questions are:
>
> 1. How should USB driver correctly handle SS cancellation?
> 2. How WDF handles SS cancellation and how it behaves in below
scenario?
> 3. Is there any solution which’d work for both XP SP2 and pre-SP2 USB
versions?
>
> Currently, my driver handles SS cancellation as I was adviced by USB
core team member:
>
> > 1) Once your callback is invoked do not cancel your IDLE irp.
> > 2) If your callback is invoked and you want to cancel your IDLE irp,
> > etc, stay in D0, do not go to D2.
> > 3) If you want to cancel your IDLE irp after going to D2 in your
> > callback send a D0 irp to the bus driver.
> >
> It differs from DDK samples; I had to change them because there were
race conditions leading to non-functional device at pre-SP2 XP. Also,
DDK samples, which cancel IDLE IRP, violate what DDK docs says
(basically #1 above). The deadlock I mentioned occurs because OS never
completes D0 IRP sent to cancel IDLE IRP (#3) when surpsise removal>
occurs in parallel. I’ll cite the scenario from my original mail:
>
> ----
> Normal situation:
> 1. IDLE notification callback is called
> 2. callback sends D2 IRP and waits until completed
> 3. IDLE notification callback finishes
> 4. device is physically disconnected
> 5. IDLE IRP completion routine is called
> 6. completion routine sends D0 IRP
> 7. D0 IRP is completed
> 8. driver receives few PnP IRPs and finally surprise removal
> 9. driver waits until all requests complete, makes cleanup and passes
IRP below
> 10. driver receives device removal IRP, finishes processing and
everything is OK
>
> Now remove device a bit sooner:
> 1. IDLE notification callback is called
> 2 - 3. callback sends D2 IRP and waits until completed
> 2 - 3. device is physically disconnected
> 4. driver receives the first PnP IRP from the removal series
(IRP_MN_QUERY_DEVICE_RELATIONS)
> 5. driver finds IDLE IRP isn’t completed, yet and tries to cancel it.
Because callback was already called, it sends D0 IRP down the stack to
achieve it.
> 6. driver receives next PnP IRP and finally surprise removal
> 7. driver waits until both D0 and IDLE IRPs are completed and waits
forever because they aren’t.
>
> OK, postpone waiting as late as possible:
> 7. driver doesn’t wait, makes cleanup and passes IRP below, instead
> 8. driver receives device removal IRP, finishes processing and waits
for D0 and IDLE IRPs
> 9. IDLE IRP is completed
> 10. driver still waits for D0 IRP completion and waits forever
> ----
>
> Some times I measured:
>
> Typical order of event with boundary timing (correct run). Device
disconnect is scheduled circa 700 ms after idle IRP submit:
>
> T + 0: driver submits idle IRP
> T + 650 ms: idle callback starts and sends D2 IRP
> T + 660 ms: D2 IRP is completed and idle callback finishes
> T + 700 ms: device is physically disconnected
> T + 900 ms:> idle IRP is completed with cancelled status
> T + 1400 ms: surprise removal IRP is received
>
> Now the same scenario when device disconnect is scheduled to T + 600
ms:
>
> T + 0: driver submits idle IRP
> T + 600 ms: device is physically disconnected
> T + 700 ms: idle callback starts and sends D2 IRP
> T + 1200 ms: D2 IRP is completed and idle callback finishes
> T + 1600 ms: surprise removal IRP is received
>
> IDLE IRP isn’t completed by system so PnP IRP handler has to cancel
it. I follow DDK docs and above advice and send D0 IRP instead of its
cancellation. D0 IRP is never completed in this situation which finally
causes OS deadlock.
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Doron_Holan · October 6, 2005, 5:14pm

In WDF if the device get’s a surprise remove, we wait for all pending
power operations to complete before sending the s.r. irp down the stack.
That includes cancellation of the SS irp and/or not powering down in the
callback in that state if the cancellation fails.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, October 06, 2005 1:36 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

Well, I’ll try it and expect nice BSOD Seriously, this is rather
desperate attempt to make a workaround. Do you have an answer to
questions in the original mail? The problem is what is in the DDK
doesn’t work, the advice I got doesn’t work and DDK samples don’t work
so I feel a bit unsupported… How did you solve it in WDF?

Problem is rare but serious as the deadlock in power path causes
inability to change power state and in turn power drain in notebooks
when user expects suspend or hibernation when lid is closed. Ironically,
we as firmware developers are most affected because every firmware
update needs device reset and surprise removal. Everything depends on
timing and machine or HC so somebody has few deadlocks per week and
others never saw deadlock at all.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, October 06, 2005 9:57 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

I have never heard of canceling a device power irp (while it is common
to do for a wait wake irp), but I guess it could be done. You would
probably run into very untested territory b/c no client before will
have
done this.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, October 06, 2005 12:52 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

Nobody? OK, I have a crazy idea. What if my driver detects deacklock
(device removal IRP received and D0 still pending) and tries to solve
it? Is it possible and safe to cancel D0 IRP which is blocked by some
OS
driver below mine?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

> ----------
> From:

xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com

] on behalf of Michal Vodicka[SMTP:xxxxx@upek.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Thursday, October 06, 2005 6:03 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Selective suspend and surpsise removal
>
> Year before I posted here a decription of the problem which causes
OS
deadlock at XP SP2 when USB selective suspend is used and device is
surprise removed in the “right” moment. We discussed it but no
solution
was found and I postponed it because of other work. Now the updated
driver should be signed again and I’d like to solve the problem
before.
>
> Basically, my questions are:
>
> 1. How should USB driver correctly handle SS cancellation?
> 2. How WDF handles SS cancellation and how it behaves in below
scenario?
> 3. Is there any solution which’d work for both XP SP2 and pre-SP2
USB
versions?
>
> Currently, my driver handles SS cancellation as I was adviced by USB
core team member:
>
> > 1) Once your callback is invoked do not cancel your IDLE irp.
> > 2) If your callback is invoked and you want to cancel your IDLE
irp,
> > etc, stay in D0, do not go to D2.
> > 3) If you want to cancel your IDLE irp after going to D2 in your
> > callback send a D0 irp to the bus driver.
> >
> It differs from DDK samples; I had to change them because there were
race conditions leading to non-functional device at pre-SP2 XP. Also,
DDK samples, which cancel IDLE IRP, violate what DDK docs says
(basically #1 above). The deadlock I mentioned occurs because OS never
completes D0 IRP sent to cancel IDLE IRP (#3) when surpsise removal>
occurs in parallel. I’ll cite the scenario from my original mail:
>
> ----
> Normal situation:
> 1. IDLE notification callback is called
> 2. callback sends D2 IRP and waits until completed
> 3. IDLE notification callback finishes
> 4. device is physically disconnected
> 5. IDLE IRP completion routine is called
> 6. completion routine sends D0 IRP
> 7. D0 IRP is completed
> 8. driver receives few PnP IRPs and finally surprise removal
> 9. driver waits until all requests complete, makes cleanup and
passes
IRP below
> 10. driver receives device removal IRP, finishes processing and
everything is OK
>
> Now remove device a bit sooner:
> 1. IDLE notification callback is called
> 2 - 3. callback sends D2 IRP and waits until completed
> 2 - 3. device is physically disconnected
> 4. driver receives the first PnP IRP from the removal series
(IRP_MN_QUERY_DEVICE_RELATIONS)
> 5. driver finds IDLE IRP isn’t completed, yet and tries to cancel
it.
Because callback was already called, it sends D0 IRP down the stack to
achieve it.
> 6. driver receives next PnP IRP and finally surprise removal
> 7. driver waits until both D0 and IDLE IRPs are completed and waits
forever because they aren’t.
>
> OK, postpone waiting as late as possible:
> 7. driver doesn’t wait, makes cleanup and passes IRP below, instead
> 8. driver receives device removal IRP, finishes processing and waits
for D0 and IDLE IRPs
> 9. IDLE IRP is completed
> 10. driver still waits for D0 IRP completion and waits forever
> ----
>
> Some times I measured:
>
> Typical order of event with boundary timing (correct run). Device
disconnect is scheduled circa 700 ms after idle IRP submit:
>
> T + 0: driver submits idle IRP
> T + 650 ms: idle callback starts and sends D2 IRP
> T + 660 ms: D2 IRP is completed and idle callback finishes
> T + 700 ms: device is physically disconnected
> T + 900 ms:> idle IRP is completed with cancelled status
> T + 1400 ms: surprise removal IRP is received
>
> Now the same scenario when device disconnect is scheduled to T + 600
ms:
>
> T + 0: driver submits idle IRP
> T + 600 ms: device is physically disconnected
> T + 700 ms: idle callback starts and sends D2 IRP
> T + 1200 ms: D2 IRP is completed and idle callback finishes
> T + 1600 ms: surprise removal IRP is received
>
> IDLE IRP isn’t completed by system so PnP IRP handler has to cancel
it. I follow DDK docs and above advice and send D0 IRP instead of its
cancellation. D0 IRP is never completed in this situation which
finally
causes OS deadlock.
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
> To unsubscribe send a blank email to
xxxxx@lists.osr.com
>

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

You are currently subscribed to ntdev as: unknown lmsubst tag
argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Michal_Vodicka-2 · October 6, 2005, 5:28pm

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, October 06, 2005 11:12 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

In WDF if the device get’s a surprise remove, we wait for all pending
power operations to complete before sending the s.r. irp down the stack.
That includes cancellation of the SS irp and/or not powering down in the
callback in that state if the cancellation fails.

Should I take it as approved and supported way? What if the IDLE callback was already called or is called in parallel with surprise removal? DDK docs states:
A function driver may cancel the idle request after it has been made, but must do so before the hub driver calls the callback routine.
Simple cases aren’t the problem, race conditions are. If you cancel IDLE IRP always and don’t care about callback call, it can lead to non-functional device which stays in low power state. At least at pre-SP2 XP.
Do you have finite state machine which handles SS in WDF? If so, can you post it?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Doron_Holan · October 6, 2005, 5:45pm

I do have a finite state machine that handles USB SS, but it is
integrated wholly into the WDF power policy state machine. The pwr pol
state machine is completely tied to the finite state machines for both
pnp and power. Basically, there is a lot to digest and I don’t know if
a snippet, or even one of the 3 is helpful on a micro level. Also,
there may be legal issues about what I can give out, I will have to ask.
I will gladly send them to you if I am allowed.

As for a sanctioned design, I can’t say either way. From our testing,
what I have written works and we have hit some of the race conditions
you mentioned during our tests.

I can tell you what the design is though. Power policy has the concept
of locked transitions. For instance, once we send a Dx irp to the
stack, we lock out any other events until that transition is complete.
That means that if a s.r. came in right after we decided to power down,
we will process the power down to its completion before we process the
s.r. irp. Now we must consider idling out and wake capable while the
machine is in S0 for both the USB SS case and then non USB SS case. In
the non USB SS case, it is simply a matter of locking up the queue,
sending a WW irp, sending a Dx irp, unlocking the queue. In the USB SS
case, there are more exit points, it is essentially

send USB SS irp (queue not locked)
if the callback is called, then do the non USB SS actions described,
then return from the callback

Now, if we need to power up or abort and we are in state 1), we lock the
queue and cancel the usb ss irp. If the cancellation fails, it is b/c a
callback is imminent, so we wait for the callback. When the callback is
invoked, we just return from the callback and then unlock the queue and
proceed on.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, October 06, 2005 2:28 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, October 06, 2005 11:12 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

In WDF if the device get’s a surprise remove, we wait for all pending
power operations to complete before sending the s.r. irp down the
stack.
That includes cancellation of the SS irp and/or not powering down in
the
callback in that state if the cancellation fails.

Should I take it as approved and supported way? What if the IDLE
callback was already called or is called in parallel with surprise
removal? DDK docs states:
A function driver may cancel the idle request after it has been made,
but must do so before the hub driver calls the callback routine.
Simple cases aren’t the problem, race conditions are. If you cancel IDLE
IRP always and don’t care about callback call, it can lead to
non-functional device which stays in low power state. At least at
pre-SP2 XP.
Do you have finite state machine which handles SS in WDF? If so, can you
post it?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Michal_Vodicka-2 · October 6, 2005, 6:16pm

Thanks. I don’t need to see code snippets, finite state machine(s) described in text or some meta language would be enough and probably better.

I’m still not quite sure how do you cancel SS: do you always cancel IDLE IRP even if callback was already called? It would probably solve my problem but it susceptible to race conditions at pre-SP2 XP. Actually, I originally used this approach and changed it to D0 after callback just because of this problem. Maybe it was solved at SP2 and if so, we can probably insist on SP2 now (we couldn’t year before). D0 approach worked well until SP2 RTM…

Locked transactions seem as a good idea. Do I understand correctly power and PnP IRPs are queued? Where?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, October 06, 2005 11:42 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

I do have a finite state machine that handles USB SS, but it is
integrated wholly into the WDF power policy state machine. The pwr pol
state machine is completely tied to the finite state machines for both
pnp and power. Basically, there is a lot to digest and I don’t know if
a snippet, or even one of the 3 is helpful on a micro level. Also,
there may be legal issues about what I can give out, I will have to ask.
I will gladly send them to you if I am allowed.

As for a sanctioned design, I can’t say either way. From our testing,
what I have written works and we have hit some of the race conditions
you mentioned during our tests.

I can tell you what the design is though. Power policy has the concept
of locked transitions. For instance, once we send a Dx irp to the
stack, we lock out any other events until that transition is complete.
That means that if a s.r. came in right after we decided to power down,
we will process the power down to its completion before we process the
s.r. irp. Now we must consider idling out and wake capable while the
machine is in S0 for both the USB SS case and then non USB SS case. In
the non USB SS case, it is simply a matter of locking up the queue,
sending a WW irp, sending a Dx irp, unlocking the queue. In the USB SS
case, there are more exit points, it is essentially

send USB SS irp (queue not locked)

if the callback is called, then do the non USB SS actions described,
then return from the callback

Now, if we need to power up or abort and we are in state 1), we lock the
queue and cancel the usb ss irp. If the cancellation fails, it is b/c a
callback is imminent, so we wait for the callback. When the callback is
invoked, we just return from the callback and then unlock the queue and
proceed on.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, October 06, 2005 2:28 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

> ----------
> From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Thursday, October 06, 2005 11:12 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Selective suspend and surpsise removal
>
> In WDF if the device get’s a surprise remove, we wait for all pending
> power operations to complete before sending the s.r. irp down the
stack.
> That includes cancellation of the SS irp and/or not powering down in>
the
> callback in that state if the cancellation fails.
>
Should I take it as approved and supported way? What if the IDLE
callback was already called or is called in parallel with surprise
removal? DDK docs states:
A function driver may cancel the idle request after it has been made,
but must do so before the hub driver calls the callback routine.
Simple cases aren’t the problem, race conditions are. If you cancel IDLE
IRP always and don’t care about callback call, it can lead to
non-functional device which stays in low power state. At least at
pre-SP2 XP.
Do you have finite state machine which handles SS in WDF? If so, can you
post it?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Doron_Holan · October 6, 2005, 6:27pm

My state machine is a monstrous, multi page visio diagram. It is hard
to transcribe to text, sorry.

If the SS callback has been invoked, I don’t cancel it. I just return
from callback in whatever D state I am currently in.

The pnp and power irps are queued by KMDF itself. All of this logic is
internal to KMDF and is how we decided to implement the rules for WDM.
In the case of pnp and power irps, they are queued w/out cancellation
routines b/c they are considered a state change transaction event which
will be completed eventually and cannot be canceled and we know we will
eventually (*) process them.

D

(*) eventually b/c we may be stuck in a client driver callback. If no
client callbacks are involved, we process them almost immediately.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, October 06, 2005 3:16 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

Thanks. I don’t need to see code snippets, finite state machine(s)
described in text or some meta language would be enough and probably
better.

I’m still not quite sure how do you cancel SS: do you always cancel IDLE
IRP even if callback was already called? It would probably solve my
problem but it susceptible to race conditions at pre-SP2 XP. Actually, I
originally used this approach and changed it to D0 after callback just
because of this problem. Maybe it was solved at SP2 and if so, we can
probably insist on SP2 now (we couldn’t year before). D0 approach worked
well until SP2 RTM…

Locked transactions seem as a good idea. Do I understand correctly power
and PnP IRPs are queued? Where?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, October 06, 2005 11:42 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

I do have a finite state machine that handles USB SS, but it is
integrated wholly into the WDF power policy state machine. The pwr
pol
state machine is completely tied to the finite state machines for both
pnp and power. Basically, there is a lot to digest and I don’t know
if
a snippet, or even one of the 3 is helpful on a micro level. Also,
there may be legal issues about what I can give out, I will have to
ask.
I will gladly send them to you if I am allowed.

As for a sanctioned design, I can’t say either way. From our testing,
what I have written works and we have hit some of the race conditions
you mentioned during our tests.

I can tell you what the design is though. Power policy has the
concept
of locked transitions. For instance, once we send a Dx irp to the
stack, we lock out any other events until that transition is complete.
That means that if a s.r. came in right after we decided to power
down,
we will process the power down to its completion before we process the
s.r. irp. Now we must consider idling out and wake capable while the
machine is in S0 for both the USB SS case and then non USB SS case.
In
the non USB SS case, it is simply a matter of locking up the queue,
sending a WW irp, sending a Dx irp, unlocking the queue. In the USB
SS
case, there are more exit points, it is essentially

send USB SS irp (queue not locked)

if the callback is called, then do the non USB SS actions
described,
then return from the callback

Now, if we need to power up or abort and we are in state 1), we lock
the
queue and cancel the usb ss irp. If the cancellation fails, it is b/c
a
callback is imminent, so we wait for the callback. When the callback
is
invoked, we just return from the callback and then unlock the queue
and
proceed on.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, October 06, 2005 2:28 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

> ----------
> From:

xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com

] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Thursday, October 06, 2005 11:12 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Selective suspend and surpsise removal
>
> In WDF if the device get’s a surprise remove, we wait for all
pending
> power operations to complete before sending the s.r. irp down the
stack.
> That includes cancellation of the SS irp and/or not powering down
in>
the
> callback in that state if the cancellation fails.
>
Should I take it as approved and supported way? What if the IDLE
callback was already called or is called in parallel with surprise
removal? DDK docs states:
A function driver may cancel the idle request after it has been made,
but must do so before the hub driver calls the callback routine.
Simple cases aren’t the problem, race conditions are. If you cancel
IDLE
IRP always and don’t care about callback call, it can lead to
non-functional device which stays in low power state. At least at
pre-SP2 XP.
Do you have finite state machine which handles SS in WDF? If so, can
you
post it?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

You are currently subscribed to ntdev as: unknown lmsubst tag
argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Michal_Vodicka-2 · October 6, 2005, 6:45pm

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, October 07, 2005 12:24 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

My state machine is a monstrous, multi page visio diagram. It is hard
to transcribe to text, sorry.

I guess it wouldn’t be possible to send it directly via e-mail or make it available on the web, right? I mean it would be nice and helpful but I understand there can be legal issues.

If the SS callback has been invoked, I don’t cancel it. I just return
from callback in whatever D state I am currently in.

No, I mean how do you cancel SS / force IDLE IRP completion once callback is called. There are two possibilities: call IoCancelIrp(IDLE_IRP) always or send D0 after callback.

The pnp and power irps are queued by KMDF itself. All of this logic is
internal to KMDF and is how we decided to implement the rules for WDM.

KMDF is now WDF? I meant which part of code queues it. Are they queued just after driver requests WDF to send an IRP or in dispatch routines or somewhere else? Just interested, maybe it’d be clear if I look at currect WDF state.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Doron_Holan · October 6, 2005, 7:47pm

KMDF == kernel mode driver framework
UMDF == user mode driver framework
Static tools == prefast & SDV
WDF == windows driver foundation

WDF = ( KMDF && UMDF && static tools )

As for the SS callback, I send a D irp.

D

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, October 06, 2005 3:45 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, October 07, 2005 12:24 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

My state machine is a monstrous, multi page visio diagram. It is hard
to transcribe to text, sorry.

I guess it wouldn’t be possible to send it directly via e-mail or make
it available on the web, right? I mean it would be nice and helpful but
I understand there can be legal issues.

If the SS callback has been invoked, I don’t cancel it. I just return
from callback in whatever D state I am currently in.

No, I mean how do you cancel SS / force IDLE IRP completion once
callback is called. There are two possibilities: call
IoCancelIrp(IDLE_IRP) always or send D0 after callback.

The pnp and power irps are queued by KMDF itself. All of this logic
is
internal to KMDF and is how we decided to implement the rules for WDM.

KMDF is now WDF? I meant which part of code queues it. Are they queued
just after driver requests WDF to send an IRP or in dispatch routines or
somewhere else? Just interested, maybe it’d be clear if I look at
currect WDF state.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Michal_Vodicka-2 · October 6, 2005, 8:38pm

Thanks, I love abbreviations

If you send D0, I’d bet you have the same problem only haven’t encountered it, yet. The race conditions are between SS callback + next D0 and external event (device removal) which can’t be influenced by driver. The best way to reproduce it is to have a device which can be told to disconnect from USB after defined interval. This way I’m able to reproduce it in almost 100% cases when “right” time is found for given machine and HC.

Contains current WDF an USB driver similar to BulkUsb and using SS? I could quickly customize it for our device and try to reproduce the problem. If so, where is up-to-date code available?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, October 07, 2005 1:44 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

KMDF == kernel mode driver framework
UMDF == user mode driver framework
Static tools == prefast & SDV
WDF == windows driver foundation

WDF = ( KMDF && UMDF && static tools )

As for the SS callback, I send a D irp.

D

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, October 06, 2005 3:45 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

> ----------
> From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Friday, October 07, 2005 12:24 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Selective suspend and surpsise removal
>
> My state machine is a monstrous, multi page visio diagram. It is hard
> to transcribe to text, sorry.
>
I guess it wouldn’t be possible to send it directly via e-mail or make
it available on the web, right? I mean it would be nice and helpful but
I understand there can be legal issues.

> If the SS callback has been invoked, I don’t cancel it. I just return
> from callback in whatever D state I am currently in.
>
No, I mean how do you cancel SS / force IDLE IRP completion once
callback is called. There are two possibilities: call
IoCancelIrp(IDLE_IRP) always or send D0 after callback.

> The pnp and power irps are queued by KMDF itself. All of this logic
is
> internal to KMDF and is how we decided to implement the rules for WDM.
>
KMDF is now WDF? I meant which part of code queues it. Are they queued
just after driver requests WDF to send an IRP or in dispatch routines or
somewhere else? Just interested, maybe it’d be clear if I look at
currect WDF state.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Doron_Holan · October 6, 2005, 8:48pm

Yes, KMDF has a bulkusb port as a public sample. If you join the WDF
beta, you can get the code (I need to find the info on that, but other
folks here probably have that more handy).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, October 06, 2005 5:38 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

Thanks, I love abbreviations

If you send D0, I’d bet you have the same problem only haven’t
encountered it, yet. The race conditions are between SS callback + next
D0 and external event (device removal) which can’t be influenced by
driver. The best way to reproduce it is to have a device which can be
told to disconnect from USB after defined interval. This way I’m able to
reproduce it in almost 100% cases when “right” time is found for given
machine and HC.

Contains current WDF an USB driver similar to BulkUsb and using SS? I
could quickly customize it for our device and try to reproduce the
problem. If so, where is up-to-date code available?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, October 07, 2005 1:44 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

KMDF == kernel mode driver framework
UMDF == user mode driver framework
Static tools == prefast & SDV
WDF == windows driver foundation

WDF = ( KMDF && UMDF && static tools )

As for the SS callback, I send a D irp.

D

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, October 06, 2005 3:45 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

> ----------
> From:

xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com

] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Friday, October 07, 2005 12:24 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Selective suspend and surpsise removal
>
> My state machine is a monstrous, multi page visio diagram. It is
hard
> to transcribe to text, sorry.
>
I guess it wouldn’t be possible to send it directly via e-mail or make
it available on the web, right? I mean it would be nice and helpful
but
I understand there can be legal issues.

> If the SS callback has been invoked, I don’t cancel it. I just
return
> from callback in whatever D state I am currently in.
>
No, I mean how do you cancel SS / force IDLE IRP completion once
callback is called. There are two possibilities: call
IoCancelIrp(IDLE_IRP) always or send D0 after callback.

> The pnp and power irps are queued by KMDF itself. All of this logic
is
> internal to KMDF and is how we decided to implement the rules for
WDM.
>
KMDF is now WDF? I meant which part of code queues it. Are they queued
just after driver requests WDF to send an IRP or in dispatch routines
or
somewhere else? Just interested, maybe it’d be clear if I look at
currect WDF state.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

You are currently subscribed to ntdev as: unknown lmsubst tag
argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Michal_Vodicka-2 · October 6, 2005, 9:23pm

I found it in list archives – http://www.microsoft.com/whdc/driver/wdf/beta.mspx and filed the survey. Hopefully it is still opened.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, October 07, 2005 2:45 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

Yes, KMDF has a bulkusb port as a public sample. If you join the WDF
beta, you can get the code (I need to find the info on that, but other
folks here probably have that more handy).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, October 06, 2005 5:38 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

Thanks, I love abbreviations

If you send D0, I’d bet you have the same problem only haven’t
encountered it, yet. The race conditions are between SS callback + next
D0 and external event (device removal) which can’t be influenced by
driver. The best way to reproduce it is to have a device which can be
told to disconnect from USB after defined interval. This way I’m able to
reproduce it in almost 100% cases when “right” time is found for given
machine and HC.

Contains current WDF an USB driver similar to BulkUsb and using SS? I
could quickly customize it for our device and try to reproduce the
problem. If so, where is up-to-date code available?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

> ----------
> From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Friday, October 07, 2005 1:44 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Selective suspend and surpsise removal
>
> KMDF == kernel mode driver framework
> UMDF == user mode driver framework
> Static tools == prefast & SDV
> WDF == windows driver foundation
>
> WDF = ( KMDF && UMDF && static tools )
>
> As for the SS callback, I send a D irp.
>
> D
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
> Sent: Thursday, October 06, 2005 3:45 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Selective suspend and surpsise removal
>
> > ----------
> > From:
>
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
> ] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
> > Reply To: Windows System Software Devs Interest List
> > Sent: Friday, October 07, 2005 12:24 AM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] Selective suspend and surpsise removal
> >
> > My state machine is a monstrous, multi page visio diagram. It is
hard
> > to transcribe to text, sorry.
> >
> I guess it wouldn’t be possible to send it directly via e-mail or make
> it available on the web, right? I mean it would be nice and helpful
but
> I understand there can be legal issues.
>
> > If the SS callback has been invoked, I don’t cancel it. I just
return
> > from callback in whatever D state I am currently in.
> >
> No, I mean how do you cancel SS / force IDLE IRP completion once
> callback is called. There are two possibilities: call
> IoCancelIrp(IDLE_IRP) always or send D0 after callback.
>
> > The pnp and power irps are queued by KMDF itself. All of this logic>
> is
> > internal to KMDF and is how we decided to implement the rules for
WDM.
> >
> KMDF is now WDF? I meant which part of code queues it. Are they queued
> just after driver requests WDF to send an IRP or in dispatch routines
or
> somewhere else? Just interested, maybe it’d be clear if I look at
> currect WDF state.
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
argument:
> ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Michal_Vodicka-2 · October 6, 2005, 11:07pm

Did you test this sample at Vista, too? I just tested my driver at beta1 and the problem I mentioned is 100% reproducible with every surprise removal i.e. always when device is suspended and detached later. It can be timining and machine, of course. At least I have something which allows easy testing

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, October 07, 2005 2:45 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

Yes, KMDF has a bulkusb port as a public sample. If you join the WDF
beta, you can get the code (I need to find the info on that, but other
folks here probably have that more handy).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, October 06, 2005 5:38 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

Thanks, I love abbreviations

If you send D0, I’d bet you have the same problem only haven’t
encountered it, yet. The race conditions are between SS callback + next
D0 and external event (device removal) which can’t be influenced by
driver. The best way to reproduce it is to have a device which can be
told to disconnect from USB after defined interval. This way I’m able to
reproduce it in almost 100% cases when “right” time is found for given
machine and HC.

Contains current WDF an USB driver similar to BulkUsb and using SS? I
could quickly customize it for our device and try to reproduce the
problem. If so, where is up-to-date code available?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

> ----------
> From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Friday, October 07, 2005 1:44 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Selective suspend and surpsise removal
>
> KMDF == kernel mode driver framework
> UMDF == user mode driver framework
> Static tools == prefast & SDV
> WDF == windows driver foundation
>
> WDF = ( KMDF && UMDF && static tools )
>
> As for the SS callback, I send a D irp.
>
> D
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
> Sent: Thursday, October 06, 2005 3:45 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Selective suspend and surpsise removal
>
> > ----------
> > From:
>
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
> ] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
> > Reply To: Windows System Software Devs Interest List
> > Sent: Friday, October 07, 2005 12:24 AM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] Selective suspend and surpsise removal
> >
> > My state machine is a monstrous, multi page visio diagram. It is
hard
> > to transcribe to text, sorry.
> >
> I guess it wouldn’t be possible to send it directly via e-mail or make
> it available on the web, right? I mean it would be nice and helpful
but
> I understand there can be legal issues.
>
> > If the SS callback has been invoked, I don’t cancel it. I just
return
> > from callback in whatever D state I am currently in.
> >
> No, I mean how do you cancel SS / force IDLE IRP completion once>
> callback is called. There are two possibilities: call
> IoCancelIrp(IDLE_IRP) always or send D0 after callback.
>
> > The pnp and power irps are queued by KMDF itself. All of this logic
> is
> > internal to KMDF and is how we decided to implement the rules for
WDM.
> >
> KMDF is now WDF? I meant which part of code queues it. Are they queued
> just after driver requests WDF to send an IRP or in dispatch routines
or
> somewhere else? Just interested, maybe it’d be clear if I look at
> currect WDF state.
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
argument:
> ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Michal_Vodicka-2 · October 14, 2005, 12:27am

OK, I tried WDF USB sample with our device (port was surprisigly easy). No problem at Vista so far and I found the problem with my driver. There was the deadlock because my surprise removal handler waited until IDLE IRP is completed. Why? Because original BulkUsb code did and still does it. Unfortunately, Vista beta 1 doesn’t complete IDLE IRP until surprise removal IRP is passed down the stack. Now I wait in the remove handler and this deadlock is gone (haven’t tested the second one, yet).

Is this behaviour or rule documented somewhere? I searched docs and didn’t find it.

BTW, I do appreciate improved selective suspend docs in WDK 5112; now it is clear how it should be cancelled. I only don’t undestand why all three DDK samples (bulkusb, selsusp and isousb) still don’t use documented way (they call IoCancelIrp instead of sending D0 IRP).

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Michal Vodicka[SMTP:xxxxx@upek.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, October 07, 2005 5:06 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

Did you test this sample at Vista, too? I just tested my driver at beta1 and the problem I mentioned is 100% reproducible with every surprise removal i.e. always when device is suspended and detached later. It can be timining and machine, of course. At least I have something which allows easy testing

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

> ----------
> From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Friday, October 07, 2005 2:45 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Selective suspend and surpsise removal
>
> Yes, KMDF has a bulkusb port as a public sample. If you join the WDF
> beta, you can get the code (I need to find the info on that, but other
> folks here probably have that more handy).
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
> Sent: Thursday, October 06, 2005 5:38 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Selective suspend and surpsise removal
>
> Thanks, I love abbreviations
>
> If you send D0, I’d bet you have the same problem only haven’t
> encountered it, yet. The race conditions are between SS callback + next
> D0 and external event (device removal) which can’t be influenced by
> driver. The best way to reproduce it is to have a device which can be
> told to disconnect from USB after defined interval. This way I’m able to
> reproduce it in almost 100% cases when “right” time is found for given
> machine and HC.
>
> Contains current WDF an USB driver similar to BulkUsb and using SS? I
> could quickly customize it for our device and try to reproduce the
> problem. If so, where is up-to-date code available?
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
> > ----------
> > From:
> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
> ] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
> > Reply To: Windows System Software Devs Interest List
> > Sent: Friday, October 07, 2005 1:44 AM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] Selective suspend and surpsise removal
> >
> > KMDF == kernel mode driver framework>
> > UMDF == user mode driver framework
> > Static tools == prefast & SDV
> > WDF == windows driver foundation
> >
> > WDF = ( KMDF && UMDF && static tools )
> >
> > As for the SS callback, I send a D irp.
> >
> > D
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
> > Sent: Thursday, October 06, 2005 3:45 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] Selective suspend and surpsise removal
> >
> > > ----------
> > > From:
> >
> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
> > ] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
> > > Reply To: Windows System Software Devs Interest List
> > > Sent: Friday, October 07, 2005 12:24 AM
> > > To: Windows System Software Devs Interest List
> > > Subject: RE: [ntdev] Selective suspend and surpsise removal
> > >
> > > My state machine is a monstrous, multi page visio diagram. It is
> hard
> > > to transcribe to text, sorry.
> > >
> > I guess it wouldn’t be possible to send it directly via e-mail or make
> > it available on the web, right? I mean it would be nice and helpful
> but
> > I understand there can be legal issues.
> >
> > > If the SS callback has been invoked, I don’t cancel it. I just
> return
> > > from callback in whatever D state I am currently in.
> > >
> > No, I mean how do you cancel SS / force IDLE IRP completion once>
> > callback is called. There are two possibilities: call
> > IoCancelIrp(IDLE_IRP) always or send D0 after callback.
> >
> > > The pnp and power irps are queued by KMDF itself. All of this logic
> > is
> > > internal to KMDF and is how we decided to implement the rules for
> WDM.
> > >
> > KMDF is now WDF? I meant which part of code queues it. Are they queued
> > just after driver requests WDF to send an IRP or in dispatch routines
> or
> > somewhere else? Just interested, maybe it’d be clear if I look at
> > currect WDF state.
> >
> > Best regards,
> >
> > Michal Vodicka
> > UPEK, Inc.
> > [xxxxx@upek.com, http://www.upek.com]
> >
> >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: unknown lmsubst tag
> argument:
> > ‘’
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: unknown lmsubst tag
> argument: ‘’
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument:
> ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Michal_Vodicka-2 · October 15, 2005, 12:45am

Bad news, Doron. I successfully simulated deadlock on surprise removal (hung D0) with WDF based driver, too. I believe it is a bug in USB stack introduced in XP SP2. More info next week.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Michal Vodicka[SMTP:xxxxx@upek.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, October 14, 2005 6:26 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

OK, I tried WDF USB sample with our device (port was surprisigly easy). No problem at Vista so far and I found the problem with my driver. There was the deadlock because my surprise removal handler waited until IDLE IRP is completed. Why? Because original BulkUsb code did and still does it. Unfortunately, Vista beta 1 doesn’t complete IDLE IRP until surprise removal IRP is passed down the stack. Now I wait in the remove handler and this deadlock is gone (haven’t tested the second one, yet).

Is this behaviour or rule documented somewhere? I searched docs and didn’t find it.

BTW, I do appreciate improved selective suspend docs in WDK 5112; now it is clear how it should be cancelled. I only don’t undestand why all three DDK samples (bulkusb, selsusp and isousb) still don’t use documented way (they call IoCancelIrp instead of sending D0 IRP).

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

> ----------
> From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Michal Vodicka[SMTP:xxxxx@upek.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Friday, October 07, 2005 5:06 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Selective suspend and surpsise removal
>
> Did you test this sample at Vista, too? I just tested my driver at beta1 and the problem I mentioned is 100% reproducible with every surprise removal i.e. always when device is suspended and detached later. It can be timining and machine, of course. At least I have something which allows easy testing
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
> > ----------
> > From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
> > Reply To: Windows System Software Devs Interest List
> > Sent: Friday, October 07, 2005 2:45 AM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] Selective suspend and surpsise removal
> >
> > Yes, KMDF has a bulkusb port as a public sample. If you join the WDF
> > beta, you can get the code (I need to find the info on that, but other
> > folks here probably have that more handy).
> >
> > d
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
> > Sent: Thursday, October 06, 2005 5:38 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] Selective suspend and surpsise removal
> >
> > Thanks, I love abbreviations
> >
> > If you send D0, I’d bet you have the same problem only haven’t
> > encountered it, yet. The race conditions are between SS callback + next
> > D0 and external event (device removal) which can’t be influenced by
> > driver. The best way to reproduce it is to have a device which can be
> > told to disconnect from USB after defined interval. This way I’m able to
> > reproduce it in almost 100% cases when “right” time is found for given
> > machine and HC.>
> >
> > Contains current WDF an USB driver similar to BulkUsb and using SS? I
> > could quickly customize it for our device and try to reproduce the
> > problem. If so, where is up-to-date code available?
> >
> > Best regards,
> >
> > Michal Vodicka
> > UPEK, Inc.
> > [xxxxx@upek.com, http://www.upek.com]
> >
> >
> > > ----------
> > > From:
> > xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
> > ] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
> > > Reply To: Windows System Software Devs Interest List
> > > Sent: Friday, October 07, 2005 1:44 AM
> > > To: Windows System Software Devs Interest List
> > > Subject: RE: [ntdev] Selective suspend and surpsise removal
> > >
> > > KMDF == kernel mode driver framework>
> > > UMDF == user mode driver framework
> > > Static tools == prefast & SDV
> > > WDF == windows driver foundation
> > >
> > > WDF = ( KMDF && UMDF && static tools )
> > >
> > > As for the SS callback, I send a D irp.
> > >
> > > D
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
> > > Sent: Thursday, October 06, 2005 3:45 PM
> > > To: Windows System Software Devs Interest List
> > > Subject: RE: [ntdev] Selective suspend and surpsise removal
> > >
> > > > ----------
> > > > From:
> > >
> > xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
> > > ] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
> > > > Reply To: Windows System Software Devs Interest List
> > > > Sent: Friday, October 07, 2005 12:24 AM
> > > > To: Windows System Software Devs Interest List
> > > > Subject: RE: [ntdev] Selective suspend and surpsise removal
> > > >
> > > > My state machine is a monstrous, multi page visio diagram. It is
> > hard
> > > > to transcribe to text, sorry.
> > > >
> > > I guess it wouldn’t be possible to send it directly via e-mail or make
> > > it available on the web, right? I mean it would be nice and helpful
> > but
> > > I understand there can be legal issues.
> > >
> > > > If the SS callback has been invoked, I don’t cancel it. I just
> > return
> > > > from callback in whatever D state I am currently in.
> > > >
> > > No, I mean how do you cancel SS / force IDLE IRP completion once>
> > > callback is called. There are two possibilities: call
> > > IoCancelIrp(IDLE_IRP) always or send D0 after callback.
> > >
> > > > The pnp and power irps are queued by KMDF itself. All of this logic
> > > is
> > > > internal to KMDF and is how we decided to implement the rules for
> > WDM.
> > > >
> > > KMDF is now WDF? I meant which part of code queues it. Are they queued
> > > just after driver requests WDF to send an IRP or in dispatch routines
> > or
> > > somewhere else? Just interested, maybe it’d be clear if I look at
> > > currect WDF state.
> > >
> > > Best regards,
> > >
> > > Michal Vodicka
> > > UPEK, Inc.
> > > [xxxxx@upek.com, http://www.upek.com]
> > >
> > >
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: unknown lmsubst tag
> > argument:
> > > ‘’
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: unknown lmsubst tag
> > argument: ‘’
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256\>
> >
> > You are currently subscribed to ntdev as: unknown lmsubst tag argument:
> > ‘’
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> > —
> > Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Doron_Holan · October 15, 2005, 9:36pm

Can you produce a full kernel or a complete memory dump? If so, I can
arrange an FTP site for you to download the .dmp file so I can confirm
it.

Thx
d

-----Original Message-----
From: Michal Vodicka [mailto:xxxxx@upek.com]
Sent: Friday, October 14, 2005 9:45 PM
To: Windows System Software Devs Interest List
Cc: Doron Holan
Subject: RE: [ntdev] Selective suspend and surpsise removal

Bad news, Doron. I successfully simulated deadlock on surprise removal
(hung D0) with WDF based driver, too. I believe it is a bug in USB stack
introduced in XP SP2. More info next week.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Michal Vodicka[SMTP:xxxxx@upek.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, October 14, 2005 6:26 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

OK, I tried WDF USB sample with our device (port was surprisigly
easy). No problem at Vista so far and I found the problem with my
driver. There was the deadlock because my surprise removal handler
waited until IDLE IRP is completed. Why? Because original BulkUsb code
did and still does it. Unfortunately, Vista beta 1 doesn’t complete IDLE
IRP until surprise removal IRP is passed down the stack. Now I wait in
the remove handler and this deadlock is gone (haven’t tested the second
one, yet).

Is this behaviour or rule documented somewhere? I searched docs and
didn’t find it.

BTW, I do appreciate improved selective suspend docs in WDK 5112; now
it is clear how it should be cancelled. I only don’t undestand why all
three DDK samples (bulkusb, selsusp and isousb) still don’t use
documented way (they call IoCancelIrp instead of sending D0 IRP).

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

> ----------
> From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Michal Vodicka[SMTP:xxxxx@upek.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Friday, October 07, 2005 5:06 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Selective suspend and surpsise removal
>
> Did you test this sample at Vista, too? I just tested my driver at
beta1 and the problem I mentioned is 100% reproducible with every
surprise removal i.e. always when device is suspended and detached
later. It can be timining and machine, of course. At least I have
something which allows easy testing
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
> > ----------
> > From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
> > Reply To: Windows System Software Devs Interest List
> > Sent: Friday, October 07, 2005 2:45 AM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] Selective suspend and surpsise removal
> >
> > Yes, KMDF has a bulkusb port as a public sample. If you join the
WDF
> > beta, you can get the code (I need to find the info on that, but
other
> > folks here probably have that more handy).
> >
> > d
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Michal
Vodicka
> > Sent: Thursday, October 06, 2005 5:38 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] Selective suspend and surpsise removal
> >
> > Thanks, I love abbreviations
> >
> > If you send D0, I’d bet you have the same problem only haven’t
> > encountered it, yet. The race conditions are between SS callback +
next
> > D0 and external event (device removal) which can’t be influenced
by
> > driver. The best way to reproduce it is to have a device which can
be
> > told to disconnect from USB after defined interval. This way I’m
able to
> > reproduce it in almost 100% cases when “right” time is found for
given
> > machine and HC.>
> >
> > Contains current WDF an USB driver similar to BulkUsb and using
SS? I
> > could quickly customize it for our device and try to reproduce the
> > problem. If so, where is up-to-date code available?
> >
> > Best regards,
> >
> > Michal Vodicka
> > UPEK, Inc.
> > [xxxxx@upek.com, http://www.upek.com]
> >
> >
> > > ----------
> > > From:
> >
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
> > ] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
> > > Reply To: Windows System Software Devs Interest List
> > > Sent: Friday, October 07, 2005 1:44 AM
> > > To: Windows System Software Devs Interest List
> > > Subject: RE: [ntdev] Selective suspend and surpsise
removal
> > >
> > > KMDF == kernel mode driver framework>
> > > UMDF == user mode driver framework
> > > Static tools == prefast & SDV
> > > WDF == windows driver foundation
> > >
> > > WDF = ( KMDF && UMDF && static tools )
> > >
> > > As for the SS callback, I send a D irp.
> > >
> > > D
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of Michal
Vodicka
> > > Sent: Thursday, October 06, 2005 3:45 PM
> > > To: Windows System Software Devs Interest List
> > > Subject: RE: [ntdev] Selective suspend and surpsise removal
> > >
> > > > ----------
> > > > From:
> > >
> >
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
> > > ] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
> > > > Reply To: Windows System Software Devs Interest List
> > > > Sent: Friday, October 07, 2005 12:24 AM
> > > > To: Windows System Software Devs Interest List
> > > > Subject: RE: [ntdev] Selective suspend and surpsise
removal
> > > >
> > > > My state machine is a monstrous, multi page visio diagram. It
is
> > hard
> > > > to transcribe to text, sorry.
> > > >
> > > I guess it wouldn’t be possible to send it directly via e-mail
or make
> > > it available on the web, right? I mean it would be nice and
helpful
> > but
> > > I understand there can be legal issues.
> > >
> > > > If the SS callback has been invoked, I don’t cancel it. I just
> > return
> > > > from callback in whatever D state I am currently in.
> > > >
> > > No, I mean how do you cancel SS / force IDLE IRP completion
once>
> > > callback is called. There are two possibilities: call
> > > IoCancelIrp(IDLE_IRP) always or send D0 after callback.
> > >
> > > > The pnp and power irps are queued by KMDF itself. All of this
logic
> > > is
> > > > internal to KMDF and is how we decided to implement the rules
for
> > WDM.
> > > >
> > > KMDF is now WDF? I meant which part of code queues it. Are they
queued
> > > just after driver requests WDF to send an IRP or in dispatch
routines
> > or
> > > somewhere else? Just interested, maybe it’d be clear if I look
at
> > > currect WDF state.
> > >
> > > Best regards,
> > >
> > > Michal Vodicka
> > > UPEK, Inc.
> > > [xxxxx@upek.com, http://www.upek.com]
> > >
> > >
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: unknown lmsubst tag
> > argument:
> > > ‘’
> > > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: unknown lmsubst tag
> > argument: ‘’
> > > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> > >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256\>
> >
> > You are currently subscribed to ntdev as: unknown lmsubst tag
argument:
> > ‘’
> > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
> > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> >
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
> To unsubscribe send a blank email to
xxxxx@lists.osr.com
>

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

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Michal_Vodicka-2 · October 17, 2005, 12:33pm

Sure, I can. Let me know FTP upload details.

Do you want driver sources and/or binary + PDB, too? I used osrusbfx2/final sample, changed VID and PID in the INF and added few IOCTLs so it works with our testing software. I also added few PnP callbacks so surprise removal is visible and used different traces.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: Doron Holan[SMTP:xxxxx@microsoft.com]
Sent: Sunday, October 16, 2005 3:29 AM
To: Michal Vodicka; Windows System Software Devs Interest List
Subject: RE: [ntdev] Selective suspend and surpsise removal

Can you produce a full kernel or a complete memory dump? If so, I can
arrange an FTP site for you to download the .dmp file so I can confirm
it.

Thx
d

-----Original Message-----
From: Michal Vodicka [mailto:xxxxx@upek.com]
Sent: Friday, October 14, 2005 9:45 PM
To: Windows System Software Devs Interest List
Cc: Doron Holan
Subject: RE: [ntdev] Selective suspend and surpsise removal

Bad news, Doron. I successfully simulated deadlock on surprise removal
(hung D0) with WDF based driver, too. I believe it is a bug in USB stack
introduced in XP SP2. More info next week.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

> ----------
> From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Michal Vodicka[SMTP:xxxxx@upek.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Friday, October 14, 2005 6:26 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Selective suspend and surpsise removal
>
> OK, I tried WDF USB sample with our device (port was surprisigly
easy). No problem at Vista so far and I found the problem with my
driver. There was the deadlock because my surprise removal handler
waited until IDLE IRP is completed. Why? Because original BulkUsb code
did and still does it. Unfortunately, Vista beta 1 doesn’t complete IDLE
IRP until surprise removal IRP is passed down the stack. Now I wait in
the remove handler and this deadlock is gone (haven’t tested the second
one, yet).
>
> Is this behaviour or rule documented somewhere? I searched docs and
didn’t find it.
>
> BTW, I do appreciate improved selective suspend docs in WDK 5112; now
it is clear how it should be cancelled. I only don’t undestand why all
three DDK samples (bulkusb, selsusp and isousb) still don’t use
documented way (they call IoCancelIrp instead of sending D0 IRP).
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
> > ----------
> > From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Michal Vodicka[SMTP:xxxxx@upek.com]
> > Reply To: Windows System Software Devs Interest List
> > Sent: Friday, October 07, 2005 5:06 AM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] Selective suspend and surpsise removal
> >
> > Did you test this sample at Vista, too? I just tested my driver at
beta1 and the problem I mentioned is 100% reproducible with every
surprise removal i.e. always when device is suspended and detached
later. It can be timining and machine, of course. At least I have
something which allows easy testing
> >
> > Best regards,
> >
> > Michal Vodicka
> > UPEK, Inc.
> > [xxxxx@upek.com, http://www.upek.com]
> >
> >
> > > ----------
> > > From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
> > > Reply To: Windows System Software Devs Interest List
> > > Sent: Friday, October 07, 2005 2:45 AM
> > > To: > Windows System Software Devs Interest List
> > > Subject: RE: [ntdev] Selective suspend and surpsise removal
> > >
> > > Yes, KMDF has a bulkusb port as a public sample. If you join the
WDF
> > > beta, you can get the code (I need to find the info on that, but
other
> > > folks here probably have that more handy).
> > >
> > > d
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of Michal
Vodicka
> > > Sent: Thursday, October 06, 2005 5:38 PM
> > > To: Windows System Software Devs Interest List
> > > Subject: RE: [ntdev] Selective suspend and surpsise removal
> > >
> > > Thanks, I love abbreviations
> > >
> > > If you send D0, I’d bet you have the same problem only haven’t
> > > encountered it, yet. The race conditions are between SS callback +
next
> > > D0 and external event (device removal) which can’t be influenced
by
> > > driver. The best way to reproduce it is to have a device which can
be
> > > told to disconnect from USB after defined interval. This way I’m
able to
> > > reproduce it in almost 100% cases when “right” time is found for
given
> > > machine and HC.>
> > >
> > > Contains current WDF an USB driver similar to BulkUsb and using
SS? I
> > > could quickly customize it for our device and try to reproduce the
> > > problem. If so, where is up-to-date code available?
> > >
> > > Best regards,
> > >
> > > Michal Vodicka
> > > UPEK, Inc.
> > > [xxxxx@upek.com, http://www.upek.com]
> > >
> > >
> > > > ----------
> > > > From:
> > >
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
> > > ] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
> > > > Reply To: Windows System Software Devs Interest List
> > > > Sent: Friday, October 07, 2005 1:44 AM
> > > > To: Windows System Software Devs Interest List
> > > > Subject: RE: [ntdev] Selective suspend and surpsise
removal
> > > >
> > > > KMDF == kernel mode driver framework>
> > > > UMDF == user mode driver framework
> > > > Static tools == prefast & SDV
> > > > WDF == windows driver foundation
> > > >
> > > > WDF = ( KMDF && UMDF && static tools )
> > > >
> > > > As for the SS callback, I send a D irp.
> > > >
> > > > D
> > > >
> > > > -----Original Message-----
> > > > From: xxxxx@lists.osr.com
> > > > [mailto:xxxxx@lists.osr.com] On Behalf Of Michal
Vodicka
> > > > Sent: Thursday, October 06, 2005 3:45 PM
> > > > To: Windows System Software Devs Interest List
> > > > Subject: RE: [ntdev] Selective suspend and surpsise removal
> > > >
> > > > > ----------
> > > > > From:
> > > >
> > >
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
> > > > ] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
> > > > > Reply To: Windows System Software Devs Interest List
> > > > > Sent: Friday, October 07, 2005 12:24 AM
> > > > > To: Windows System Software Devs Interest List
> > > > > Subject: RE: [ntdev] Selective suspend and surpsise
removal
> > > > >
> > > > > My state machine is a monstrous, multi page visio diagram. It
is
> > > hard
> > > > > to transcribe to text, sorry.
> > > > >
> > > > I guess it wouldn’t be possible to send it directly via e-mail
or make
> > > > it available on the web, right? I mean it would be nice and
helpful
> > > but
> > > > I understand there can be legal issues.
> > > >
> > > > > If the SS callback has been invoked, I don’t cancel it. I just
> > > return
> > > > > from callback in whatever D state I am currently in.
> > > > >
> > > > No, I mean how do you cancel SS / force IDLE IRP completion
once>
> > > > callback is called. There are two possibilities: call
> > > > IoCancelIrp(IDLE_IRP) always or send D0 after callback.>
> > > >
> > > > > The pnp and power irps are queued by KMDF itself. All of this
logic
> > > > is
> > > > > internal to KMDF and is how we decided to implement the rules
for
> > > WDM.
> > > > >
> > > > KMDF is now WDF? I meant which part of code queues it. Are they
queued
> > > > just after driver requests WDF to send an IRP or in dispatch
routines
> > > or
> > > > somewhere else? Just interested, maybe it’d be clear if I look
at
> > > > currect WDF state.
> > > >
> > > > Best regards,
> > > >
> > > > Michal Vodicka
> > > > UPEK, Inc.
> > > > [xxxxx@upek.com, http://www.upek.com]
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as: unknown lmsubst tag
> > > argument:
> > > > ‘’
> > > > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as: unknown lmsubst tag
> > > argument: ‘’
> > > > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> > > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256\>
> > >
> > > You are currently subscribed to ntdev as: unknown lmsubst tag
argument:
> > > ‘’
> > > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
> > > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> > >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
> > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> >
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

Selective suspend and surpsise removal

OK, postpone waiting as late as possible:
7. driver doesn't wait, makes cleanup and passes IRP below, instead
8. driver receives device removal IRP, finishes processing and waits for D0 and IDLE IRPs
9. IDLE IRP is completed
10. driver still waits for D0 IRP completion and waits forever

OK, postpone waiting as late as possible:
7. driver doesn’t wait, makes cleanup and passes IRP below, instead
8. driver receives device removal IRP, finishes processing and waits for D0 and IDLE IRPs
9. IDLE IRP is completed
10. driver still waits for D0 IRP completion and waits forever

OK, postpone waiting as late as possible:
7. driver doesn’t wait, makes cleanup and passes IRP below, instead
8. driver receives device removal IRP, finishes processing and waits
for D0 and IDLE IRPs
9. IDLE IRP is completed
10. driver still waits for D0 IRP completion and waits forever

Selective suspend and surpsise removal

OK, postpone waiting as late as possible: 7. driver doesn't wait, makes cleanup and passes IRP below, instead 8. driver receives device removal IRP, finishes processing and waits for D0 and IDLE IRPs 9. IDLE IRP is completed 10. driver still waits for D0 IRP completion and waits forever

OK, postpone waiting as late as possible: 7. driver doesn’t wait, makes cleanup and passes IRP below, instead 8. driver receives device removal IRP, finishes processing and waits for D0 and IDLE IRPs 9. IDLE IRP is completed 10. driver still waits for D0 IRP completion and waits forever

OK, postpone waiting as late as possible: 7. driver doesn’t wait, makes cleanup and passes IRP below, instead 8. driver receives device removal IRP, finishes processing and waits for D0 and IDLE IRPs 9. IDLE IRP is completed 10. driver still waits for D0 IRP completion and waits forever

OK, postpone waiting as late as possible:
7. driver doesn't wait, makes cleanup and passes IRP below, instead
8. driver receives device removal IRP, finishes processing and waits for D0 and IDLE IRPs
9. IDLE IRP is completed
10. driver still waits for D0 IRP completion and waits forever

OK, postpone waiting as late as possible:
7. driver doesn’t wait, makes cleanup and passes IRP below, instead
8. driver receives device removal IRP, finishes processing and waits for D0 and IDLE IRPs
9. IDLE IRP is completed
10. driver still waits for D0 IRP completion and waits forever

OK, postpone waiting as late as possible:
7. driver doesn’t wait, makes cleanup and passes IRP below, instead
8. driver receives device removal IRP, finishes processing and waits
for D0 and IDLE IRPs
9. IDLE IRP is completed
10. driver still waits for D0 IRP completion and waits forever