Windows XP Embedded Gotchas

Thanks to virtually no help whatsoever from neither the Microsoft Developer Network (MSDN) nor Microsoft's microsoft.public.windowsxp.embedded newsgroup, I have finally tamed Windows XP Embedded (XPE) with Service Pack 2 (SP2).

Some potential gotchas and how to deal with them ...

- Throw the Embedded Studio Help out the (pun)Windows(pun)

Seriously. Do not follow the step-by-step help in building your first XP Embedded target in Microsoft Windows Embedded Studio from its included help files. They are full of incorrect approaches and steps -- things that will causes you days of grief. We will cover several.

Unfortunately, the MSDN pages mirror much of the Embedded Studio help files. The more 3rd party/independent pages you can find for help, the better. The newsgroup is limitedly helpful, but I have to admit I haven't been around it long enough. Although I did note several people openly complaining why Microsoft can't get its act together in comparison to Linux when it comes to embedded.

- TAP a "pure" XPProSP2 installation

Do not run the 16-bit version of Target Analyzer (TA.EXE) under DOS. Do not run the 32-bit version of Target Analyzer (TAP.EXE) under a Windows PE (or BartPE) boot. Do not run TAP on a XP Home or Pro installation that has been updated with drivers or other patches. Ignore just about every clueless MSDN or other site suggestion I've seen (which is many, many, many).

Install Windows XP Professional with Service Pack 2 (XPProSP2) on the system, and do not update any drivers. Leave them as-is. That is the absolute best way to generate the most "pure" Devices.PMQ file for use in the next recommendation. I have had nothing but issues with TAP when run under a Windows PE environment (let alone TA in a DOS one).

Yes, still do this even if you have 3, 4, 5+ "Unknown Devices" under Device Manager in XPProSP2, or if you normally update drivers. As long as the XPProSP2 installation can boot on its own (meaning the storage driver and other core components work), this is the "pure" Devices.PMQ file you want.

Do not worry about having all or the latest drivers installed in XPProSP2 for Target Analyzer. The PCI vendor/ID information will result in updated drivers in the Component Database being used when you build a target. In fact, I've found that sometimes updating the driver in XPProSP2 (e.g., the ViA Ultra ATA Bus Master driver) and then seemingly importing its "equivalent" SLD component into the Component Database (e.g., from ViAEmbedded.COM) does not work as it should. It's far better to stick with the "older" driver under XPProSP2 when TAP runs, than what you have updated in your Component Database.

Regarding missing drivers and, therefore, devices missed by TAP that don't make it into your Device.PMQ and, subsequent, SLD file, just manually add them to your target. The First Boot Agent (FBA) will automatically configure any missing devices as long as their components were included in the target. So just because they weren't setup under XPProSP2 when TAP was run doesn't mean they won't be available in XPE -- because that's the job of the FBA, to find all hardware and setup such devices.

To summarize, the focus of the Device.PMQ is to get a full set of "pure" components that will let XPE boot. Running the 32-bit version of Target Analyzer (TAP) under a "pure" (no added drivers/software) Windows XP Professional with Service Pack 2 (XPPProSP2) is the best recommendation I can make given 50+ hours of trial'n error with 3 different SBC/Mini-ITX systems.

- Build a SLD for the "pure" Devices.PMQ

One of the stupidest things that the Embedded Studio help has you do is import your Devices.PMQ file (from your TAP run) directly into Target Designer. Never, ever do this! You will almost always get an incomplete, unbootable XPE image build. Always work with Source Level Definition (SLD) aka "component" files.

That means you want to launch Component Designer and import your Devices.PMQ under it as a new .SLD "component" file. Of course this means you have to then import it into your Component Database via Component Database Manager, but that's a small, extra step.

I'm not expert on XPE yet, but I think I know why importing a Device.PMQ directly into Target Designer fails to build a bootable image. I got STOP 0x0000007B error after STOP0x0000007B error within seconds of first boot (well before First Boot Agent, FBA, could run). I think it's because Target Designer makes too many assumptions on what dependencies are already resolved from the Device.PMQ. Whereas if I add a .SLD "component", it seems to add/suggest all the necessary components during the dependency check.

Besides, making a .SLD "component" file for your board from the TAP run (and it's Device.PMQ) is much "cleaner" anyway.

- "Fixed Disk" CompactFlash boot requirement

This is one of the most grossly overlooked aspects of XP Embedded, and virtually ignored in Microsoft's own documentation. Unlike DOS (including Windows 9x) and Linux, the NT loader (NTLDR) has some very picky requirements on CompactFlash boot.

First off, the more well-known fact is the reality that the CompactFlash must be connected to an ATA channel. I knew this from the get-go, and made sure I had SBC/Mini-ITX systems with either ATA-to-CompactFlash logic on-PCB, or an external ATA-to-CompactFlash adapter.

Secondly, and far less well understood, is the fact that the CompactFlash must appear as a "fixed disk" with a "partition" and not as a "removable" device. I use the terms "partition" and "removable" explicitly as they would appear under NT5 (2000/XP)'s DiskPart utility. Boot Windows XP, Windows PE or BartPE and run DiskPart to see the format type.

There is a lot of commentary out there that an ATA-to-CompactFlash adapter removes this requirement. This is completely false. It's not geometry, ATA format or other issue -- it's the way the CompactFlash device itself presents. Now for DOS or Linux, it has no issue. But for Windows XP, the NTLDR absolute does not want to boot from anything that identifies itself as a "removable" device.

The reasons for this stem from countless, legacy NT design flaws and other ways to prevent (or at least inhibit) copying of a NT system that still plagues NT5+ (2000/XP). I won't go into the extensive technical reasons. But even if you use an alternative master boot record (MBR) and even some disk translating bootstrap, there appears to be no way around the issue.

In a nutshell, the "fixed disk" format is incompatible with "normal consumer usage," so you cannot find them anywhere but from a few CompactFlash vendors as a specialized OEM/Industrial part. And even then, it's typically an added P/N for the "fixed" configuration. E.g., SimpleTech's part numbers are typically of the form SLCFxxxJ-F (the "-F" suffix meaning "fixed" configuration).

The good news is that these devices typically come from the factory with the bootstrap already setup with the bootstrap for NTLR. So it's just a matter of copying over the file tree. No need to run BOOTPREP or any other utility. I mean, and side note/rant here, isn't it ironic that you have to use a set of 16-bit DOS utilities like BOOTPREP, which is always an issue in supporting a 32-bit OS like NT which may differ in geometry, hardware access, etc...?