WHQL tests

NTDEV
1

Now that I finally got DTM started :slight_smile: I wonder if anyone could nudge me in the right
direction of testing a bulk usb driver (which is based on the WDK bulkusb example).

  1. Which test(s) are applicable for a WHQL certification (the driver is heading for
    Windows Update) ?
  2. Would it suffice testing the driver only ? I.e. omitting the device(s) it is meant to
    communicate with?

TIA
/Rob

2

Hi Rob,

  1. It depends! Does your device fall into one of the existing categories? If not then “Unclassified” is the test for you.

  2. For USB drivers you need the device connected, otherwise you will find DTM will complain about the driver not being loaded.

Good luck,
Tim.

From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] On Behalf Of Robert Bielik [xxxxx@xponaut.se]
Sent: 02 April 2010 11:34
To: Windows System Software Devs Interest List
Subject: [ntdev] WHQL tests

Now that I finally got DTM started :slight_smile: I wonder if anyone could nudge me in the right
direction of testing a bulk usb driver (which is based on the WDK bulkusb example).

  1. Which test(s) are applicable for a WHQL certification (the driver is heading for
    Windows Update) ?
  2. Would it suffice testing the driver only ? I.e. omitting the device(s) it is meant to
    communicate with?

TIA
/Rob

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

Tim Green skrev:

Hi Rob,

  1. It depends! Does your device fall into one of the existing categories? If not then “Unclassified” is the test for you.

Hmm… yeah, so far that’s the category I found applicable :slight_smile:

  1. For USB drivers you need the device connected, otherwise you will find DTM will complain about the driver not being loaded.

Thanks Tim, that’s a good start :slight_smile:

/R

4

Tim Green skrev:

  1. For USB drivers you need the device connected, otherwise you will find DTM will complain about the driver not being loaded.

Our INF file is “prepped” to be “future proof” with a lot of PIDs that don’t exist yet. Suddenly I got a bad feeling that the WHQL tests
will be done for all hw ids in the INF file. Please tell me this is not the case ?

TIA
/Rob

5

> Suddenly I got a bad feeling that the WHQL tests will be done for all hw ids in the INF file.

Please tell me this is not the case?

This is not the case.

Tim.

6

xxxxx@displaylink.com skrev:

> Suddenly I got a bad feeling that the WHQL tests will be done for all hw ids in the INF file.
> Please tell me this is not the case?

This is not the case.

Thnx Tim, made my day :slight_smile:

/R

7

Ok, we’d like to have the driver up on windows update for XP, Vista and Win7 (32 and 64 bit flavors). What is the requirement
for tests then? Do I need to set up 6 machines, or would it suffice passing for Win7 x64 ??

TIA
/Rob

8

> Ok, we’d like to have the driver up on windows update for XP, Vista and Win7

(32 and 64 bit flavors). What is the requirement
for tests then? Do I need to set up 6 machines, or would it suffice passing
for Win7 x64 ??

It seems if you do not test on XP then, while you can get the driver signature for no extra effort after Win7 testing, you cannot then post the driver on Windows Update.

For each OS on Windows Update you need to supply the DTM logs, both x64 and x86 if that is what you want.

You can speed up the DTM testing by doubling the number of test PCs for each OS flavour. You can roughly half the time required if you schedule the longest job first.

Regards,
Tim Green
Development Engineer
DisplayLink (UK) Limited
Registered in England No. 04811048

9

You won’t be able to get your INF signed for device ID that you don’t test.

“Robert Bielik” wrote in message
news:xxxxx@ntdev…
> Tim Green skrev:
>> 2. For USB drivers you need the device connected, otherwise you will find
>> DTM will complain about the driver not being loaded.
>
> Our INF file is “prepped” to be “future proof” with a lot of PIDs that
> don’t exist yet. Suddenly I got a bad feeling that the WHQL tests
> will be done for all hw ids in the INF file. Please tell me this is not
> the case ?
>
> TIA
> /Rob
>

10

Alex Grig wrote:

You won’t be able to get your INF signed for device ID that
you don’t test.

This was never my experience, I always ran DTM against one instance of my device (in my case, one USB PID) and the INF contained many other PIDs as well. The signed .cat that I got back was for the entire .INF.

11

xxxxx@gmail.com skrev:

Alex Grig wrote:

> You won’t be able to get your INF signed for device ID that
> you don’t test.

This was never my experience, I always ran DTM against one instance of my device (in my case, one USB PID) and the INF contained many other PIDs as well. The signed .cat that I got back was for the entire .INF.

Ok, seems to be some disagreemnent here… Doron, do you know what the beef is with this?

While I’m at it, some questions: Since the devices are composite, with a bulk endpoint and a MIDI streaming endpoint, the
driver package is composed of a “composite” INF, which just points to usbccgp, and an INF for the bulk endpoint (MIDI is
handled by Windows).

To certify this package, do I have to test both the MIDI and the bulk device ? Or would it suffice only with the bulk one, since
it’s the one we supply an actual driver for ?

TIA
/Rob