chkinf errors for new class guid

NTDEV
1

Hi,

We have a function driver for our USB peripheral. We use our own class
GUID and installer for driver and INF file. When I run chkinf tool with
the INF file, it reports an error saying it cannot recognize the Class
GUID and the device class name.

What needs to be done?

Thanks.

2

xxxxx@hotmail.com wrote:

We have a function driver for our USB peripheral. We use our own class
GUID and installer for driver and INF file. When I run chkinf tool with
the INF file, it reports an error saying it cannot recognize the Class
GUID and the device class name.

What needs to be done?

You’ll have to get a variance from WHQL. For some reason, they don’t
like to certify driver packages with custom setup classes. Never mind
that the DDK describes how to *create* these custom classes without
giving you a clue that you’re going to have this problem downstream.

–
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

3

I am new to this WHQL stuff? What do you mean by “variance”?

Can I call the api SetupDiInstallClass in the installer inorder for the
system to recognise the new device class.

The comments section in the DDK for this api says
" This function is called by a class installer when it installs a device
of a new device class"

I have one more question:
If I use the standard device class “USB”, which exe/dll needs to be called
for install and un-install and update of the driver file.

Thanks for your quick response

4

xxxxx@hotmail.com wrote:

I am new to this WHQL stuff? What do you mean by “variance”?

That’s actually slang for getting approval from a local government for
an exception to the zoning laws or building codes. Anyway, you need to
contact WHQL and explain to them why you need a custom setup class.

Can I call the api SetupDiInstallClass in the installer inorder for the
system to recognise the new device class.

WHQL won’t want you to have your own installation program that does
this. The approved way to proceed is to (a) copy all your files onto a
local drive, (b) call SetupCopyOEMInf. You’re then supposed to let the
system detect your device, whereupon it will automatically and silently
install your signed driver package.

In other words, you shouldn’t need a custom installation program that
calls functions like SetupDiInstallClass.

If I use the standard device class “USB”, which exe/dll needs to be called
for install and un-install and update of the driver file.

I don’t understand what you mean here. The setup subsystem automatically
locates the required installer and coinstaller files. There’s no need
for you to specify them.

Additionally, the setup class USB is supposedly only for hubs and
controllers. Many companies mistakenly put their widgets into this
class, and WHQL seems to let this go by. Maybe because of the
bureaucratic hassle of getting a variance for a custom class.

–
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

5

We encountered the same problem during WHQL certification of a USB
device/driver. Chkinf complained about our private device class.
We got advice from WHQL support to use the USB class.
Quotation from the email:
“We have already changed the statement in the DDK regarding USB Class
usage, as you may know there are many other USB devices that are using
Class=USB. Such as USB Composite device, USB Mass Storage device and
etc… So Class=USB is not limited to the Host Controller or Hub anymore.”

However, certification of the device is still in progress. So I cannot
tell if WHQL will really accept this.

Udo Eberhardt
Thesycon GmbH

Walter Oney wrote:

xxxxx@hotmail.com wrote:

>I am new to this WHQL stuff? What do you mean by “variance”?

That’s actually slang for getting approval from a local government for
an exception to the zoning laws or building codes. Anyway, you need to
contact WHQL and explain to them why you need a custom setup class.

>Can I call the api SetupDiInstallClass in the installer inorder for the
>system to recognise the new device class.

WHQL won’t want you to have your own installation program that does
this. The approved way to proceed is to (a) copy all your files onto a
local drive, (b) call SetupCopyOEMInf. You’re then supposed to let the
system detect your device, whereupon it will automatically and silently
install your signed driver package.

In other words, you shouldn’t need a custom installation program that
calls functions like SetupDiInstallClass.

>If I use the standard device class “USB”, which exe/dll needs to be called
>for install and un-install and update of the driver file.

I don’t understand what you mean here. The setup subsystem automatically
locates the required installer and coinstaller files. There’s no need
for you to specify them.

Additionally, the setup class USB is supposedly only for hubs and
controllers. Many companies mistakenly put their widgets into this
class, and WHQL seems to let this go by. Maybe because of the
bureaucratic hassle of getting a variance for a custom class.

–
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

You are currently subscribed to ntdev as: xxxxx@thesycon.de
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

This is not the best thought out whql policy. The consequences are going to
be the proliferation of devices in ‘catch all’ classes such as System or
Usb. I predict a reversal down the road a bit to cleanup the mess they’ve
created.

-----Original Message-----
From: Udo Eberhardt [mailto:xxxxx@thesycon.de]
Sent: Wednesday, May 28, 2003 4:55 AM
To: NT Developers Interest List
Subject: [ntdev] Re: chkinf errors for new class guid

We encountered the same problem during WHQL certification of a USB
device/driver. Chkinf complained about our private device class. We got
advice from WHQL support to use the USB class. Quotation from the email: “We
have already changed the statement in the DDK regarding USB Class usage, as
you may know there are many other USB devices that are using Class=USB. Such
as USB Composite device, USB Mass Storage device and etc… So Class=USB is
not limited to the Host Controller or Hub anymore.”

However, certification of the device is still in progress. So I cannot
tell if WHQL will really accept this.

Udo Eberhardt
Thesycon GmbH

Walter Oney wrote:

xxxxx@hotmail.com wrote:

>I am new to this WHQL stuff? What do you mean by “variance”?

That’s actually slang for getting approval from a local government for
an exception to the zoning laws or building codes. Anyway, you need to
contact WHQL and explain to them why you need a custom setup class.

>Can I call the api SetupDiInstallClass in the installer inorder for
>the system to recognise the new device class.

WHQL won’t want you to have your own installation program that does
this. The approved way to proceed is to (a) copy all your files onto a
local drive, (b) call SetupCopyOEMInf. You’re then supposed to let the
system detect your device, whereupon it will automatically and
silently install your signed driver package.

In other words, you shouldn’t need a custom installation program that
calls functions like SetupDiInstallClass.

>If I use the standard device class “USB”, which exe/dll needs to be
>called for install and un-install and update of the driver file.

I don’t understand what you mean here. The setup subsystem
automatically locates the required installer and coinstaller files.
There’s no need for you to specify them.

Additionally, the setup class USB is supposedly only for hubs and
controllers. Many companies mistakenly put their widgets into this
class, and WHQL seems to let this go by. Maybe because of the
bureaucratic hassle of getting a variance for a custom class.

–
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

You are currently subscribed to ntdev as: xxxxx@thesycon.de To
unsubscribe send a blank email to xxxxx@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

7

Uma Devi
xxxxx@hotmail.com

> If I use the standard device class “USB”, which exe/dll needs to be
called
> for install and un-install and update of the driver file.

I don’t understand what you mean here. The setup subsystem automatically
locates the required installer and coinstaller files. There’s no need
for you to specify them.

Additionally, the setup class USB is supposedly only for hubs and
controllers. Many companies mistakenly put their widgets into this
class, and WHQL seems to let this go by. Maybe because of the
bureaucratic hassle of getting a variance for a custom class.

I just want to know what needs to be done for installing/uninstalling the
INF file and the driver that uses a system setup class “USB”.
How does the system know where to find the INF file. Do I still have to call
SetupCopyOEMInf() for installing the INF file?
How do I uninstall the driver and INF file when the software is uninstalled
by the user? Which api needs to be called?

Thanks.

The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail

8

I agree. This will lead to some confusion.
In another mail the support people told us that with this policy they
want to avoid the opposite scenario: the user will end up with a
separate class (item in Device Manager) for each particular device he
installed.

I do not understand why MS/WHQL is not willing to certify devices which
use private device classes. Any guesses?

Udo Eberhardt
Thesycon GmbH

Roddy, Mark wrote:

This is not the best thought out whql policy. The consequences are going to
be the proliferation of devices in 'catch all' classes such as System or
Usb. I predict a reversal down the road a bit to cleanup the mess they've
created.

-----Original Message-----
From: Udo Eberhardt [mailto:xxxxx@thesycon.de]
Sent: Wednesday, May 28, 2003 4:55 AM
To: NT Developers Interest List
Subject: [ntdev] Re: chkinf errors for new class guid

We encountered the same problem during WHQL certification of a USB
device/driver. Chkinf complained about our private device class. We got
advice from WHQL support to use the USB class. Quotation from the email: "We
have already changed the statement in the DDK regarding USB Class usage, as
you may know there are many other USB devices that are using Class=USB. Such
as USB Composite device, USB Mass Storage device and etc.. So Class=USB is
not limited to the Host Controller or Hub anymore."

However, certification of the device is still in progress. So I cannot
tell if WHQL will really accept this.

Udo Eberhardt
Thesycon GmbH

Walter Oney wrote:

>xxxxx@hotmail.com wrote:
>
>
>>I am new to this WHQL stuff? What do you mean by "variance"?
>
>
>That's actually slang for getting approval from a local government for
>an exception to the zoning laws or building codes. Anyway, you need to
>contact WHQL and explain to them why you need a custom setup class.
>
>
>
>>Can I call the api SetupDiInstallClass in the installer inorder for
>>the system to recognise the new device class.
>
>
>WHQL won't want you to have your own installation program that does
>this. The approved way to proceed is to (a) copy all your files onto a
>local drive, (b) call SetupCopyOEMInf. You're then supposed to let the
>system detect your device, whereupon it will automatically and
>silently install your signed driver package.
>
>In other words, you shouldn't need a custom installation program that
>calls functions like SetupDiInstallClass.
>
>
>
>>If I use the standard device class "USB", which exe/dll needs to be
>>called for install and un-install and update of the driver file.
>
>
>I don't understand what you mean here. The setup subsystem
>automatically locates the required installer and coinstaller files.
>There's no need for you to specify them.
>
>Additionally, the setup class USB is supposedly only for hubs and
>controllers. Many companies mistakenly put their widgets into this
>class, and WHQL seems to let this go by. Maybe because of the
>bureaucratic hassle of getting a variance for a custom class.
>
>--
>Walter Oney, Consulting and Training
>Basic and Advanced Driver Programming Seminars
>Check out our schedule at http://www.oneysoft.com
>
>---
>You are currently subscribed to ntdev as: xxxxx@thesycon.de To
>unsubscribe send a blank email to xxxxx@lists.osr.com
>

You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@thesycon.de
To unsubscribe send a blank email to xxxxx@lists.osr.com:8001

--

Udo Eberhardt
Thesycon GmbH, Germany

xxxxx@thesycon.de
www.thesycon.de