Re: Vista WHQL PnP failure question

I'm quite positive that the device supports selective suspend, and this
morning re-confirmed that it does with an Ellisys USB analyzer on both XP SP3
and Vista SP2. A "SetFeature(RemoteWakeup)" is sent out, the device enters
selective suspend. Upon wake, a "Clear Feature(RemoteWakeup)" is sent out.
Both transactions were successful and returned an "ACK" packet.

The power management tab of both XP and Vista have a check box checked that
says "Allow the computer to turn off this device to save power".

Concerning the sequence, I was basing my statement off of the KMDF & Kernel
Mode Driver Architecture documents provided on-line at MSDN (I do not own the
book you refer to, but it's now on my "Buy Real Soon" list). Under "Windows
Driver Kit -> Kernel-Mode Driver Architecture -> Design Guide -> Writing WDM
Drivers -> Implementing Power Management -> Managing Power for Individual
Devices -> Device Power States", the final paragraph says:

"Like the system, a device can transition from the working state (D0) to any
sleeping state (D1-D3) and from any sleeping state to the working state."

Under "Windows Driver Kit -> Windows Driver Foundation -> Kernel-Mode Driver
Framework -> Design Guide -> PnP and Power Management in Framework-Based
Drivers -> PnP and Power Management Scenarios -> A Device Enters a Low-Power
State", there's no mention of a call to the "IO Flush" callback. In the
collected logs, the "IO Flush" callback takes place about 12 seconds -after-
the "D0 Exit to D2 (Selective Suspend)" callback completes, so I don't think
it's part of the entry into selective suspend. The only time I see the "IO
Flush" callback mentioned is under the "A User Unplugs a Device" scenario.
And in order to hit that scenario, the driver must be brought back to D0 per
the section I mentioned in the preceding paragraph. This seems to have
changed in Vista versus XP. XP brings the driver back to D0 first, then
takes it to D3. Vista just does a D2 to D3 transition (if a bus powered
device is removed, it's certainly no longer in D2).

However, my driver works regardless of whether or not it returned to D0
first. Under WHQL testing, ithe driver is not handling any traffic, so has
no cleanup to perform. Also, since the device went from D2 to D3 directly,
the driver does not perform a reset of the device (i.e. the device will not
re-enumerate). When told to perform an "IO Flush", the driver assumes that
the device is physically gone.

Here's a DbgView output snippet starting from when the "IO Suspend" is
received by my driver. My driver has a prefix of "CtbUsb":

--------------------
00000226 64.85100555 Ctb:--> pwrIoSuspend
00000227 64.85101318 Ctb:--> CtbReaderStop
00000228 64.85102081 Ctb:<-- CtbReaderStop (not started)
00000229 64.85102081 Ctb:<-- pwrIoSuspend
00000230 64.85131073 PNPFILTR: List has 0 entries
00000231 64.85131836 PNPFILTR: Processed 0 IRPs
00000232 64.85133362 PNPFILTR: List has 0 entries
00000233 64.85133362 PNPFILTR: Processed 0 IRPs
00000234 64.85134125 Ctb:--> pwrD0Exit (3)
00000235 64.85134888 Ctb:<-- pwrD0Exit (in DFU mode/target state
not 5)
00000236 66.62499237 PNPFILTR: Received IRP_MN_QUERY_CAPABILITIES
which I am simply passing down
00000237 66.64597321 PNPFILTR: Received IRP_MN_QUERY_CAPABILITIES
which I am simply passing down
00000238 66.65718079 PNPFILTR: Received IRP_MN_QUERY_INTERFACE
which I am simply passing down
00000239 76.08638763 PNPFILTR: Received IOCTL_QUERY_DEVICE_COUNT
00000240 76.08644867 PNPFILTR: Received
IOCTL_QUERY_HARDWARE_ID_SIZE for PDO 0x9DF3D030
00000241 76.08652496 PNPFILTR: Received IOCTL_QUERY_HARDWARE_ID
for PDO 0x9DF3D030
00000242 76.08661652 PNPFILTR: Received
IOCTL_SURPRISE_REMOVE_DEVICE for PDO 0x9DF3D030
00000243 76.08661652 PNPFILTR: Calling IoInvalidateDeviceState to
start rebalance on PDO 9DF3D030
00000244 76.08663177 PNPFILTR: Received
IRP_MN_QUERY_PNP_DEVICE_STATE for stack with PDO 0x9DF3D030
00000245 76.08679962 PNPFILTR: Recieved Query Result
00000246 76.08680725 PNPFILTR: Waiting for test to be completed -
will wait for 50 seconds
00000247 76.08682251 PNPFILTR: FilterCompletionRoutine Completed,
event set.
00000248 76.08683014 PNPFILTR: Completing
IRP_MN_QUERY_PNP_DEVICE_STATE for PDO 0x9DF3D030 with status 0x00000000 and
information 0x00000004
00000249 76.08685303 PNPFILTR: Received
IRP_MN_QUERY_DEVICE_RELATIONS which I am simply passing down
00000250 76.08687592 PNPFILTR: Received IRP_MN_SURPRISE_REMOVAL
for stack with PDO 0x9DF3D030
00000251 76.08901215 Ctb:--> pwrIoFlush
00000252 76.08901978 Ctb:--> CtbReaderFlush
00000253 76.08902740 Ctb:<-- CtbReaderFlush
00000254 76.08902740 Ctb:--> pmdtStopPmdt
00000255 76.08902740 Ctb:<-- pmdtStopPmdt
00000256 76.08903503 Ctb:<-- pwrIoFlush
00000257 76.08925629 PNPFILTR: FilterSurpriseRemove returning
0x00000103 for stack with PDO 0x9DF3D030
00000258 76.11583710 PNPFILTR: Received IRP_MN_REMOVE_DEVICE for
stack with PDO 0x9DF3D030
00000259 76.11583710 PNPFILTR: Setting the test completed event
00000260 76.11584473 PNPFILTR: Waiting for result to be stored
00000261 76.11585236 PNPFILTR: Query Result Wait Satisfied... 4
00000262 76.11585236 PNPFILTR: Number of IRPs Stored... 4
00000263 76.11586761 PNPFILTR: Query Result - Releasing the remove
00000264 76.11587524 PNPFILTR: Remove Wait completed... now
deleting
00000265 76.11587524 PNPFILTR: List has 0 entries
00000266 76.11588287 PNPFILTR: Processed 0 IRPs
00000267 76.11589813 PNPFILTR: Query Result -Result Stored Event
set
00000268 76.13028717 PNPFILTR: Deleting the global control object
00000269 76.13031006 PNPFILTR: FilterRemove returning 0x00000000
for stack with PDO 0x9DF3D030
--------------------

Is there some new Vista requirement for D2 -> D3 support that's needed?
I've removed the device while it was in selective suspend, and that operation
works fine in both Vista and XP. Likewise, I've issued a "Disable" request
from the device manager, and under that scenario Vista acts like XP. The
only remaining issue seems to be with this PnP test.

Thanks,
Michael

"Egidio [MSFT]" wrote:

The sequence below seems correct and consistent with the flow you can find
in pages 181 to 189 of Windows Driver Foundation book. It may be possible
that in XP the device doesn't support selective suspend. Please check the
device characteristics of your node (device manager). Do you see the
PowerManager tab in XP? like you see in Vista.
What are the info you see in Details->Power Data in both XP and Vista for
this device?
Is it possible that this device doesn't support selective suspend?

Thx,
Egi.

"dhmot" <dhmot@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:1A229197-B74F-4822-9CC4-FAEE1510B4E9@xxxxxxxxxxxxxxxx
To answer your questions (#5 is probably the most important):

1) As far as I can tell, the test runs - I see the PnP window appear for
a
short period, maybe a few seconds, at least twice during the PnP test. At
the end of my response, I've included the log file (uuencoded zip file).

2) I do nothing special for a surprise remove that I do for any other
condition that causes the device to enter D3; it's the same code that's
used
if someone right-clicks on the device in device manager and "Disable"s it.

3) I re-ran the test with the selective suspend time-out cranked down to
one second on Windows XP. This should cause the driver and device to
enter
selective suspend. The test still passed on Windows XP.

4) As far as I'm aware, my driver is not a child of USBCCGP. I assume
this
is something I'd have to call out explicitly. If not, please tell me how
I'd
know.

5) I performed a log comparison and found one major difference just prior
to
the second driver re-load (initial driver load on boot-up, first driver
re-load after start of test, then second driver re-load). On XP, the
callback sequence after the first driver re-load was as follows:

DriverEntry
Device Add
Prepare Hardware
IO Init
IO Suspend
D0 Exit to D3
IO Flush

The above is what I would normally expect. However, Vista threw the
following at my driver:

DriverEntry
Device Add
Prepare Hardware
IO Init
IO Suspend
D0 Exit to D2 (selective suspend)
IO Flush

I would have expected it to have called my IO Restart callback after the
D0
Exit to D2, then IO Suspend, then D0 Exit to D3, and THEN IO Flush.
Turning
on WDF Verifier did not affect this. After this occurs, Vista re-loads my
driver and stops testing while XP continues testing.

6) I did not have WDF Verifier enabled for either Vista or XP. Once I
discovered #5, I re-ran the test on Vista with WDF Verifier enabled for
the
USB driver (I'm not sure how to enable it for WDF01000). There was no
change
in the test results.

7) I have no Windows 7 machines available to me at the moment.

Any ideas why #5 is happening?

Thanks,
Michael

PnP result log:







"Egidio [MSFT]" wrote:

Just to understand more about this error.
does the surprise remove test run? or doesnâ?Tt even run because the
device is
not initializing correctly, i.e., the previous test left the device in a
strange state?
Do you do anything in your driver when you receiving surprise remove?
When XP works, is the device in selective suspend? I.e., is it possible
that in the XP case you don't see a problem b/c the device never enters
the
selective suspend state?
Is your client driver a child of USBCCGP?
Do you see the same callbacks from your driver point of view in both the
XP
and Vista cases?
Did you make sure to enable device verifier and wdf verifier on your
driver
and wdf01000?
Since Win7 is available, do you see any problem in Win7? Win7 has better
logging for USB.

Egi.

"dhmot" <dhmot@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:5E3C4F23-83C8-4BFF-8AE7-3243860E4C2A@xxxxxxxxxxxxxxxx
The same hardware series is used (Dell Precision 380), although not
exactly
the same machine. The failure occurs with three different devices on
Vista
(all that are available to me), and at least one of those passes on XP.
WDF
Framework 1.7 is used for both, not 1.9. I can't say if it's exactly
the
same PnP test, as one is run on Vista and the other on XP. I do have
the
latest filters and have installed QFE011 & QFE002.

So as far as I can tell, the only difference is the OS.

If you think there's some benefit, I can try swapping hard drives
between
the XP and Vista machines to see if that makes a difference. Let me
know.

Michael

"Egidio [MSFT]" wrote:

Just to clarify, what is different in your environment from Vista and
XP?
Only the OS? Is everything else is the same? system h/w, device h/w,
WDF
framework 1.9, PnP tests?
Otherwise can you try re-running the tests on the h/w that works?

Egi.

"dhmot" <dhmot@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:B3EA455C-E94A-4A4F-A145-B8E5C14ADDBF@xxxxxxxxxxxxxxxx
All,

I'm sure you're all tired of hearing of my WHQL trials and
tribulations
:),
but I've got another question. I have a KMDF driver for a USB
device.
The
device and driver support selective suspend, and have a default
selective
suspend time-out of five seconds. If I run the PnP Driver Test on
an
x86
Vista + SP2 Dell Precision 380, the test fails unless I disable
selective
suspend first. The surprise removal test is the test that fails
with
an
error of "Device node status not ok: problem code 10". I've
confirmed
that
my driver is not returning any errors nor is it hitting any code I
would
not
expect it to hit. Likewise, I see nothing wayward in the debug
output
from
the PNP filter captured via Dbgview.

If I disable selective suspend, all "PnP Driver Test" tests pass
under
x86
Vista. Likewise, all "PnP Driver Test" tests pass under XP (x86 and
x64)
with selective suspend enabled.

What's the proper solution for this?

Thanks,
Michael




.

Relevant Pages

  • Re: Vista WHQL PnP failure question
    ... I'm selecting the same PnP DTM test on both XP and Vista. ... After the surprise removal test completes, my driver is reloaded. ... returning 0x00000000 for stack with PDO 0x85921030 ... it's part of the entry into selective suspend. ...
    (microsoft.public.development.device.drivers)
  • Re: Vista WHQL PnP failure question
    ... is it possible that in the XP case you don't see a problem b/c the device never enters the selective suspend state? ... Is your client driver a child of USBCCGP? ... Do you see the same callbacks from your driver point of view in both the XP and Vista cases? ... > If I disable selective suspend, all "PnP Driver Test" tests pass under ...
    (microsoft.public.development.device.drivers)
  • Re: Vista WHQL PnP failure question
    ... Of course you need to run the above dbg commands before the driver is removed from the system. ... For Vista, the debug symbol in USBCCGP is dbgLevel. ... returning 0x00000000 for stack with PDO 0x85921030 ... > I'm quite positive that the device supports selective suspend, ...
    (microsoft.public.development.device.drivers)
  • Re: Selective suspend of USB device on Vista 64 OS
    ... Since KS doesn't support selective suspend natively, AFIK, I'm wondering how you are getting this to work in your driver. ... The driver supports Windows XP 32/64 and Vista 32/64. ...
    (microsoft.public.development.device.drivers)
  • Re: Stops Working
    ... I have found Vista to be very sensitive to video driver problems. ... Sony Acid 4 is a very old version, so I thought I might have trouble with it. ... Word, IE, Windows Explorer and Sony music mixing software never quit while running under the XP operating system. ...
    (microsoft.public.windows.vista.performance_maintenance)
Loading