Zoyd W.

I've been fighting an insidious bug in Windows XP installation recently, so I want to share my conclusions here. I've been trying to install from a genuine Windows XP CD-ROM (not scratched at all), but this problem is also present in some ISO images being shared on the net.

As noted by lots of people in http://www.richardsramblings.com/?p=49&cp=all there's a fairly common problem in Microsoft Windows XP install CD's. It seems clear that a flaky CD preparation and/or pressing process by Microsoft is to blame, possibly also involving a deliberate attempt at a copy protection measure by Microsoft. The problem affects both pirate and legitimate users, and it's also present in international versions of Windows XP. It affects both native and virtual machine installs (and both with Qemu and VMware).

This issue seems to be very old; the discussions in the aforementioned site date from 2002 and 2003. As virtualization technologies expand their user base, I guess this problem will be frequent again (in fact that's how I stumbled into it). And as installation CD's are older now, they're bound to be less readable, thereby aggravating this issue even more.

The problem appears right after the start of the installation's phase 2. On phase 1 it finishes copying files from the CD to the hard disk, and then reboots to start phase 2. Then an error message appears saying some variation of:

Fatal Error

An error has been encountered that prevents setup from continuing.

One of the components that windows needs to continue setup could not be installed.

A component’s file does not match the verification information present in the component manifest.

***
Error:

SXS.DLL: Syntax error in manifest or policy file “E:\I386\asms\6000\MSFT\VCRTL\VCRTL.MAN” Line 11.

***
Error:

Installation Failed E:\I386\asms. Error Message: A component’s file does not match the verification information present in the component manifest.

***
Fatal Error:

One of the components that windows needs to continue setup could not be installed.

A component’s file does not match the verification information present in the component manifest. 

The filename mentioned in the error message may vary somewhat. Its extension, .man, is that of a "manifest" file (a file that describes other files to install). In some cases (not in this precise same error message I quoted) it may prompt for a directory where it could find the manifest file, so that it can be solved by handing it some more or less legit manifest file in a diskette. But most of the times it's a fatal error that elicits an automatic reboot.

This much seems certain: this problem shows up when the Windows installation process is unable to verify the integrity of some of the files being installed. In a few cases this happens due to faulty RAM, but most often it's caused by the CD-ROM drive (and driver) not being able to read faithfully what's stored in the CD. Almost always there's some problem with the CD itself, but sometimes it helps to use a different CD-ROM drive, or maybe a CD or DVD burner.

What's been most surprising to me is that extracting an ISO image from the Windows CD is no guarantee for good data. In particular, I tried extracting the ISO image using dd on a Linux kernel 2.6.20, and I ended up having a flawed ISO image but it didn't issue any error messages. Nero 6 on Windows also failed silently. Only IsoBuster got it right.

The manifest file may or may not be readable; even if it is readable it sometimes may contain garbage (and the fact that this does not produce a checksum error raises the suspicion that some copy protection could be involved). Or the manifest file could be fine, but some of the files referenced by it could be corrupted.

What's even more alarming is the fact that not all of the installed files' integrity is being verified. In fact, it seems ONLY NON-CRITICAL FILES seem to be checked, and if the installation process is somehow tricked into not installing them there seem to be no harm. But some important file may well end up installed in their corrupted state. This would imply that in some cases Windows installs corrupted files without the user being alerted at all.

Several solutions to this problem have been proposed; some work in some cases and some in others. The only solution acknowledged by Microsoft is to get a new CD from them. But a few workarounds have been tried successfully by the users. Among them:

Create a new ISO image from the installation CD, eliminating the asms directory; when the installer asks for it point it to a diskette with a doctored manifest file and an empty directory structure identical to that of asms. The installation process usually finishes OK, but some corrupted files may be installed, and the missing files might be important (though it seems they usually aren't).
Create a new ISO image from the installation CD, edit it with a disk editor altering the sectors used by the offending manifest file. In particular, replace the hash="..." and hashalg="SHA1" with spaces (hex code 20) so that the files will be installed but not verified. This method certainly installs corrupted files, but seems to work nonetheless.
If a copy CD or an ISO image were used, re-record them using an original CD and doing it at the lowest speed possible, hoping that the problem disappears.
If the CD was genuine or known good, use a different CD-ROM drive that hopefully will read the CD without corruption

As noted above, I've come to the conclusion that there is no better workaround than rerecording the installation CD (or regenerating the ISO image) from one that is error-free.

In case there are any skeptics out there, let me state that I've systematically tried almost all of these installation scenarios and workarounds, both in native and in virtualized environments. Skeptics are welcome to double-check my findings and conclusions, but I'm fairly certain about what's going on here. I hope this post saves time for somebody, because this issue has taken up a lot from mine.