There’s a new version of DTM available. It was released at the end of last week. Craig has the details..
This marks a change in the way Microsoft is distributing the logo tools. Whereas they were built into the Vista WDK for RTM, going forward, they will be released separately as the Windows Logo Kit (WLK). They’re going to try to do annual updates to the kit each June or so, with beta availability of the kit six months earlier.
Hopefully this stops someone out there from duplicating my recent mistake. DTM warns of needing 300GB to install (although that’s not true), and I didn’t have anything like that much space on the drive I had installed the OS onto. So, I chose to install on E: instead, which had more (but not quite 300GB!) space. All seemed to go well.
Then, I tried to install a couple of QFE’s (which, if you run DTM, you should check for regularly). The QFE installer told me my version wasn’t compatible with the patch, and it quit. It turns out that the problem was simply that it was looking for the DTM version number in a file on the C: drive, which is what %ProgramFiles% evaluates to on my computer, rather than on the E: drive where the file actually was. A complete re-install onto C: fixed the problem.
Someone on the DTM newsgroup tried to repro this and couldn’t, so this obviously isn’t universally broken, but I don’t think I’ll mess with alternate-drive installations any more – I don’t want to risk the 1hr re-install time. Again.
The installation instructions for DTM state that the controller needs 300GB of disk in which to install. This has obviously caused consternation, as now not only do you need a Windows Server 2003 OS, but you need what is still a lot of hard drive space. New computers are OK, but if you hope to e.g. use a VM server, you might be in trouble.
The good news is that all evidence seems to contradict the installation notes. I just did another (!) fresh install of DTM on a freshly installed Windows Server 2003 Standard box, in workgroup mode, with all patches and service packs and a fresh installation of DTM, in under 8 gigs. Obviously this will change as clients and tests are added, but with that as a baseline, it’s hard to imagine where 292GB of test data are going to come from.
Others have posted on NTDEV and in the DTM newsgroup that it’s not taking nearly 300GB for them either. Anyone have any experiences to corroborate or refute this?
I’ve been working much with DTM lately, and two interesting things have risen above the ambient difficulty level that seems to be associated with every DTM installation.
The first is this dialog box I received on adding a Vista client:
Setup has detected that Internet Connection Firewall is enabled on a network connection. Test Client will not be able to communicate with the sserver unless a port is opened up through the firewall. In order for you to continue with the installation of this package you must select the Yes below
Warning: A pop-up dialog may occur during setup while this port is opened, setup will take care of dismissing it.
Not-quite-English aside, this dialog seems to indicate that the installer will click the allow anyway
button. I didn’t realize Microsoft shipped button-whackers, particularly to driver developers who they are hoping will not write their own button-whackers.
Interesting.
One of the nicer little changes to Vista is the re-engineering of Windows File Protection into Windows Resource Protection (WRP). As everyone who’s ever tried to construct a partial checked build knows, replacing a file like ndis.sys in older OSes was a pain – you had to edit the registry and boot with the debugger to keep windows from silently clobbering your replaced file.
Windows Vista takes a much more intelligent approach to the problem: it prevents users from deleting these files in the first place, using the built-in security mechanisms of the OS. Protected resources get an ACL that prevents writes/deletes/etc, and the files are owned by a special user.
Now, if you want to replace a file for testing purposes, life is a lot easier – just take ownership of the file, give yourself full control, and re-name the old file. Drop in the new file and you’re done – no need to worry about the watchdog thread any more.
WRP also protects registry keys now using the same mechanism. More info is available at http://msdn2.microsoft.com/en-us/library/aa382503.aspx
Jennifer Stepler spent some time whiteboarding at the MVP summit about signing. She was explaining that there are two different kinds of signing in the Windows world: Device Installer signing and Code Security Signing. Here are her notes:
In search-engine-findable text:
Example of trusted cert path: MS root -> Verisign -> ATI
Kernel Mode Security Signing
These notes resulted from about an hour of discussion, so they’re missing a lot of detail.
A common misconception in the driver-signing world is that boot-start drivers must have a signature embedded in the driver binary itself. This is not strictly true, although it’s still the right thing to do.
To re-cap, x64 systems check every kernel-mode binary on load for a digital signature. The signature can be an Authenticode signature or a Microsoft-supplied signature, as I discussed in my last post.
There are actually two ways that the OS can tell if a driver is signed:
The boot loader can, in fact, handle either type of signature, but for important performance reasons, signing the binary itself is the recommended practice. Peter Brundrett from Microsoft was kind enough to provide this explanation:
The loader does have code to find .cat files for boot start drivers. However, the loader depends on a simple I/O subsystem that is not very high performance. If a boot start driver is catalog signed, the loader has to locate (seek and read) through potentially hundreds of small catalog files to find the catalog that signed the particular boot start driver. There is mechanism in code integrity in the loader to be smarter about how it locates the catalog that did sign the boot start driver on the next boot. But using embedded signatures is much better, and over time as more update catalogs are installed, makes for more consistently faster boot times that do not have catalog dependencies.
So, again, the best practice is simply to sign every binary you produce. It’s easy to integrate into the build system and will keep you from having to ever think about this stuff again.
We had some extended discussion at the MVP summit on the topic of driver signing. Jennifer Stepler from the WDK team spent a couple of hours talking through the various kinds of signing and clearing up the confusion.
To recap, there are two kinds of signing used in the [Windows] world today: code signing and device installation signing. Code signing means embedding a digital signature in your compiled binary, such as a .sys file. These signatures are checked by the loader and (on x64) your driver will not load if it’s not signed in this way. Notice that this happens at load time, which is every time PnP decides to fire up your driver (i.e. every boot, plus immediately after install time).
The other type of signing is device installation signing. The device manager checks for signatures in .cat files that go with your driver package. To sign a .cat file, you first have to generate one, and then sign it with signtool. This signature allows the device to be installed without the big nasty unsigned driver
warning. There are two kinds of signatures that you can put on a driver package: you can get your driver signed by WHQL, or you can sign your driver package with your own code signing certificate, similar to other code (called an Authenticode
signature). If you use an Authenticode signature, the user will get a friendly “Do you want to install software from XYZ Corp?” prompt, with an option to always trust this publisher from now on. If you use a WHQL signature, the installation is totally silent.
It is Microsoft’s recommendation to use both kinds of signatures on all drivers, x86 or x64.
One of the first topics that came up at the MVP summit with the kit team was which DDK/WDK to use for which target OSes. The answer is simple: always use the latest released dev kit. You can build drivers for any supported OS with the latest WDK.
This is at variance with advice seen in various places (NTDEV, the release notes themselves (!), USENET), and there are people who even advocate adding the kit to source control so that it can be re-built at any time in the future in an identical configuration. Obviously, this has to work, since it was once the only way to do things. There are other concerns and problems with this approach, and we discussed several of them with the team.
But, for all that, the use of downlevel kits is now officially deprecated by Microsoft, so at this point, I think it makes sense to bite the bullet and upgrade kits for released drivers. There are good reasons to use newer kits as well, and regardless, I expect PSS will soon insist on troubleshooting against current kits.
I had an awesome time at the MVP summit in Seattle and Redmond this week. The executive briefings were about what you’d expect – roadmaps, technology overviews, etc. The Gates keynote was good, particularly once he got to the 45-minute question-and-answer part.
But, once again, the highlight of the week was the time spent with the product teams. Big thanks to Johan Marien from the WDK team for organizing a great day and a half of presentations and discussions with the various teams. We got to spend time with the WDF teams, the WDK team, and lots of others with whom I was less familiar.
I learned a lot and got a lot of clarification on topics I thought I understood (i.e. signing, DTM, etc.). I’ll see if I can write up a few posts on some of the high points.
Anyway, thanks again to everyone at Microsoft for putting together such a great event!