is it possible to detect checked build?

NTDEV
1

I’m implementing a virtual (Xen passthrough) USB Host Adapter and HUB, and because this is completely unsupported by Microsoft the checked build ASSERT’s very early on when it finds missing magic numbers in my BusContext structure. The free build has no such problems .

It’s going to come up so rarely that it probably isn’t worth the effort, but is it possible for my DriverEntry to detect that it is running on a checked build of windows and to not load? I guess this is made a bit more difficult in that you could have a checked kernel and/or hal and my drivers would work fine, but you could have a free kernel and hal but a checked usbhub.sys and get an assert…

Thanks

James

2

Hi,

there are several ways to probe if you are running in a debug environment/code but there is NO guarantee that you can be sure that all is debug, since parts can be retail, as you mentioned by yourself. You can probe several binaries for version information on their version information for specific information like File Version and strings like “RTM”, “_rtm”, or version information, build information, file size, file date, file hash, is debugging information/symbols included, etc., but there is NO 100% way to make sure its debug or retail. There is a documented way in the .NET framework class named “SystemInformation” how it detects a environment as Debug or Release. Its the property named “DebugOS”. Its probing for a debug or release version of the USER.EXE. See here for more information:

http://msdn.microsoft.com/en-us/library/system.windows.forms.systeminformation.debugos.aspx

Other ways are having a look at the IMAGE_FILE_HEADER header of a PE and the Characteristics field and probing for bit 0x0200 /IMAGE_FILE_DEBUG_STRIPPED. Having a look into the sections of the PE if there is debug related information

The documented way for non .NET developers is GetSystemMetrics(SM_DEBUG) //SM_DEBUG = 22, its internally pinvoked by SystemInformation::DebugOS as mentioned before.

AFAIK its simply difficult,…

best

K.

3

As checked and free components can be intermixed, I’m not sure the concept
of “is this the checked build” is meaningful. It sounds like you want to
know if usbhub.sys is checked.

Another thought is perhaps it’s invalid to depend on the normal usbhub
driver to use an unusual usb controller. I know the usb 3 controller in my
current system also seems to have a custom usb hub. I could also understand
how a debugging build would want a matched set of debug/debug or free/free
usb controller/usbhub, so there could be extra debugging interfaces under
the checked drivers.

I know I like to run other vendor’s products under the checked build, before
I depend on them. I hate spending hours debugging just to find it’s a bug in
another driver.

I actually wish Microsoft would make it a WHQL system requirement that the
checked build run correctly. The full checked build doesn’t run on many
systems, although also runs perfectly on some. I’ve talked to some vendors
of systems where it doesn’t run, and there seemed to be a lot of finger
pointing about who’s fault the asserts were (like in acpi.sys). The vendors
claim their ACPI info is correct yet Windows asserts and claims it’s wrong.
Since kernel developers are not the primary customer of system vendors, it’s
hard to get them to expend engineering resources on bugs that are reported
only by kernel developers, even if these bugs may impact normal users on
occasion. If you ask me, this degrades the overall ability of the driver
community to deliver high quality drivers.

Jan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Saturday, January 07, 2012 1:02 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] is it possible to detect checked build?

I’m implementing a virtual (Xen passthrough) USB Host Adapter and HUB, and
because this is completely unsupported by Microsoft the checked build
ASSERT’s very early on when it finds missing magic numbers in my BusContext
structure. The free build has no such problems .

It’s going to come up so rarely that it probably isn’t worth the effort, but
is it possible for my DriverEntry to detect that it is running on a checked
build of windows and to not load? I guess this is made a bit more difficult
in that you could have a checked kernel and/or hal and my drivers would work
fine, but you could have a free kernel and hal but a checked usbhub.sys and
get an assert…

Thanks

James

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

4

>

As checked and free components can be intermixed, I’m not sure the
concept of “is this the checked build” is meaningful. It sounds like you want
to know if usbhub.sys is checked.

Yes I think that should suffice. It could be the tip of the iceberg though - I only know about the first crash :slight_smile:

Another thought is perhaps it’s invalid to depend on the normal usbhub
driver to use an unusual usb controller. I know the usb 3 controller in my
current system also seems to have a custom usb hub.

Yes I can see why a USB3 controller would want to do it that way - a USB3 hub is probably quite different to a USB2 hub.

I could also understand
how a debugging build would want a matched set of debug/debug or
free/free usb controller/usbhub, so there could be extra debugging
interfaces under the checked drivers.

Hmmm… yes I hadn’t thought of that.

What I’ve seen from disassembly of usbhub.sys where the ASSERT is being triggered is that it seems to be looking for magic numbers in various places, eg ‘HUBx’ in the hub’s BusContext, 'HUB ’ in the FDO extension, and probably a few others scattered around. Putting a magic number at some offset in the FDO’s extension is going to be somewhat difficult given that my drivers are KMDF, but I didn’t get as far as checking if it was usbhub.sys’s FDO extension or my controller’s FDO extension that was being checked.

I know I like to run other vendor’s products under the checked build, before I
depend on them. I hate spending hours debugging just to find it’s a bug in
another driver.

I actually wish Microsoft would make it a WHQL system requirement that the
checked build run correctly. The full checked build doesn’t run on many
systems, although also runs perfectly on some. I’ve talked to some vendors
of systems where it doesn’t run, and there seemed to be a lot of finger
pointing about who’s fault the asserts were (like in acpi.sys). The vendors
claim their ACPI info is correct yet Windows asserts and claims it’s wrong.
Since kernel developers are not the primary customer of system vendors, it’s
hard to get them to expend engineering resources on bugs that are reported
only by kernel developers, even if these bugs may impact normal users on
occasion. If you ask me, this degrades the overall ability of the driver
community to deliver high quality drivers.

Given the amount of internal checking that the checked build does, I’m inclined to agree.

Thanks for the response.

James

5

OK, let’s see if I read this right: “The checked build reports errors that
the free build does not”

There is a reason it is called a “checked build”, and that is so it can
report errors the free build does not even look for.

It does not mean the code you have is correct, or will execute correctly,
or not cause a BSOD, or cause some subtle malfunction. It means that the
free build is not checking for the kinds of errors that might lead to
these problems. Sort of like saying, “If I keep my eyes open, and walk
straight ahead, I will find a deep reiver gorge which I have to work my
way around. But if I close my eyes, and walk straight ahead, I don’t have
to worry about finding my way around the gorge, because I don’t see it.”

The fact that certain magic numbers are not there indicates that the
structure may not be conforming to the requirements; the free build
assumes that all such structures are conforming (after all, they were
first run under a checked build so they must now be correct, since any
errors found would have been fixed).

On the other hand, if you enjoy juggling bowling balls while standing on
thin ice, feel free to ignore the warnings.
joe

I’m implementing a virtual (Xen passthrough) USB Host Adapter and HUB, and
because this is completely unsupported by Microsoft the checked build
ASSERT’s very early on when it finds missing magic numbers in my
BusContext structure. The free build has no such problems .

It’s going to come up so rarely that it probably isn’t worth the effort,
but is it possible for my DriverEntry to detect that it is running on a
checked build of windows and to not load? I guess this is made a bit more
difficult in that you could have a checked kernel and/or hal and my
drivers would work fine, but you could have a free kernel and hal but a
checked usbhub.sys and get an assert…

Thanks

James

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

6

>

OK, let’s see if I read this right: “The checked build reports errors that the
free build does not”

There is a reason it is called a “checked build”, and that is so it can report
errors the free build does not even look for.

It does not mean the code you have is correct, or will execute correctly, or
not cause a BSOD, or cause some subtle malfunction. It means that the free
build is not checking for the kinds of errors that might lead to
these problems. Sort of like saying, “If I keep my eyes open, and walk
straight ahead, I will find a deep reiver gorge which I have to work my way
around. But if I close my eyes, and walk straight ahead, I don’t have to worry
about finding my way around the gorge, because I don’t see it.”

The fact that certain magic numbers are not there indicates that the structure
may not be conforming to the requirements; the free build assumes that all
such structures are conforming (after all, they were first run under a checked
build so they must now be correct, since any errors found would have been
fixed).

On the other hand, if you enjoy juggling bowling balls while standing on thin
ice, feel free to ignore the warnings.

OTOH, if I make the crashes go away by putting the expected number in the expected place, I haven’t really made my product any more stable have i?

The structures in question are mine for use in my driver. Windows is making some assumptions about structure ownership that are false as it’s my USB Controller, not Microsoft’s.

James