Device class interface documentation?

NTDEV
1

Hello.

Under HKLM\SYSTEM\CurrentControlSet\Control\DeviceClasses in the registry, there is a long list of device class GUID’s and device PnP ID’s and associated symbolic names of devices in the classes in subkeys thereunder. Upwards of four dozen of them.

Only a very few of the GUID’s appear in winioctl.h and, as far as I’ve been able to determine so far, there is a dearth of documentation for/on them.

What are these things? Microsoft proprietary? Vendor proprietary? What?

In particular, I’m interested in obtaining documentation for the video adapter device class interface, {5b45201d-f2f2-4f3b-85bb-30ff1f953599}, and finding out if there is any diagnostics capability included therein.

Is documentation for same, or any of this, available anywhere, under NDA or otherwise?

Anyone know?

MikeC

2

xxxxx@mcolandreo.fastmail.fm wrote:

Hello.

Under HKLM\SYSTEM\CurrentControlSet\Control\DeviceClasses in the registry, there is a long list of device class GUID’s and device PnP ID’s and associated symbolic names of devices in the classes in subkeys thereunder. Upwards of four dozen of them.

Only a very few of the GUID’s appear in winioctl.h and, as far as I’ve been able to determine so far, there is a dearth of documentation for/on them.

What are these things? Microsoft proprietary? Vendor proprietary? What?

They are uninteresting, for the most part. Those GUIDs are just a way
for applications to find drivers in an unambiguous, using the SetupDi
APIs. It’s just a lookup table. It’s not like COM, where the GUID
points to a C++ class. Having a device class does not necessarily imply
that there is some publicly available interface for talking to the
driver. A few classes have one, but certainly not all

In particular, I’m interested in obtaining documentation for the video adapter device class interface, {5b45201d-f2f2-4f3b-85bb-30ff1f953599}, and finding out if there is any diagnostics capability included therein.

The only public interface to your display driver is through GDI. What
were you hoping to find?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

Some way to run at least some minimal diagnostic test(s) on the video adapter (not the/a display or display surface) from inside the OS.

4

xxxxx@mcolandreo.fastmail.fm wrote:

Some way to run at least some minimal diagnostic test(s) on the video adapter (not the/a display or display surface) from inside the OS.

Probably should have quoted a bit more of the message; I wasn’t entirely
sure what you were talking about here.

There are no such diagnostics. Basically, Windows always assumes that
hardware functions perfectly. In a few cases, you may be able to
download a DOS-based diagnostic from the manufacturer.

What would you hope to learn?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

5

“What would you hope to learn?”

Hmmm. Interesting question.

I would learn nothing. These days, I’m a diagnostics software developer. I invent tools that others use. To use to determine whether or not a hardware device is fully functional. If not, to use to troubleshoot what’s amiss. Etc.

Or, simply to use to confirm that the hardware device is actully “there” and is in fact the “part number” that’s supposed to be there.

And, in this case, I’m ferreting out means of directly accessing a video adapter from inside the OS.

Because, as you say: “Basically, Windows always assumes that hardware functions perfectly”. And it’s my job to invent tools that can be used from inside the OS to determine whether or not that is in fact true, among other things.

MikeC

6

xxxxx@mcolandreo.fastmail.fm wrote:

“What would you hope to learn?”

Hmmm. Interesting question.

I would learn nothing. These days, I’m a diagnostics software developer. I invent tools that others use. To use to determine whether or not a hardware device is fully functional. If not, to use to troubleshoot what’s amiss. Etc.

Or, simply to use to confirm that the hardware device is actully “there” and is in fact the “part number” that’s supposed to be there.

The OEMs (e.g., Dell, Gateway) require that their hardware vendors
provide DOS-based manufacturing tests, to validate that the device is
what it says it is, and that the basic functionality is healthy.
Unfortunately, they don’t release those tests.

And, in this case, I’m ferreting out means of directly accessing a video adapter from inside the OS.

Windows will not allow you to “directly access a video adapter”. There
are any number of GDI-based diagnostics; the old DCT (display
compatibility tests) suite that was used to qualify display drivers for
WHQL would run a number of tests, and then compare the results to a
known bitmap.

For anything more detailed than that, there is simply no
infrastructure. There is no way to talk to the device, and even if you
could, there are no standards in place for what such access would look
like. Every graphics chip is different.

Because, as you say: “Basically, Windows always assumes that hardware functions perfectly”. And it’s my job to invent tools that can be used from inside the OS to determine whether or not that is in fact true, among other things.

The problem is likely to be unsolvable in the general case. An IDE
device has to respond to a well-defined set of low-level IDE commands in
a well-defined manner, and you can test that. A USB host controller
similarly has to respond to a well-defined set of low-level commands in
a well-defined manner. For a graphics chip, there is no such set of
well-defined commands. Although a single vendor might establish a set
of register meanings for the chips in their product line, chips from
different vendors vary wildly.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.