Can an application wake before a user-mode driver?

NTDEV
1

Hello,

I’m using a UMDF driver.
My application opens a handle to the driver when Windows boots, and keeps using the same handle until Windows shuts down.
Sometimes, when the system wakes from Sleep\Hibernate, the application crashes.
After debugging the issue, it seems that the handle (at the application level) is invalid while waking from the low power state.
This results in an application crash.
This happens in higher frequency if the firmware takes longer time to wake (due to FW code issues).
My questions are -

  1. Isn’t there a mechanism which is supposed to prevent the application from waking before the driver? Or at least preventing it to try and use the handle?
    Maybe because it’s a user mode driver they wake at the same time?
  2. When the driver wakes, I do a few initialization operations between the driver and the FW (questions and answers, some sort of handshake). Requests arriving from applications at that time are queued, aren’t they?

*** As opposed to the phenomena I’ve mentioned in the past, this time the driver doesn’t crash (so I guess it is not related to the (non) power managed queues issue).

Thanks,
Gadi

2

With fast resume, yes, the application can start running while the driver is powering up. As long as you use power managed queues in your umdf driver to guard access to your hardware access from/to the application, this is not a problem though as UMDF will pend these requests until you power up.

In what callback do you do the “Few initialization operations between the driver and the fw”? if you do this in D0Entry or SelfManagedIoRestart, yes the requests are still pended in the power managed queues

None of this will invalidate the application’s handle to the device driver though. Based on this statement, " This happens in higher frequency if the firmware takes longer time to wake (due to FW code issues)," I am guessing that b/c you have FW code issues the device is falling off of the device bus (is it usb?) and being surprise removed. Is your application registering for notifications on the handle it has opened against your driver? If so, my guess would be that this code which handles the notifications for the device handle has run, closed the handle and the other part of your application is not synchronized with the notification code and is using the handle after you have closed it.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@n-trig.com
Sent: Sunday, December 23, 2007 6:26 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Can an application wake before a user-mode driver?

Hello,

I’m using a UMDF driver.
My application opens a handle to the driver when Windows boots, and keeps using the same handle until Windows shuts down.
Sometimes, when the system wakes from Sleep\Hibernate, the application crashes.
After debugging the issue, it seems that the handle (at the application level) is invalid while waking from the low power state.
This results in an application crash.
This happens in higher frequency if the firmware takes longer time to wake (due to FW code issues).
My questions are -

  1. Isn’t there a mechanism which is supposed to prevent the application from waking before the driver? Or at least preventing it to try and use the handle?
    Maybe because it’s a user mode driver they wake at the same time?
  2. When the driver wakes, I do a few initialization operations between the driver and the FW (questions and answers, some sort of handshake). Requests arriving from applications at that time are queued, aren’t they?

*** As opposed to the phenomena I’ve mentioned in the past, this time the driver doesn’t crash (so I guess it is not related to the (non) power managed queues issue).

Thanks,
Gadi

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

My code is based on the FX2 sample (it is a USB device).

  1. When I was visited MS, I had the following issue –
    When the device was supposed to wake from D2, messages from the host to the device, on the Control queue (power managed queue), weren’t sent until messages from the device to the host, on the ReadWriteQueue (non power managed) arrived.
    The WDF team told me that the control queue should also be non power managed, and this did resolve the issue.
    So, I believe, changing the control queue back to being power managed would mess up with selective suspend scenario again.
    Is there any other option?

  2. If the device does fall off of the device bus, should the application check every time there is a power transition whether the handle is valid? And if it’s not, should it perform some sort of busy wait until it is valid again, or create a new one? (the driver is operational and new applications can connect to it after the first one crashed).

Thanks,
Gadi

4

1 I pointed out power managed queues b/c you talked about the application sending i/o with repect to resume from Sx. I don’t think you need to change anything, esp b/c winusb is doing the power management on your behalf.

2 the handle is valid until the application closes it, the driver cannot invalidate the handle. All that could happen on surprise remove from the driver point of view is to fail new and outstanding i/o until the application closes its handle. The app should not do a busy wait or anything like that, the application needs to synchronize its state between the notification that the device was surprise removed and all other threads using the handle and only when all the threads are not using the handle, close it. Again, I highly suspect this is a state synchronization problem in your application.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@n-trig.com
Sent: Monday, December 24, 2007 7:58 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Can an application wake before a user-mode driver?

My code is based on the FX2 sample (it is a USB device).

  1. When I was visited MS, I had the following issue -
    When the device was supposed to wake from D2, messages from the host to the device, on the Control queue (power managed queue), weren’t sent until messages from the device to the host, on the ReadWriteQueue (non power managed) arrived.
    The WDF team told me that the control queue should also be non power managed, and this did resolve the issue.
    So, I believe, changing the control queue back to being power managed would mess up with selective suspend scenario again.
    Is there any other option?

  2. If the device does fall off of the device bus, should the application check every time there is a power transition whether the handle is valid? And if it’s not, should it perform some sort of busy wait until it is valid again, or create a new one? (the driver is operational and new applications can connect to it after the first one crashed).

Thanks,
Gadi

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

I’d also like to point out that an application can use its handle to a
device even before a kernel-mode driver has gotten a message saying
that the system is moving back to S0. Applications are only suspended
in the sense that they stop executing when the system leave S0. Once
the processors start running again upon wake, after any PASSIVE_LEVEL
code can run at all, the apps get scheduled just like anything else.

In many cases, applications stop executing as the system goes to sleep
because they take a page fault after the disk has stopped spinning.
But there’s certainly no guarantee of this.

  • Jake Oshins
    Windows Kernel Guy
    Author of a lot of Windows code related to sleep states

“Doron Holan” wrote in message
news:xxxxx@ntdev…
> 1 I pointed out power managed queues b/c you talked about the
> application sending i/o with repect to resume from Sx. I don’t
> think you need to change anything, esp b/c winusb is doing the power
> management on your behalf.
>
> 2 the handle is valid until the application closes it, the driver
> cannot invalidate the handle. All that could happen on surprise
> remove from the driver point of view is to fail new and outstanding
> i/o until the application closes its handle. The app should not do
> a busy wait or anything like that, the application needs to
> synchronize its state between the notification that the device was
> surprise removed and all other threads using the handle and only
> when all the threads are not using the handle, close it. Again, I
> highly suspect this is a state synchronization problem in your
> application.
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@n-trig.com
> Sent: Monday, December 24, 2007 7:58 AM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] Can an application wake before a user-mode
> driver?
>
> My code is based on the FX2 sample (it is a USB device).
> 1. When I was visited MS, I had the following issue -
> When the device was supposed to wake from D2, messages from the host
> to the device, on the Control queue (power managed queue), weren’t
> sent until messages from the device to the host, on the
> ReadWriteQueue (non power managed) arrived.
> The WDF team told me that the control queue should also be non power
> managed, and this did resolve the issue.
> So, I believe, changing the control queue back to being power
> managed would mess up with selective suspend scenario again.
> Is there any other option?
>
> 2. If the device does fall off of the device bus, should the
> application check every time there is a power transition whether the
> handle is valid? And if it’s not, should it perform some sort of
> busy wait until it is valid again, or create a new one? (the driver
> is operational and new applications can connect to it after the
> first one crashed).
>
> Thanks,
> Gadi
>
>
>
> —
> 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
>