Hello everyone,
I've been messing around trying to see if I can boot Windows XP in full mode (not setup-mode or /MININT mode) entirely over the network. I've done it a million times with Windows XP PE (via BartPE). It's such an interesting process, the XP boot process...
- The computer PXE-boots
- A DHCP address is obtained from my Cygwin DHCPD
- My DHCP server recommends STARTROM.N12 as a boot file
- The computer downloads STARTROM.N12 from my Cygwin TFTPD
- STARTROM.N12 runs and downloads NTLDR via TFTP
- This is where we branch in different directions for BartPE and full XP, based on NTLDR. I am only discussing full XP in this post
- The Windows XP Embedded NTLDR runs and downloads BOOT.INI via TFTP and gives the boot menu:
CODE
[boot loader]
timeout=30
default=ramdisk(0)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional from Hard Disk" /fastdetect /sos /bootlog
ramdisk(0)\WINDOWS="ramdisk(0)\windows from net(0) HALAACPI" /fastdetect /rdpath=net(0)\foo.sdi /rdimageoffset=36352 /sos /bootlog /hal=halaacpi.dll
ramdisk(0)\windows="ramdisk(0)\windows from net(0) HALACPI" /fastdetect /rdpath=net(0)\foo.sdi /rdimageoffset=36352 /sos /bootlog /hal=halacpi.dll
net(0)\windows="net(0)\windows" /fastdetect /sos /bootlog
- If we choose one of the ramdisk boots, NTLDR downloads FOO.SDI as a ramdisk, then starts loading the OS from it
- If we choose the net(0)\windows option:
- NTLDR starts loading the OS via TFTP!
--- START OF GUESSWORK --- - When it's time to make the switch away from BIOS routines, the Kernel checks the ARC path which we were loaded from
(You can use Sysinternals' [now Microsoft's] WinObj to see that ARC paths are shortcuts to filesystems) - The Kernel doesn't see a net(0) shortcut pointing to any filesystem
--- END OF GUESSWORK --- - The Kernel displays a Blue Screen of Death with STOP 7B
Although it's guesswork, I think I might have learned something about the boot process that I never knew before... I always thought UNMOUNTABLE_BOOT_VOLUME had to do with not having a device (under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E967-E325-11CE-BFC1-08002BE10318}) with a MatchingDeviceID of "gendisk" and not having a device (under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\IDE, for example) with a ComptabileIDs including "GenDisk". Now I don't think so. Now I think
this is what happens:
- As .SYS files are being loaded (as seen with /SOS), each one has an initialization routine which is called
- Microsoft's RAMDISK.SYS recognizes an available ramdisk loaded by NTLDR and associates that memory with a volume (like \Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2f6b750})
- RAMDISK.SYS then creates a shortcut from ramdisk(0) to the volume, as can bee seen with WinObj
- When the Kernel decides to switch from using BIOS routines, it checks the ARC path
- The Kernel sees the shortcut from the ARC path of "ramdisk(0)" to "\Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2f6b750}", so it uses the NTFS filesystem all the way through the MS Ramdisk Controller to access the volume
I could be wrong; it could be NTLDR who makes the ramdisk(0) ARC shortcut. Whatever.
If this is all true, and all you need is an ARC shortcut to your boot volume, perhaps someone could write a small .SYS file who will be loaded at boot time and make the "net(0)" shortcut point to "\Device\LanmanRedirector\Registry_stored_fileserver\Registry_stored_fileshare". Then maybe at the big switch, we wouldn't get a blue screen!
The point of all of this is to run full XP over the network, without using a ramdisk. Let me know what you think.