Install XP from USB without extra tools

[Legorol]

This is a report of the culmination of my successful adventure. I have been researching the topic of installing XP from USB, and after learning a lot from this and other forums, I set myself a challenge. Based on all the available knowledge, is it possible to install XP from USB using no third party tools, except what's available to me in a standard Windows 7 installation? I realise that there are now lots of good tools available online for a variety of installation scenarios, but there is something satisfying about managing to do this "out of the box".

The scenario. Available to me were:

* Legitimate Windows XP with SP1 setup CD.

* Target computer: has 1 blank Harddisk and can boot from USB. Aim to install XP here. No CD drive.

* "Work" computer: standard Windows 7 installation, used for preparation.

* Blank 1 Gb USB stick.

The restriction was that I could only use whatever tools are included in Windows 7 on the Work machine. No third party applications. In addition, I aimed to make the fewest possible tweaks along the way.

The steps that worked successfully to install XP from USB, exactly as written, from the first to last step. Some additional remarks are at the end.

Steps 1 - 5 are performed on the Work computer.

Steps 6 - 10 are performed on the Target computer.

Step 1) Partition and format the USB stick in Windows 7, which makes it bootable:

Start Command Prompt, start diskpart.

Enter commands: select disk 2, clean, create partition primary, active

Exit diskpart, unplug and replug the stick.

Format the stick via Windows Explorer (I chose FAT32).

Note: the value in "select disk 2" depends on the number of harddisks and other USB storage devices you have! You have to check what value is appropriate for your system (use "list disk"). I have two Harddisks and disconnected all other USB storage devices, hence the value is 2 for me (numbered from 0).

Step 2) Copy contents of Windows XP with SP1 setup CD in whole to the USB stick.

Step 3) Copy these files from \I386 folder to \ on USB stick:

setupldr.bin -> bootmgr (rename), ntdetect.com, txtsetup.sif

Step 4) Edit \txtsetup.sif to add two lines in [setupData] section:

BootPath = "\I386\"

SetupSourceDevice = "\Device\Harddisk0\Partition1"

Step 5) Use Notepad to create a file named boot.hdd at \ on USB stick with these two lines:

[Operating Systems]

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP" /fastdetect

Step 6) Boot from the USB stick on the Target computer. This starts the text-mode portion of Setup.

Follow the instructions on-screen, creating/formatting a partition on the Harddisk as needed in the process. Make sure to install Windows XP in the first partition, in the WINDOWS directory.

Step 7) When Setup reboots, reboot from the USB stick again and enter Recovery Console. If you try to boot from the Harddisk at this point, you'll get a hal.dll error.

Step 8) Using the Recovery Console, rename c:\boot.ini to boot.bak. Copy \boot.hdd from USB stick to c:\boot.ini

Step 9) Reboot, this time from the Harddisk. This starts the first GUI portion of Setup. Proceed as normal, but you are asked for the location of various files several times along the way. Each time answer with D:\I386, where D is the drive letter of the USB stick at this point. Trial and error works here. Have to do this about 20 times total.

Step 10) When setup reboots again, reboot from the Harddisk. This is the last GUI portion of Setup. Proceed as normal.

Done! This process took me 61 minutes from start to finish, which included 30 minutes for copying the contents of the CD onto the USB stick. The process is non-destructive in the sense that it does not modify the contents of the USB stick in any way.

Remarks

* Using Windows 7, partitioning with diskpart and formatting via Windows Explorer is actually sufficient to create a bootable USB stick. The resulting stick will boot in most modern PCs, and a lot of older ones. When formatting, Windows 7 correctly enters drive number 80h in the BPB of the partition on a USB stick (unlike Windows XP, which enters 00h, leading to issues with bootability). However, creating a bootable USB stick is not always an easy or guaranteed process. It worked for me on my hardware, but your milage may vary.

* Conventionally, setupldr.bin is renamed to ntldr, but I had to use bootmgr instead, because naturally the VBR code placed by Win 7 loads that one.

* As is well-known, XP setup can be performed from a properly prepared local source on the USB stick, using $WIN_NT$.~BT/$WIN_NT$.~LS. What's less known is that setup can be booted and performed from *any* directory, using BootPath and SetupSourceDevice. These two settings are honoured if placed in txtsetup.sif in the current directory next to ntdetect.com. SetupSourceDevice overrides the need for a CD drive.

* The value of SetupSourceDevice can be any valid NT device path. When booting from a USB stick, the stick normally gets assigned as \Device\Harddisk0. The fun thing is that other paths also work, for example "\GLOBAL??\D:", where D is the drive letter assigned to your USB stick when booting from it. (Bit of trial and error needed here). The trick is that all Win32 device paths are actually a subset of all NT device paths, attached under \GLOBAL??. Note that paths other than NT device paths don't work (such as ARC paths, or direct Win32 paths such as "D:" or "\\.\Physicaldisk0".

* There is no need to prepare winnt.sif

* The deal with having to prepare a boot.ini file in advance and copy it over using Recovery Console is because of the ARC path problem arising from booting from USB, which leads to the (in)famous hal.dll error. Sadly Recovery Console doesn't allow file editing, so the correct boot.ini has to be prepared in advance. This issue is well-documented, so just in brief:

When booting from USB under XP (and its setup), the USB stick is assigned multi(0)disk(0)rdisk(0), and the internal harddisks are assigned multi(0)disk(0)rdisk(1) onwards. When booting from the harddisk, it is of course assigned multi(0)disk(0)rdisk(0). Since the setup was started by booting from USB, an incorrect boot.ini file is created on the harddisk (with a multi(0)disk(0)rdisk(1) entry). In order to correct this and allow booting from the harddisk, the boot.ini file on the harddisk needs fixing.

Edited June 21, 2011 by Legorol

[jaclaz]

Just for the record:

* Conventionally, setupldr.bin is renamed to ntldr, but I had to use bootmgr instead, because naturally the VBR code placed by Win 7 loads that one.

IF you work with windows 7, you can use bootsect.exe /NT52 allright (and have the VBR invoke NTLDR)

* The deal with having to prepare a boot.ini file in advance and copy it over using Recovery Console is because of the ARC path problem arising from booting from USB, which leads to the (in)famous hal.dll error. Sadly Recovery Console doesn't allow file editing, so the correct boot.ini has to be prepared in advance. This issue is well-documented, so just in brief:

When booting from USB under XP (and its setup), the USB stick is assigned multi(0)disk(0)rdisk(0), and the internal harddisks are assigned multi(0)disk(0)rdisk(1) onwards. When booting from the harddisk, it is of course assigned multi(0)disk(0)rdisk(0). Since the setup was started by booting from USB, an incorrect boot.ini file is created on the harddisk (with a multi(0)disk(0)rdisk(1) entry). In order to correct this and allow booting from the harddisk, the boot.ini file on the harddisk needs fixing.

Since you boot anyway to Recovery Console, nothing prevents you to run BOOTCFG:

http://commandwindows.com/recovery-console-commands.htm

You may need a "fake" Windows installation , something similar to my "no more CATCH22" trick, though.

Reference:

http://www.911cd.net/forums//index.php?showtopic=20983&st=25

jaclaz

[Legorol]

Just for the record:

IF you work with windows 7, you can use bootsect.exe /NT52 allright (and have the VBR invoke NTLDR)

That is true, but there are a few reasons why I didn't use it. An NT 6.x type bootsector seems to boot setupldr.bin just fine, when renamed correctly. It's also debatable whether my mission restriction (use standard Windows 7) allows the use of bootsect.exe or not, since bootsect.exe is only found on the Windows 7 DVD and isn't installed on the computer by default. What if you don't have the Windows 7 DVD with you? ;-) I also wanted to keep it as short and simple as possible (which is a contradiction, considering I'm trying to install from USB ;-) ), so if it's not necessary, I didn't include it.

There is another consideration as well though. The procedure as I described actually almost works using Windows XP instead of Windows 7. The only snag under XP is that it's not as straightforward to make your USB stick bootable. You would need a third party tool in that case, if only to change the drive letter to 80h in the BPB and optionally change the FAT type to LBA. However, running something like the HP USB Tool to format with instead of Windows Explorer is sufficient. Everything else works as is under XP too, so I didn't want to include the use of bootsect.exe.

Since you boot anyway to Recovery Console, nothing prevents you to run BOOTCFG:

http://commandwindows.com/recovery-console-commands.htm

I tried bootcfg, but there doesn't seem to be a way to actually edit the ARC path. When you add a Windows installation with bootcfg, it constructs an incorrect ARC path just like setup does. Please let me know if I missed an option to bootcfg or something, this would be a good improvement to my procedure :-)

You may need a "fake" Windows installation , something similar to my "no more CATCH22" trick, though.

Reference:

http://www.911cd.net/forums//index.php?showtopic=20983&st=25

jaclaz

This is very neat, I will remember this! Luckily this wasn't necessary for me, I was able to access both C:\ and the USB stick and copy a file over. I can see how this trick can be useful though.

[jaclaz]

I do not remember the problems you describe with simply partitioning/formatting a USB hard disk (i.e. something that is seen as "fixed") with XP, but I may well be wrong.

I tried bootcfg, but there doesn't seem to be a way to actually edit the ARC path. When you add a Windows installation with bootcfg, it constructs an incorrect ARC path just like setup does. Please let me know if I missed an option to bootcfg or something, this would be a good improvement to my procedure :-)

You may need a "fake" Windows installation , something similar to my "no more CATCH22" trick, though.

Reference:

http://www.911cd.net/forums//index.php?showtopic=20983&st=25

This is very neat, I will remember this! Luckily this wasn't necessary for me, I was able to access both C:\ and the USB stick and copy a file over. I can see how this trick can be useful though.

Just a guess, mind you, but if you have a "fake" windows install on the booted USB device (see above), if you use BOOTCFG to add it (and NOT the real one) the ARCpath should be correct:

http://support.microsoft.com/kb/291980/en-us

Since you are into experimenting, another thing that you may want to check is whether the use of the debug.exe (that comes with XP) is possible to do some "sector manipulation".

A rough example is here:

http://www.911cd.net/forums//index.php?showtopic=7233

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/debug.mspx?mfr=true

If a batch file is not considered "third party tool" under your "Rules", it may solve the "formatting problem" and/or the "loader name", that is IF debug allows writing to sectors under XP and/or Windows 7.

Another option (lame, I know) is to make a copy of SETUPLDR.BIN renamed to BOOTMGR and one renamed to NTLDR and when you run Recovery Console, issue a FIXBOOT command.

But even this "cosmetic" change won't change what I see as the "real" issue, that of Renaming a "basic system file", reasons here:

http://reboot.pro/2362/

http://reboot.pro/5209/page__st__6

jaclaz

[jaclaz]

Verified.

Debug has no direct disk access under any of NT/2K/XP and latrer OS.

I start to think that there is nothing capable of accessing a disk sector in "default" MS OS install so, it's a dead end.

jaclaz

[Legorol]

It's a shame that debug doesn't work for sector writing.

The issue under XP is this. As I'm sure you know, a USB stick is seen as removable media by XP, even if it's partitioned like a Harddisk (with MBR etc.). XP can format the drive, which just reformats the existing partition without touching the MBR or partition table. When you do so, XP writes the drive number 00h in the BPB of the formatted partition. This often causes problems when trying to boot the stick, because when booting, the stick is (or should be) emulated as a Harddisk and is accessible by drive number 80h.

I finally understood what your idea was by using a fake installation. So I set one up on the USB stick in a WINDOWS directory, as you describe in http://www.911cd.net/forums//index.php?showtopic=20983&st=25. I proceeded with text-mode setup first, and then booted to Recovery Console. Sure enough it offered me a choice of logging into C:\WINDOWS and D:\WINDOWS, where C was the Harddisk and D the USB stick. I tried both, and tried to use bootcfg. Unfortunately however, bootcfg only offered to add C:\WINDOWS to boot.ini, it didn't see the D:\WINDOWS directory. So this didn't help.

I take your point about not renaming system files, the caution is justified. I think just for the purpose of this project, I was OK. I was envisioning a scenario where you might be stuck with a restricted set of tools, for example because you are out visiting a client site.

[Legorol]

I forgot to mention that I also tried the procedure I describe in the first post by setting SetupSourceDevice="\GLOBAL??\D:", instead of "\Device\Harddisk0\Partition1". This has an advantage.

As you know, the Device paths get assigned depending on what device you boot from: if you boot from USB, then the USB is Harddisk0 and the internal Harddisk is Harddisk1, but if you boot from the internal Harddisk, that is Harddisk0. However, drive letters are always assigned starting with the first partitions of internal Harddisks. So if you just have one internal Harddisk with one partition, and one USB stick, then the internal partition is always C:, and the USB one is D:, no matter how you boot. What this means is that drive letters remain consistent throughout setup.

If you use SetupSourceDevice="\Device\Harddisk0\Partition1" and follow the procedure in the first post, then during the GUI portion of setup, it asks for the location of files a number of times (about 20 in total). This is because for the GUI portion, I was booting from the internal Harddisk, so that is Harddisk0. However, if you use "\GLOBAL??\D:", setup finds the files on the USB stick both during text and GUI portion.

The only thing to watch out for is at the start of the text portion of setup, when you are repartitioning your internal Harddisk. After you are done with that, reboot once and restart setup to make sure the drive letters are assigned correctly.

Edited June 22, 2011 by Legorol

[jaclaz]

I forgot to mention that I also tried the procedure I describe in the first post by setting SetupSourceDevice="\GLOBAL??\D:", instead of "\Device\Harddisk0\Partition1". This has an advantage.

This is very nice.

The issue under XP is this. As I'm sure you know, a USB stick is seen as removable media by XP, even if it's partitioned like a Harddisk (with MBR etc.). XP can format the drive, which just reformats the existing partition without touching the MBR or partition table. When you do so, XP writes the drive number 00h in the BPB of the formatted partition. This often causes problems when trying to boot the stick, because when booting, the stick is (or should be) emulated as a Harddisk and is accessible by drive number 80h.

Yes, but you see, under XP diskpart or disk management won't allow the partitioning, and you need a third party tool anyway, be it a "RMPREPUSB like" utility or the Cfadisk/dummydisk driver or anyay something "designed" to have the stoopid stick properly partitioned and bootable.

I don't remember having noticed any problem with "drive number" in the BPB, but as said it is perfectly possible that it does create problems.

I finally understood what your idea was by using a fake installation. So I set one up on the USB stick in a WINDOWS directory, as you describe in http://www.911cd.net/forums//index.php?showtopic=20983&st=25. I proceeded with text-mode setup first, and then booted to Recovery Console. Sure enough it offered me a choice of logging into C:\WINDOWS and D:\WINDOWS, where C was the Harddisk and D the USB stick. I tried both, and tried to use bootcfg. Unfortunately however, bootcfg only offered to add C:\WINDOWS to boot.ini, it didn't see the D:\WINDOWS directory. So this didn't help.

That's why I said :

You may need a "fake" Windows installation , something similar to my "no more CATCH22" trick, though.

I mean, we do know that in order to set the stoopid variables, the RC needs to access ONLY some very limited parts of the Registry:

Now, it seems like RC "detects" the existence of a XP install on HD by checking for the existence of BOTH:

a. a subdirectory \whatever\System32\config

b. a subdirectory \whatever\System32\drivers

then it connects to the hive SOFTWARE inside \whatever\System32\config\ and reads ONLY the said key in it.

it is very possible that bootcfg looks for "something else".

For testing purposes, try copying a "whole" Registry to the "\whatever\System32\config" directory (but probably also some keys in it needs to be changed)

I take your point about not renaming system files, the caution is justified. I think just for the purpose of this project, I was OK. I was envisioning a scenario where you might be stuck with a restricted set of tools, for example because you are out visiting a client site.

Sure , not at all a problem for this use/purpose of this project, which is anyhow reserved to people that know where their towel is.

[Legorol]

I forgot to mention that I also tried the procedure I describe in the first post by setting SetupSourceDevice="\GLOBAL??\D:", instead of "\Device\Harddisk0\Partition1". This has an advantage.

This is very nice.

I don't think I have seen this use of SetupSourceDevice anywhere, which is why I posted it. I came up with the idea after reading Naming Files, Paths, and Namespaces. I was reading today about techniques for assigning a fixed drive letter to the USB stick, for example as mentioned in . It just occured to me that once you have a fixed drive letter, you can use \GLOBAL??\D: in a predictable way.

Yes, but you see, under XP diskpart or disk management won't allow the partitioning, and you need a third party tool anyway, be it a "RMPREPUSB like" utility or the Cfadisk/dummydisk driver or anyay something "designed" to have the stoopid stick properly partitioned and bootable.

I don't remember having noticed any problem with "drive number" in the BPB, but as said it is perfectly possible that it does create problems.

Yes, you are right. If you don't already have a bootable USB stick, you are stuck under XP. However, when you buy them in the shop, nowadays USB sticks come prepartitioned already, so you are not too far away, and just need to format it. That you can do under XP as well, so the only snag under XP is the "drive number". As for what this snag is, as we discovered over at http://www.911cd.net/forums//index.php?showtopic=24395, the VBR code uses the driver number in the BPB to try and load NTLDR. If it's not the correct number, you get a "Disk Error" when trying to boot.

it is very possible that bootcfg looks for "something else".

For testing purposes, try copying a "whole" Registry to the "\whatever\System32\config" directory (but probably also some keys in it needs to be changed)

I see, this could work. Unfortunately I won't be trying this due to time constraints. It digresses a bit too much from my original goal, and I would like to do some other experimenting. Maybe later

Sure , not at all a problem for this use/purpose of this project, which is anyhow reserved to people that know where their towel is.

Actually, I was kind of hoping to distill a procedure that is as simple as possible and relies on no other tools so that maybe it can be written up as a general guide. I can now install from the USB stick almost like from a CD, with only the following extra steps required:

* Make your USB stick bootable (this could be a bit technical, but is easy under Win 7 by just partitioning/formatting)

* Copy 3 extra files (setupldr.bin, ntdetect.com, txtsetup.sif)

* Edit 2 lines in txtsetup.sif in Notepad

* Create a boot.hdd file with 2 lines in Notepad

* Enter Recovery Console once to copy 1 file

Still a bit on the technical side, but not too bad If I can find a (simple) way to avoid having to enter Recovery Console, I would be happy.

[jaclaz]

No prob whatever, take all the time you need (and more) this is FUN, remember

About fixing a drive letter, the reference is "migrate.inf":

http://www.911cd.net/forums//index.php?showtopic=19663

that can be used for other tweaks too.

Still a bit on the technical side, but not too bad If I can find a (simple) way to avoid having to enter Recovery Console, I would be happy.

Sure , I would say excellent instead of "not too bad"

I am thinking about it, but without *ANY* third party tools (and no batches) I think it is hard.

And anyway there may a difference between "running Vista or 7 and installing XP" and "running XP and installing XP".

jaclaz

[Legorol]

Fun it is!

About fixing a drive letter, the reference is "migrate.inf":

http://www.911cd.net/forums//index.php?showtopic=19663

that can be used for other tweaks too.

I was just reading up on this area. Thanks for the links!

I am thinking about it, but without *ANY* third party tools (and no batches) I think it is hard.

It is hard Remember, Microsoft didn't intend for us to install XP from USB Batches are technically allowed though, since you can create them in Notepad B) however the aim is simplicity, so a 300 line batch that you have to type in yourself wouldn't work.

And anyway there may a difference between "running Vista or 7 and installing XP" and "running XP and installing XP".

Sadly yes, so for now "running 7 and install XP" or at least "make bootable stick in 7 and do the rest in XP".

Idea: Get an inf-based method to copy boot.ini over from the USB stick to the Harddisk during text-mode Setup. Maybe migrate.inf, maybe txtsetup.sif, it's too early to tell. I wonder what happens, whether Setup would just overwite it at the end of text-mode before the reboot. I will see.

Edited June 22, 2011 by Legorol

[Legorol]

Sadly this idea didn't work out, thwarted by Setup

Steps:

1) I put a file "test.txt" in the \I386 directory of the USB stick.

2) In txtsetup.sif, in [systemPartitionFiles], I added a line:

test.txt="\"

3) In [sourceDisksFiles], I added a line:

test.txt = 1,,,,,,_x,1,0,0

I then did Setup as usual. Result: test.txt appeared both in C:\ and C:\WINDOWS, as expected. (Changing the 0,0 to 3,3 would eliminate copy in \WINDOWS).

Instead of test.txt, I repeated the experiment with a boot.ini file with the correct multi(0)disk(0)rdisk(0)partition(1) line. Sure enough, it got copied to \WINDOWS, but the boot.ini in C:\ was still the one normally created by Setup It means that Setup creates boot.ini after file copy, and completely overwrites it.

Another idea: try to copy the real NTLDR to the root of the USB stick during text-mode setup, to replace setupldr.bin. Together with a correctly prepared boot.ini, what this means is that when text-mode setup is complete, could just reboot from USB to resume setup. This would be a destructive change, but at least no Recovery Console need. So the aim: get Setup to copy a file to D:\.

Steps are similar to before:

1) Put "test.txt" in \I386 of the USB stick.

2) In txtsetup.sif, in [systemPartitionFiles], add a line:

test.txt="D:\"

3) In [sourceDisksFiles], add a line:

test.txt = 1,,,,,,_x,1,0,0

To my surprise, test.txt showed up in C:\ instead of D:\ (as well as in C:\WINDOWS, but that's expected). I tried a few alternative paths: "\\.\D:\", "\\.\Physicaldrive0" and "\\.\Physicaldrive1". Each time, test.txt showed up in C:\ (Note: I reformat C: each time, so the file wasn't just accidentally left there).

Back to the drawing board!

[jaclaz]

I then did Setup as usual. Result: test.txt appeared both in C:\ and C:\WINDOWS, as expected. (Changing the 0,0 to 3,3 would eliminate copy in \WINDOWS).

Instead of test.txt, I repeated the experiment with a boot.ini file with the correct multi(0)disk(0)rdisk(0)partition(1) line. Sure enough, it got copied to \WINDOWS, but the boot.ini in C:\ was still the one normally created by Setup It means that Setup creates boot.ini after file copy, and completely overwrites it.

This is "strange".

I mean, let's take the case when you ALREADY have an installed 2K or XP on the internal hard disk and you want to install (from a "normal" CD) an "additional" instance.

The BOOT.INI already on root of "C:\" is not overwritten, the entry to the "additional" instrance is added to it. (actually the existing BOOT.INI is first modified to add the temporary entry for the install (after reboot) and then this temporary addition is removed.

Maybe this happens because when you boot the CD the BOOT.INI is ALREADY there?

Or maybe some checks (just like the ones for the CATCH22 trick) are performed to verify that another instance of windows is present?

I dont' think the latter applies,

I mean, if I do a dual boot install of DOS (7.1/8.0) and XP (on a FAT32 C:\ drive) then I decide to delete the whole Windos stuff, the "Bootsect.dos" file and the entry pointing to it should not be deleted when I re-install XP.

But yes, the binifix batch was at the time created to solve this issue AFAICR (a lot of time has passed, and my memory is not as good as it used to be ), relevant links should be these:

You will need some time to go through the various steps taken, I cannot even remember if this

has been added/coorected

jaclaz

[Legorol]

That is an excellent point you bring up about Setup for dual-booting, didn't think of that. So I tested it, and the conclusion is this. If BOOT.INI is present when Setup starts, then Setup will only append to it, but if it is not present at the start, a new one is created, overwriting any that is copied during the Setup itself. Sadly.

I have seen your binifix batch file included in USB_MultiBoot_10.zip at http://www.911cd.net/forums//index.php?showtopic=22857. As you say, it is doing the job of correcting the BOOT.INI entry at the end of the GUI Setup.

[jaclaz]

That is an excellent point you bring up about Setup for dual-booting, didn't think of that. So I tested it, and the conclusion is this. If BOOT.INI is present when Setup starts, then Setup will only append to it, but if it is not present at the start, a new one is created, overwriting any that is copied during the Setup itself. Sadly.

What happens if you boot SETUP twice?

Once to just Partition/Format and start install? Then "break it" at some stage?

Once for actually installing?

Could first round allow copying a BOOT.INI that becomes "base" for additions?

Or somehow add a "fake" (or real) IO.SYS/MSDOS.SYS/COMMAND.COM?

Would in this case setup create a "stable" BOOT.INI with the provision for the DOS (like c:\bootsect.dos or the like)?

Can this be somehow used to our "advantage"?

What does F2 do?

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

Do we know in which order the "text/inf" files in setup are processed?

I mean is there anything that allows the copy of the file or a rename of it just before the reboot?

Mind you just semi-random ideas , let's call it free-no-limit-brain-storming....

jaclaz

Edited June 24, 2011 by jaclaz