Month: June 2005

If you develop enough drivers, eventually you’ll ship one with a bug. Yeah, I know, seems unlikely, doesn’t it? What, with all of the time everyone spends testing and profiling and code reviewing, bugs are almost non-existent, right? Well, on the off chance that the impossible happens, here’s a tip that I have used in the past.

Most computers will generate a dump of some sort when a crash happens, but what if the driver hangs in the field? You have only a couple of options in that case. One possibility would be to hook up a kernel debugger. That can be problematic, though – users have to find a null modem cable, modify the target to boot with debugging support (or step through an F8 menu that they may not be comfortable with), set up the debugger and turn on remote desktop for the host, and generally put the user through a nontrivial amount of trouble. When this works, it’s great; there are even variations on this theme that make it more convenient. But for many, the requirement for a second computer and a null modem connection kills the deal.

Another way to get a crash dump is to force windows to crash from the keyboard. [No dumb jokes, please. :-)] To get an idea of how this works, grab a DDK and check out the 8042 sample in the input directory. To enable keyboard-triggered crashes, do the following:

• create a DWORD value called “CrashOnCtrlScroll” in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters
• set it to 1
• reboot

Now, if you need a crash dump, hit ctrl+scroll lock twice. This will generate a bugcheck, and will drop a minidump or full dump or whatever you have your system configured for. The bugcheck code will be E2 – MANUALLY_INITIATED_CRASH.

Hope this helps.

I’ve heard about compilers no fewer than three times today, so I decided I’d have to blog about it before the subject would go away. 🙂

First off, there’s a very interesting discussion going on over at NTDEV about structure packing differences between the Visual Studio compiler and the DDK compiler. Let it never be said that compiler choice doesn’t matter when building drivers – this goes for people using the VS compiler, people trying to use the Intel compiler, or even those who have tried building Windows binaries on MinGW.

Second, AprilR has a post on her blog called What’s the deal with all of these C++ compilers, anyway?, that is a really interesting read (if you’re a nerd like me!). Someone at Microsoft once said something to the effect of “Revving a compiler is really difficult” – and this is some explanation for that fact. Interesting read!

Lookie what I found… my WinXP SP2 box has a new service called “Windows User Mode Driver Framework”. I heard all about the great work that the framework teams were doing at DevCon, and am really looking forward to it. Nobody has been willing to give a release date for the user-mode portion of the framework yet, though, so I was surprised when a Ken Johnson, a co-worker, pointed it out to me. I didn’t think they were anywhere near shipping. See for yourself: open services and look for it.

Whatever the case, I’m looking forward to the production version!

Why, you ask, is a title such as this present in a Windows kernel-mode blog?

Our good friends at AnandTech have published an interesting article on G5 vs. Opteron vs. Xeon performance. It has one or two major flaws, such as changing two variables at once and attempting to draw a conclusion nonetheless, but it is a fascinating read anyway. The chip architecture stuff is great, although you can also find similarly technical articles at Ars Technica (which I read daily). The really good stuff starts when they do what amounts to an OS comparison between Darwin (the UNIX under MacOSX) and Linux. They point out a really serious performance problem with multi-threaded application performance, and another one with kernel locking.

Locking is really hard. The best seasoned programmers don’t always do it right, and the collective wisdom keeps changing and improving as time goes on. NT’s internal locking architecture has evolved steadily over the years, just like Linux’s has, and (to a lesser degree) MacOSX’s. The first iterations of windows had several very hot locks that were practically mandatory in some significant kernel paths, such as I/O (the cancel lock) and dispatching (the dispatcher lock). The current performance of Windows is the result of a systematic effort to profile and improve. Beyond a certain point, it doesn’t pay to guess where redesign and recoding will yield improved performance – Raymond Chen has written often about it, and has a recent series on optimization that’s worth a read.

The take-home is to profile your code. There are lots of tools available, some expensive and some free, to help you out here. You can even instrument your own code, though that has its own performance-related consequences. Regardless, if you write any nontrivial production code, you owe it to yourself to profile.