Error: "NTLDR missing" after routine Windows Update on XP with SP3

[Tricklozen]

Yesterday I was prompted by Windows Update to install the normal updates, and allowed it to restart, only to be faced with the following message when the system attempts to boot up again:

NTLDR is missing

Press CTRL+ALT+DEL to restart.

This is the second time this has happened, on two different systems. One was a clean OEM install of XP Pro with SP2 integrated, then updated to SP3--and after Windows Update had done its thing some days later, the required system files go missing; booting into the recovery console, from the installation media, confirms that there were no files at the root level of the boot partition, and that a time consuming (about two hours on most systems) chkdsk /R will not be able to recover them.

Prepare for it. Have a boot disk ready that can boot into the OS again.

However, should you experience this problem, you might as well use the recovery console from the installation media (XP SP2) instead, and copy both required files to the boot partition.-- The boot disk or boot CD, or boot-whatever-you-can-boot device is probably the fastest solution, but you still have to do this:

COPY D:\I386\NTLDR C:\

COPY D:\I386\NTDETECT.COM C:\

C is the bootable system partition.

D is the installation media.

Verify that the files are on C after the copy. (The COPY function part of the recovery console is a bug in itself.)

You may probably need to reconstruct BOOT.INI manually, if the BOOTCFG command from the recovery console fails (BOOT.INI is optional here, but it's normally used, and includes parameters passed to the OS loader, and may also point to a local install of the recovery console (cmdcons), or other OS installations).

Instead of uninstalling XP SP3 on the other system, I reinstalled the OS and left SP3 out of it. See also Windows Service Pack Blocker Tool Kit.--That system has been running fine for a month now, whereas the instance with SP3 installed survived only a couple of days. It is unclear what exactly causes this problem, but SP3 may be provoking this behaviour somehow, however, my system has been running SP3 longer than the other system again.

This isn't hard to correct in general, but it's incredibly unnecessary to spend time on such things.

It may be that SP3 reveals a bug in NTFS, or reintroduced it. This KB article is the closest I have come [but not the most accurate] for the possible reasons for this behaviour.

http://support.microsoft.com/kb/320397