Sorry, wrong answer, chum. XP SP2 is more like a dot release for XP than an ordinary service pack. The good news is that if you write quality drivers, and test them thoroughly with Driver Verifier, you probably won’t have any problems with XP SP2. On the other hand, if you like living on the edge and bypassing the operating system whenever you feel like it, you might have some work ahead of you.

Let’s look at the two changes in XP SP2 that are most significant to driver writers.

If you’ve read the memo from Hector on OSR Online^® you already know about this new feature. Starting with XP SP2, ExFreePoolWithTag (you are using the "WithTag" variants of the pool allocation functions, right?) was enhanced to check the integrity of the header used by the pool block following the one being returned. If the header is corrupted, the system will immediately blue screen. I think we can all agree that catching pool corruption is a good thing.

What you might not realize is that during beta testing, a number of drivers were discovered that blue screened because of this new pool corruption check. The only problem was that they blue screened while running at customer sites. Personally, I’d say this is good for the driver community, and pretty bad for the dev who wrote and shipped those drivers without testing them first.

If you regularly run your drivers with Driver Verifier enabled, including special pool, you’re doing your due diligence. Your drivers are almost certainly safe. But do take a few minutes to try out your driver code under XP SP2 just to be sure.

As for those devs who don’t test their drivers with Verifier before they ship them, well…. You boneheads don’t read this publication anyhow. I mean, why would you take the time to read a free publication that might help you increase the quality of your drivers if you don’t use the free tools that are to help avoid turning your customers into QA testers?

I bet you’re curious about how setting "no execute" protection on data pages could possibly make a difference to driver writers. While I guess it’s possible that you have a driver that generates code at run time and then executes it, but I’m thinkin’ that this isn’t likely to be an issue.

No friends, the real problem for certain drivers is what has to be done to enable no execute protection. NX is only available on processors that support it and then only when the system is run in Physical Address Extension (PAE) mode.

Presently, the only processors that support NX are the AMD Athlon64 and Opteron. And, yes, we’re talking about running these processors in their 32-bit mode (in case you haven’t noticed, these processors are among the most popular CPUs on the market these days - even without a shipping version of Windows 64).

PAE mode expands the addressing capability of the processor from 32-bits of physical memory to 36-bits. It does this by increasing the size of the page table and page directory entries to 64 bits, and creating a third-level page table. PAE mode was previously only supported on Windows Server products, and only enabled on 32-bit Windows systems that had more than 4GB of physical memory installed.

What this means is that starting with XP SP2, there will be 32-bit Windows XP systems with less than 4GB of physical memory that will be run in PAE mode so that NX can be used. This creates problems for drivers that:

I don’t even want to think about why some drivers may try to understand the layout of the system page tables. But apparently, there are drivers that do. It makes me feel dirty. But, if you do it… now at least you’ve been warned.

There may be drivers that check to see if PAE mode is enabled and then refuse to load. This is usually because the driver has been written with certain inherent restrictions, such as no support for DMA to addresses longer than 32 bits. These drivers will have to be modified to take into account the fact that PAE mode can be enabled on systems with less than 4GB of physical memory. Note that we’re talking only about driver restrictions here. Whether or not your device is 64-bit DMA capable is an entirely different story (the HAL has always handled that for a well written driver).

The good news here is that if your driver doesn’t play with the page tables, or explicitly check for PAE mode so that it can change its behavior, you’re likely to have no problems with XP SP2. You might also be pleased to know that enabling PAE mode in Windows XP does not cause the intermediate buffering of 32-bit DMA transfers that would be previously unbuffered, or further limit the number of map registers that are available to

your driver. You can thank the guys who write the HAL for these changes. Oh, one more thing: Even when PAE mode is enabled, Windows XP systems are still limited to less than 4GB of physical memory.

To sum up, if your driver is well written and well tested, you probably don’t have anything to worry about. I don’t know how many times we have to say this: If you follow the rules, write a well-engineer driver, don’t try cute tricks to bypass the operating system, and test your driver thoroughly using Driver Verifier, your driver problems will be minimized. No matter, if I were you, I’d probably get a couple AMD systems, install XP with SP2, and make sure my driver works the way it should. Here at OSR, we’ve already done that - We know we’re in the clear.