Should WdfDeviceStopIdle be always followed by WdfDeviceResumeIdle?

NTDEV
1

Hi all,

I’m facing a strange problem. In my code, I perform the following code to reset the IdleTimeout:
WdfDeviceStopIdle(mydev, FALSE);
WdfDeviceResumeIdle(mydev);
In that sequence of the call, I would expect the device to be waked-up if it was suspended, or the timeout to be re-set if device is in D0.

However, I observe that sometimes the driver doesn’t call for EvtDeviceD0Entry cb.
I have 2 questions regarding that:

  • In msdn it appears that WdfDeviceStopIdle can return with values differ then STATUS_SUCCESS or STATUS_PENDING (i.e NT_STATUS(status) will return 0). Should I call for WdfDeviceResumeIdle in that case? (From msdn: “Every call to WdfDeviceStopIdle must eventually be followed by a call to WdfDeviceResumeIdle”)

  • Sometimes I observe a strange thing in USB analyzer when the symphom above occurs:
    When WdfDeviceStopIdle succeeds and I can see the entrance to EvtDeviceD0Entry, I can
    see a valid SetFeature(DEVICE_REMOTE_WAKEUP) and
    ClearFeature(DEVICE_REMOTE_WAKEUP) transfers in the analyzer. Each of them has 2
    transactions: a SETUP transaction, and an IN transaction with no data.
    When I don’t see the entrance to EvtDeviceD0Entry, I can see that these transfers are
    incomplete: The SETUP transaction is sent to the device (and is ACK-ed), but the IN token
    then is not sent. This is true for both SetFeature and ClearFeature transfers (which is
    invoked when device waking up remotely). After the ClearFeature with no IN token sent,
    I don’t see the entrance to EvtDeviceD0Entry.
    Since I don’t handle the suspend myself, but the framework does, I have no control on
    these transactions. What are the circumstances when such a problem can occur?

Thanks,
S.

2

The only way stopidle() returns an error is if you pass it invalid input. In the code below you are doing an asyn stopidle which means that when you call resumeidle() immediately afterwards kmdf can possibly halt the async stopidle() that you set in motion in the previous call. If you want to guarantee you return to full power, pass true to stopidle() for a sync power up

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: xxxxx@gmail.com
Sent: Tuesday, June 16, 2009 2:59 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Should WdfDeviceStopIdle be always followed by WdfDeviceResumeIdle?

Hi all,

I’m facing a strange problem. In my code, I perform the following code to reset the IdleTimeout:
WdfDeviceStopIdle(mydev, FALSE);
WdfDeviceResumeIdle(mydev);
In that sequence of the call, I would expect the device to be waked-up if it was suspended, or the timeout to be re-set if device is in D0.

However, I observe that sometimes the driver doesn’t call for EvtDeviceD0Entry cb.
I have 2 questions regarding that:

- In msdn it appears that WdfDeviceStopIdle can return with values differ then STATUS_SUCCESS or STATUS_PENDING (i.e NT_STATUS(status) will return 0). Should I call for WdfDeviceResumeIdle in that case? (From msdn: “Every call to WdfDeviceStopIdle must eventually be followed by a call to WdfDeviceResumeIdle”)

- Sometimes I observe a strange thing in USB analyzer when the symphom above occurs:
When WdfDeviceStopIdle succeeds and I can see the entrance to EvtDeviceD0Entry, I can
see a valid SetFeature(DEVICE_REMOTE_WAKEUP) and
ClearFeature(DEVICE_REMOTE_WAKEUP) transfers in the analyzer. Each of them has 2
transactions: a SETUP transaction, and an IN transaction with no data.
When I don’t see the entrance to EvtDeviceD0Entry, I can see that these transfers are
incomplete: The SETUP transaction is sent to the device (and is ACK-ed), but the IN token
then is not sent. This is true for both SetFeature and ClearFeature transfers (which is
invoked when device waking up remotely). After the ClearFeature with no IN token sent,
I don’t see the entrance to EvtDeviceD0Entry.
Since I don’t handle the suspend myself, but the framework does, I have no control on
these transactions. What are the circumstances when such a problem can occur?

Thanks,
S.

—
NTDEV is sponsored by OSR

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

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

3

Hello Doron,

Thank you for the answer.

So, device is not promised to wake up if I call for WdfDeviceStopIdle(dev, FALSE) and WdfDeviceResumeIdle. But if the device is in D0, will these calls reset the timer?

The only way stopidle() returns an error is if you pass it invalid input.
When it returns STATUS_POWER_STATE_INVALID? Isn’t it assumes as an error?
And, in any case - if WdfDeviceStopIdle returns an error, should I still call for WdfDeviceResumeIdle?

Thanks a lot,
S.

4

What are you really trying to do? Reset the idle timer when some event happens? Have you read about power managed queues? A typical kmdf driver uses power managed queues to control the idle state, letting kmdf perform all of the tracking and the driver has no stopidle()/resumeidle() calls in it

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: xxxxx@gmail.com
Sent: Tuesday, June 16, 2009 7:30 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Should WdfDeviceStopIdle be always followed by WdfDeviceResumeIdle?

Hello Doron,

Thank you for the answer.

So, device is not promised to wake up if I call for WdfDeviceStopIdle(dev, FALSE) and WdfDeviceResumeIdle. But if the device is in D0, will these calls reset the timer?

> The only way stopidle() returns an error is if you pass it invalid input.
When it returns STATUS_POWER_STATE_INVALID? Isn’t it assumes as an error?
And, in any case - if WdfDeviceStopIdle returns an error, should I still call for WdfDeviceResumeIdle?

Thanks a lot,
S.

—
NTDEV is sponsored by OSR

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

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

5

> What are you really trying to do? Reset the idle timer when some event happens?
Yes.

A typical kmdf driver uses power managed queues to control the idle state, letting kmdf perform all of
the tracking and the driver has no stopidle()/resumeidle() calls in it.
Well, my problem is that my queue is not power managed. The device I’m working with has remote
wakeup, and when it is suspended and has a data to send, it wakes up. So, when the driver posts reads, they are returned with error and don’t wake the device. Hence, every time I have the data from the device, I want to reset the timer, and I call for WdfDeviceStopIdle and WdfDeviceResumeIdle.
Am I wrong with that design?

Thanks,
S.

6

Do you need to continuously read for data? Is it an entirely push driven data model or do you also write data to the device

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: xxxxx@gmail.com
Sent: Tuesday, June 16, 2009 7:47 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Should WdfDeviceStopIdle be always followed by WdfDeviceResumeIdle?

> What are you really trying to do? Reset the idle timer when some event happens?
Yes.

> A typical kmdf driver uses power managed queues to control the idle state, letting kmdf perform all of
> the tracking and the driver has no stopidle()/resumeidle() calls in it.
Well, my problem is that my queue is not power managed. The device I’m working with has remote
wakeup, and when it is suspended and has a data to send, it wakes up. So, when the driver posts reads, they are returned with error and don’t wake the device. Hence, every time I have the data from the device, I want to reset the timer, and I call for WdfDeviceStopIdle and WdfDeviceResumeIdle.
Am I wrong with that design?

Thanks,
S.

—
NTDEV is sponsored by OSR

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

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

7

> Do you need to continuously read for data? Is it an entirely push driven data

model or do you also write data to the device
When a user-mode application is open, it does read the data continuously. We also write the data to the device.

Thanks,
S.

8

You should be using power managed queues. When the app’s reads go through a power managed queue, it wil make sure the device is in d0 before presenting the io to you. Making sure it is in d0 means stopping the idle timer and powering up if necessary. When the pwr managed queues are empty, the idle timer starts. Do the writes initiate from the driver or the app?

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, June 16, 2009 1:21 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Should WdfDeviceStopIdle be always followed by WdfDeviceResumeIdle?

Do you need to continuously read for data? Is it an entirely push
driven data model or do you also write data to the device
When a user-mode application is open, it does read the data continuously. We also write the data to the device.

Thanks,
S.

NTDEV is sponsored by OSR

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

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

9

> Do the writes initiate from the driver or the app?
Both reads and writes are initiated by the app. I moved the reads out of the managed queue because noticed that device doesn’t move to suspend when IN tokens are posted (although they are NAK-ed).
Won’t the subsequent call for WdfDeviceStopIdle(dev, FALSE) and WdfDeviceResumeIdle(dev) reset the timer?

Thanks,
S.

10

Imho, you are focused in on the wrong thing. You are now just trying to recreate a power managed queue on your own. Why does reseting the idle timer matter? If you want to idle with pending reads, move the reads to a non power managed queue and cancel them when you get D0Exit called. You then push writes and whatever else requires power through power managed queues and that will reset the idle timer.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Wednesday, June 17, 2009 12:05 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Should WdfDeviceStopIdle be always followed by WdfDeviceResumeIdle?

Do the writes initiate from the driver or the app?
Both reads and writes are initiated by the app. I moved the reads out of the managed queue because noticed that device doesn’t move to suspend when IN tokens are posted (although they are NAK-ed).
Won’t the subsequent call for WdfDeviceStopIdle(dev, FALSE) and WdfDeviceResumeIdle(dev) reset the timer?

Thanks,
S.

NTDEV is sponsored by OSR

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

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

11

Hello Doron,

Sorry for late response.

Why does reseting the idle timer matter? If you want to idle with pending reads, move the reads to
a non power managed queue and cancel them when you get D0Exit called. You then push writes
and whatever else requires power through power managed queues and that will reset the idle
timer.
In fact, I do handle writes via power-managed queue. The reason that I wanted to reset a timer is to prevent the driver to try to suspend the device if device has a data to be returned.
Here is a problem I saw which I wanted to work-around: if the device starts to send data exactly at the same moment when the host starts to suspend it, the data is lost.
So, to work-around somehow that race, I just wanted to reset the timer every time when I get data from device. This to reduce a chance that such a race will occur.

Now I observe additional problem: I have a device that has a data to send every 5 seconds. I suspend the device every 3 seconds, and after 2 seconds the device is suspended, it wakes up, and then it moves again to suspend after 3 seconds. I observe that after about 20 minutes of such a loop, my driver stops to suspend the device. Could it be related somehow to the timer and to my attempt to reset it?

Thanks,
S.

12

> Here is a problem I saw which I wanted to work-around: if the device

starts to send data exactly at the same moment when the host starts to
suspend it, the data is lost.
So, to work-around somehow that race, I just wanted to reset the timer
every time when I get data from device. This to reduce a chance that such
a race will occur.

Is this a race condition in your driver? If so, I’d suggest identifying and
fixing the race instead of working around it or trying to reduce the chances
of it occurring.

wrote in message news:xxxxx@ntdev…
> Hello Doron,
>
> Sorry for late response.
>> Why does reseting the idle timer matter? If you want to idle with
>> pending reads, move the reads to
>> a non power managed queue and cancel them when you get D0Exit called.
>> You then push writes
>> and whatever else requires power through power managed queues and that
>> will reset the idle
>> timer.
> In fact, I do handle writes via power-managed queue. The reason that I
> wanted to reset a timer is to prevent the driver to try to suspend the
> device if device has a data to be returned.
> Here is a problem I saw which I wanted to work-around: if the device
> starts to send data exactly at the same moment when the host starts to
> suspend it, the data is lost.
> So, to work-around somehow that race, I just wanted to reset the timer
> every time when I get data from device. This to reduce a chance that such
> a race will occur.
>
> Now I observe additional problem: I have a device that has a data to send
> every 5 seconds. I suspend the device every 3 seconds, and after 2 seconds
> the device is suspended, it wakes up, and then it moves again to suspend
> after 3 seconds. I observe that after about 20 minutes of such a loop, my
> driver stops to suspend the device. Could it be related somehow to the
> timer and to my attempt to reset it?
>
> Thanks,
> S.
>
>

13

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Monday, June 22, 2009 5:41 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Should WdfDeviceStopIdle be always
followed by WdfDeviceResumeIdle?

Now I observe additional problem: I have a device that has a
data to send every 5 seconds. I suspend the device every 3
seconds, and after 2 seconds the device is suspended, it
wakes up, and then it moves again to suspend after 3 seconds.
I observe that after about 20 minutes of such a loop, my
driver stops to suspend the device. Could it be related
somehow to the timer and to my attempt to reset it?

And everything else still works? For example, if you detach the device
and attach back, are both actions visible in Device Manager? No BSOD
after 10 minutes?

What you’re doing is not safe. Suspend/resume OS path is not bug free
and this way you provoke race conditions there. There were bugs in XP
and Vista which lead to BSOD sooner or later doing something as you do.
Easier at multi-core machines. I’m not sure about Win7 but I’d bet some
are still there.

BTW, suspend for 3 sec followed by 2 sec wake doesn’t make too much
sense. It can increase power consumption in some cases (depends on the
device).

Best regards,

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

14

> And everything else still works? For example, if you detach the device

and attach back, are both actions visible in Device Manager? No BSOD
after 10 minutes?
Both actions are visible in Device Manager, and I didn’t noticed BSOD.

Suspend/resume OS path is not bug free and this way you provoke race conditions there.
What kind of race should I expect? How can I work-around it?

Thanks,
S.

15

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Tuesday, June 23, 2009 12:29 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Should WdfDeviceStopIdle be always
followed by WdfDeviceResumeIdle?

> And everything else still works? For example, if you detach
the device
> and attach back, are both actions visible in Device Manager? No BSOD
> after 10 minutes?
Both actions are visible in Device Manager, and I didn’t
noticed BSOD.

In this case PnP/power management isn’t blocked and you have some
different problem.

> Suspend/resume OS path is not bug free and this way you
provoke race conditions there.
What kind of race should I expect? How can I work-around it?

Races inside OS drivers resulting to above mentioned block and BSOD
later (or immediate BSOD in some cases). The risk is proportional to
number of USB suspends and resumes and can be minimized by reducing
them. It isn’t linear, though. The worst problem is wake just after real
suspend but when you allow suspend, it takes some time depending on the
machine. So if you allow suspend and disallow it after few sec, the real
suspend time can be few ms and it is a problem. You can see it with USB
analyser.

Best regards,

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

16

> So if you allow suspend and disallow it after few sec, the real suspend time can be few ms and it is a

problem. You can see it with USB analyser.

Does that mean that if I dis-allow suspend and then allow it (by calling for WdfDeviceStopIdle and then by calling for WdfDeviceResumeIdle), it can somehow race with PnP manager and won’t suspend the device? Could you thing about that kind of scenario?

17

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Wednesday, June 24, 2009 9:44 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Should WdfDeviceStopIdle be always
followed by WdfDeviceResumeIdle?

> So if you allow suspend and disallow it after few sec, the
real suspend time can be few ms and it is a
> problem. You can see it with USB analyser.

Does that mean that if I dis-allow suspend and then allow it
(by calling for WdfDeviceStopIdle and then by calling for
WdfDeviceResumeIdle), it can somehow race with PnP manager
and won’t suspend the device? Could you thing about that kind
of scenario?

Only in the case when Dx or D0 IRP is blocked forever. It always leads
to BSOD after 10 minutes (there is a watchdog) and blocks any PnP
operation like attaching a new devices or scan for device changes in DM.
If you don’t see these symptoms, you have different problem.

Best regards,

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

18

Specifically Michal is referring to usb core stack issues around idle, power irps, and pnp state changing irps. This is not a bug in the pnp or power managers in the kernel or in PCI or other busses, but rather very specific to Vista’s core USB driver stack (usbhub, usbccgp, usbport)

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Wednesday, June 24, 2009 12:56 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Should WdfDeviceStopIdle be always followed by WdfDeviceResumeIdle?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Wednesday, June 24, 2009 9:44 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Should WdfDeviceStopIdle be always followed by
WdfDeviceResumeIdle?

> So if you allow suspend and disallow it after few sec, the
real suspend time can be few ms and it is a
> problem. You can see it with USB analyser.

Does that mean that if I dis-allow suspend and then allow it (by
calling for WdfDeviceStopIdle and then by calling for
WdfDeviceResumeIdle), it can somehow race with PnP manager and won’t
suspend the device? Could you thing about that kind of scenario?

Only in the case when Dx or D0 IRP is blocked forever. It always leads to BSOD after 10 minutes (there is a watchdog) and blocks any PnP operation like attaching a new devices or scan for device changes in DM.
If you don’t see these symptoms, you have different problem.

Best regards,

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

NTDEV is sponsored by OSR

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

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

19

Yes, exactly. I should be more specific to avoid possible confusion. I
wasn’t because original question was about USB (at least I hope so) but
it is already lost in list archives :wink:

Best regards,

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, June 24, 2009 11:00 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Should WdfDeviceStopIdle be always
followed by WdfDeviceResumeIdle?

Specifically Michal is referring to usb core stack issues
around idle, power irps, and pnp state changing irps. This
is not a bug in the pnp or power managers in the kernel or in
PCI or other busses, but rather very specific to Vista’s core
USB driver stack (usbhub, usbccgp, usbport)

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Wednesday, June 24, 2009 12:56 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Should WdfDeviceStopIdle be always
followed by WdfDeviceResumeIdle?

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@gmail.com
> Sent: Wednesday, June 24, 2009 9:44 AM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] Should WdfDeviceStopIdle be always followed by
> WdfDeviceResumeIdle?
>
> > So if you allow suspend and disallow it after few sec, the
> real suspend time can be few ms and it is a
> > problem. You can see it with USB analyser.
>
> Does that mean that if I dis-allow suspend and then allow it (by
> calling for WdfDeviceStopIdle and then by calling for
> WdfDeviceResumeIdle), it can somehow race with PnP manager and won’t
> suspend the device? Could you thing about that kind of scenario?

Only in the case when Dx or D0 IRP is blocked forever. It
always leads to BSOD after 10 minutes (there is a watchdog)
and blocks any PnP operation like attaching a new devices or
scan for device changes in DM.
If you don’t see these symptoms, you have different problem.

Best regards,

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

NTDEV is sponsored by OSR

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

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

NTDEV is sponsored by OSR

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

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

20

Well, I removed the WdfDeviceStopIdle(dev, FALSE) and WdfDeviceResumeIdle(dev) calls to reset the timer, as Doron sugested.

No I observe another problem.
Actually I have my driver split onto 2 drivers - first driver (Drv1) is installed for the device, and creates a child device object by calling for WdfChildListAddOrUpdateChildDescriptionAsPresent, on which I install another driver (Drv2).
For Drv1 I call for WdfDeviceAssignS0IdleSettings with IdleUsbSelectiveSuspend and IdleTimeout = 1000 (1 sec) in idle settings.
For Drv2 I call for WdfDeviceAssignS0IdleSettings with IdleCanWakeFromS0 and IdleTimeout = 4000 (4 sec) in idle settings. Drv2 manages power-managed queue for writes and non-power-managed queue for reads and ioctls. 2 drivers communicate via driver device interface (not IRPs).
I also have a device with a test firmware, which wakes up after 2 seconds that it was suspended and sends some data.

I observe the following behavior:

  • When device has no data to send, Drv2 moves to D2 after 4 secs, then Drv1 moves to D2 after 1 sec (and sometimes after 2 secs).
  • Then, after 2 secs device wakes up Drv1, which wakes up Drv2. Then Drv2 tells Drv1 to read the data (and here is the place I tries to call for WdfDeviceStopIdle and WdfDeviceResumeIdle to reset the timer - the functionality that I removed), and when there is no data any more, suspends again after 4 secs. Then, Drv1 suspends after 1 sec later.
  • After 30 minutes of such a cycle I observe the following behavior: I can see that Drv2 enters to D0Exit callback, but Drv1 doesn’t enters it’s D0Exit callback after. There is no blocking WdfDeviceStopIdle call from my driver, I double-checked that.

That behavior occurs on XP SP3 only, I didn’t encounter it on XP SP2 or on Vista.

I also tried to perform something else:

  • I set the IdleTimeout for Drv1 to IdleTimeoutDefaultValue (=0).
  • Upon call of Drv2D0Entry I called for WdfDeviceStopIdle for Drv1, and upon Drv2D0Exit I called for WdfDeviceResumeIdle for Drv1. What I could see that Drv1D0Exit was called after 5-6 seconds after Drv2D0Exit (which was called after 4 seconds, as specified). Just to verify that there is no dependency on Drv2’s IdleTimeout, I changed it to 10 seconds, and saw the same - Drv1D0Exit called after 5-6 seconds after Drv2D0Exit.

What could be the problem here?

Thanks,
S.