mrjrt

Before you ask, I'm deliberately doing a bit of an educational project, which is why I'm playing with obsolete software (i.e. XP). With that out of the way, I'm currently manually integrating USB3 drivers so that USB3 mass storage devices work in text mode setup. I have this working fine with the Etron drivers and my motherboard's built-in USB3. To test against other chipsets I bought a couple of cheap cards off eBay, and it was not until they turned up that it dawned on me that I would be unable to test booting off them as they generally don't have option ROMS. My solution here was to boot off my built-in USB3, but to have some USB3 storage in the new card's ports so they would show up. Problem is, they don't. Doesn't even so much as flash the access indicator. The VIA drivers are all happy enough once detected as part of GUI PnP setup - all works fine from there. Text mode however is another story. Now, based upon what I have in place for my Etron drivers which work, I have the following set: The PnP IDs are in the hardware IDs database (mine's the DEV_3483):PCI\VEN_1106&DEV_9201 = "viaxhci"PCI\VEN_1106&DEV_3432 = "viaxhci"PCI\VEN_1106&DEV_3483 = "viaxhci"USB\VIA_ROOT_HUB = "viahub3"VUSB1\CLASS_09 = "viahub3"VUSB2\CLASS_09 = "viahub3"VUSB2\CLASS_09&SUBCLASS_00&PROT_02 = "viahub3"VUSB3\CLASS_09 = "viahub3"The drivers are set to load along with the rest of the USB drivers:[InputDevicesSupport.Load]etronxhci = etronxhci.sysetronhub3 = etronhub3.sysviaxhci = xhcdrv.sysviahub3 = viahub3.sysusbehci = usbehci.sys...etcThe drivers are also filled-in the same elsewhere:[InputDevicesSupport]etronxhci = "Etron USB 3.0 Extensible Host Controller",files.none,etronxhcietronhub3 = "Etron USB 3.0 Extensible Root Hub",files.none,etronhub3viaxhci = "VIA USB 3.0 eXtensible Host Controller",files.none,viaxhciviahub3 = "VIA USB 3.0 eXtensible Root Hub",files.none,viahub3usbehci = "Enhanced Host Controller",files.usbehci,usbehci...etc...and the WDF libraries are also in the i386 directory (without which the drivers cannot be loaded):wdf01000.syswdfldr.sys...so I know they're being loaded. And I know they work with my hardware as they're fine from the PnP stage. I've also tried explicitly loading the WDF:[BootBusExtenders]wdf01000 = "Kernel Mode Driver Framework Runtime",files.none,wdf01000[BootBusExtenders.Load]wdf01000 = wdf01000.sysSo, any ideas why they aren't picking up any mass storage devices? Short of checking they're loading (they are) and it's not blowing up (it's not), I don't really know how I can troubleshoot the problem here! For completeness, I've found threads here: http://reboot.pro/topic/17769-kmdf-integrate-into-xp-install-cd/ http://forum.driverpacks.net/viewtopic.php?id=6258 ..and this: http://gena.spam.net/Projects/Gena/Drivers/4%20Storage/RemovableDeviceUSB3%20More.script ...which all suggest it should work. The primary difference being that they tend to use the bus extenders sections rather than the input devices ones...but I used those because that's where the rest of the stock USB support is, and it works for the Etron drivers, so... Next plan of action is to try and see if adding the registry keys the full-fat PnP inf sets up helps any.

Just thought I'd come back to this as I don't like finding abandoned threads... Basically, I think I was being an id*** and confusing myself. I'm not sure. Suffice to say, I cleared everything down to stock and started again and found that it was more likely related to the USB3 support than anything else, but in the process have ended up in a bit of a quandary with RTM USB2. If I add in USB3 support as well, then I currently lose all USB1 & USB2 until GUI PnP setup, but it's fine from then on. If I don't patch in USB3, then my backported USB2 works fine. Hmm. As for the HAL issues, I found that backporting processr.sys from SP2 (and tweaking CPU.inf to not overwrite it!) solves that issue perfectly. I'm currently integrating more USB3 drivers, but that's not related to RTM so I'll leave it there.

So...I identified the cause of the SP1 failures. If I switch HAL during setup, it installs fine. Doing a spot more digging identified the issue is that when using the ACPI Multiprocessor HAL setup crashes when installing cpu.inf (which installs a driver specific to your CPU, processr.sys for Intel CPUs, or a special alternative if needed). Removing the inf file enables SP1 setup to complete successfully. I might do a bit more digging to see why it seemingly has no issues on SP2 & SP3. So now I'm back, at last, to RTM. Alas, text mode fails with: 0x0000006B ( PROCESS1_INITIALIZATION_FAILED ), and from the params (0x7A (STATUS_PROCEDURE_NOT_FOUND), 0x8 (?), 0x0, 0x0) I can tell that it can't find a procedure, so probably just need ot copy over another setup-related binary.

I can certainly have a look for you, but I deliberately went through the USB ID database at http://www.linux-usb.org/usb.ids to hunt down all known floppy, optical, bridge et al IDs so that XP would know how to handle the devices with the existing usbstor.sys driver. I suspect all I personally would require would be the bridge ID for the USB-SATA enclosure my optical drive uses, but those IDs are freebies that don't require modification to any installed files, so I'm not too fussed about those. In other news: SP1 completes text mode successfully (yay!), but BSODs in GUI mode setup near the end of the devices phase with a 0x0A (IRQL_LEVEL_NOT_EQUAL). I've confirmed the files on disk copied from text mode are the original SP1 ones, so I may have to do a bit more experimenting there. Perhaps installing SP1 from a SATA drive and then seeing what happens when I plug the optical drive into a running SP1 system...? Interestingly, if I leave the optical drive unplugged that phase doesn't crash, but obviously setup can't find files on the disc until I connect it.

So... ...we seem to have some progress, and some accidental bonuses. First up, I just installed SP2b from a USB-BD drive successfully. What was needed were the following files from SP3 (5.1.2600.5512) replacing the SP2 (5.1.2600.2180) versions: NTKRNLMP.EX_ - SMP NT kernel NTOSKRNL.EXE_ - Uniprocessor NT kernel USBEHCI.SY_ - USB Enhanced Host Controller Interface (aka. 2.0 aka. high-speed) driver USBOHCI.SY_ - USB Open Host Controller Interface (aka. 1.1 aka low-speed/full-speed) driver...and of course the smattering of additions to the hardware IDs DB in txtsetup.sif. The updated SP3 kernel alone is insufficient, and will BSOD in the same way as the stock SP2 kernel, suggesting that jaclaz is indeed correct - MS lies and the updated drivers are required to avoid the re-enumeration. I suspected this would be the case when I found that the kernel from their hotfix that supposedly resolved the problem actually pre-dated SP2, which still had it (the hotfix is build 1524 and SP2 is 2180). As the intent of my experiments is to have a clean install for compatibility testing (in this case, of SP2), having those files from a later version wasn't ideal in the end installation. Earlier failed attempts with more files and unsigned driver bypasses left me with those files in the resulting installation, so I was just about to do some trickery using renamed source files (as the kernel and drivers only need to exist during the initial read from disc - when the files are copied to mass storage I intended to overwrite them with the correct SP2 versions), I thought I'd try something and lo and behold - the install had lost the unsigned driver prompts and left me with the SP2 copies of the files, exactly as I wanted. Having done a lot of reading the last few days, I'm fairly certain I know what has happened. The stock disc contains the updated versions of the files in the SP2.cab file, and these will be extracted over the separate files copied earlier from I386. Additionally, when there are multiple candidates for a driver Windows will rank them, with valid, signed drivers having a higher score. I suspect that if it isn't just a simple overwrite from the SP2.cab file then Windows is finding the SP3 drivers, deciding they're unsigned, and ranking the SP2 drivers higher and installing those instead. Regardless, it works, leaves me with a stock install, and has only 4 files replaced from stock, which is nice. Onwards to SP1.

Thanks for the ideas. Basically, my ultimate aim is indeed installing from a USB stick, but I want to reserve the option of installing to a older machine when required, hence my decision to go down the route of building an ISO (that could be burnt to disc), and then using Firadisk to make said ISO available as a first option for the USB stick. This also enables hardlink-style de-duplication, letting me get 5 or so increasingly-tweaked versions of 15-odd variations of XP in a single 3GB ISO.) Having had some troubles with the initial Firadisk approach I decided to ensure a traditional CD-based fallback for troubleshooting, and given the issues I'm experiencing with my USB optical drive I'm beginning to suspect the problem is indeed the USB side of things (and indeed, file-mapped ISOs on the stick also seem to fail in a similar way). In truth, I've not had to restore a file from the install media for over 15-odd years, so I'm not to bothered about that. A couple of my USB sticks stashed away and 7zip to extract from the ISO should suffice I'll have a look at the PE-route, but my current plan works well enough if you install on hardware of an appropriate vintage...I'm just seeing how far back I can push that threshold.

Thanks for that - much obliged. Unfortunately doesn't seem to have made much difference - RTM still 0x7Bs, with: a) NTDETECT.COM from SP3 b) Modifed NTDETECT.COM from the threads mentioned above c) The kernels from that KB hotfix. d) The SP3 kernels and SP3 NTDETECT.COM Given your comments I might have a play with SP2 (and if that works, working back to SP1), but I'm tempted at this point to just include a note that you need an IDE optical drive to install anything older than SP3

...and just in case anyone else tries this later - it's a dead end. The fix unfortunately is in Ntoskrnl.exe / Ntkrnlmp.exe / Ntkrnlpa.exe / Ntkrpamp.exe, and the hotfix is for SP2, which would explain why SP3 works fine but nothing else does. I should be able to apply the hotfix to my SP2 images, but my RTM and SP1 images are SOL.

Ahem. Think I've found it. SP1 adds some kernel exports to NTOSKRNL.EXE, in particular KeRegisterBugCheckReasonCallback and KeDeregisterBugCheckReasonCallback. USBPORT.SYS from SP3 links to these, and USBEHCI.SYS links to that, so it fails to load due to runtime link failure. I've replaced the USBPORT.SYS with the RTM one and the error went away. USBEHCI.sys loads up fine now.

Hello all. I'm doing a bit of an experiment to see if I can backport the USB support in SP3 to previous versions of XP. It's mainly just an interesting little project, but I have a USB BD-drive, and can't use it to install from a disc pre-SP3 as setup loses the drive and BSODs. Not that I'm likely to need to, but anyway. Project. I've read a lot of guides on this of late, and have integrated all sorts of other things successfully elsewhere using various tools, and I've certainly read a lot of threads, but I'd like to just clarify things as I can't seem to get the basics working when I do things manually, but I like to understand how my tools work so I can troubleshoot when they don't. This is a near-as clean copy of RTM (just some multiboot tweaks to the loaders), so conflicts aren't likely. As a first step, my primary objective is to get the USB2 support into RTM. To this end I've looked at how this is achieved, and have copied the relevant files into a new cab (USB.cab a-la a SPx.cab file). I later discovered that the files also seem to exist compressed in the i386 directory directly, so I copied those over from SP3 as well (USBEHCI.SY_, etc.). Two new files, and a few updated ones. To apply those files I added the following bits into my txtsetup.sif: --- D:/Temp/XPx86/install/O200/TXTSETUP.SIF Sat Aug 18 12:00:00 2001+++ D:/Temp/XPx86/install/O201/TXTSETUP.SIF Sun Nov 15 03:08:04 2015@@ -3476,6 +3476,7 @@ hardware.chm = 1,,,,,,,21,0,0 harrow.cur = 1,,,,,,,,3,3 HCAppRes.dll = 1,,,,,,,,3,3+hccoin.dll = 1,,,,,,,2,1,3,,1,2 hcross.cur = 1,,,,,,,,3,3 hdwwiz.cpl = 1,,,,,,,2,0,0 Headsp~1.wmz =1,,,,,,,,3,3 @@ -7671,12 +7672,14 @@ ups.exe = 1,,,,,,,2,1,0 ureg.dll = 1,,,,,,,2,1,0,,1,2 urgent.cov = 1,,,,,,,,3,3 +USB.cab = 1,,,,,,,39,0,0 usb.inf = 1,,,,,,,20,0,0 usb8023.sys = 1,,,,,,,4,0,0,,1,4 usbaudio.sys = 1,,,,,,,,3,3 usbcamd.sys = 1,,,,,,,4,0,0,,1,4 usbcamd2.sys = 1,,,,,,,4,0,0,,1,4 usbccgp.sys = 1,,,,,,4_,4,1,3,,1,4+usbehci.sys = 1,,,,,,4_,4,1,3,,1,4 usbohci.sys = 1,,,,,,4_,4,1,3,,1,4 usbport.inf = 1,,,,,,,20,0,0 usbprint.inf = 1,,,,,,,20,0,0@@ -15323,7 +15326,8 @@ -SetupSourcePath = "\"+SetupSourcePath = "\O201\"+BootPath = \O201\I386\ MajorVersion = 5 MinorVersion = 1 DefaultPath=\WINDOWS@@ -15359,7 +15363,7 @@ Architecture = i386 -DriverCabName=driver.cab+DriverCabName=driver.cab,USB.cab ProductType = 4 DisableAsr = 1@@ -18060,10 +18064,12 @@ *ADP4215 = "aha154x" GenSFloppy = "sfloppy" SCSI\DiskMATs***ALS-120_COSM___04 = "sfloppy"+PCI\CC_0C0320 = "usbehci" PCI\CC_0C0310 = "usbohci" PCI\CC_0C0300 = "usbuhci" USB\COMPOSITE = "usbccgp" USB\ROOT_HUB = "usbhub"+USB\ROOT_HUB20 = "usbhub" USB\Class_03&SubClass_01&Prot_02 = "hidusb" USB\Class_03&SubClass_01 = "hidusb" USB\Class_03 = "hidusb" [InputDevicesSupport.Load]+usbehci = usbehci.sys usbohci = usbohci.sys usbuhci = usbuhci.sys usbhub = usbhub.sys@@ -18405,6 +18434,15 @@ usbport.sys,4 usbohci.sys,4 +[files.usbehci]+hid.dll,2+hccoin.dll,2+hidclass.sys,4+hidparse.sys,4+usbd.sys,4+usbport.sys,4+usbehci.sys,4+ [files.usbuhci] hid.dll,2@@ -18461,6 +18499,7 @@ kbdclass.sys = 16 mouclass.sys = 16 driver.cab = 16+USB.cab = 16 @@ -20543,6 +20582,7 @@ i2omgmt = "Intelligent I/O Support Driver" [InputDevicesSupport]+usbehci = "Enhanced Host Controller",files.usbehci,usbehci usbohci = "Open Host Controller",files.usbohci,usbohci usbuhci = "Universal Host Controller",files.usbuhci,usbuhci usbhub = "Generic USB Hub Driver",files.usbhub,usbhubThis is what I stuck in drvindex.inf: --- D:/Temp/XPx86/install/O200/i386/drvindex.inf Sat Aug 18 12:00:00 2001+++ D:/Temp/XPx86/install/O201/i386/drvindex.inf Sat Nov 14 21:45:49 2015@@ -1,6 +1,6 @@ [Version] signature="$Windows NT$"-CabFiles=driver+CabFiles=USB,driver [driver]@@ -1995,11 +1995,8 @@ hcf_msft.sys hermes_1.ppd hermes_2.ppd-hid.dll hidbatt.sys-hidclass.sys hidgame.sys-hidparse.sys hidserv.dll hidswvd.sys hidusb.sys@@ -4368,16 +4365,10 @@ usbccgp.sys usbd.sys usbdload.hex-usbhub.sys usbintel.sys-usbohci.sys-usbport.sys usbprint.sys usbscan.sys usbser.sys-usbstor.sys-usbuhci.sys-usbui.dll usr1801.sys usr1806.sys usr1806v.sys@@ -4662,7 +4653,19 @@ xxwh1hlp.hlp zlogic.cyz -+[USB]+hccoin.dll+hid.dll+hidclass.sys+hidparse.sys+usbehci.sys+usbhub.sys+usbohci.sys+usbport.sys+usbstor.sys+usbuhci.sys+usbui.dll [Cabs] driver=driver.cab+USB=USB.cab\ No newline at end of file...and I'm booting from disc so strictly-speaking I don't need DOSNET.inf, but I have updated it regardless: --- D:/Temp/XPx86/install/O200/i386/DOSNET.INF Sat Aug 18 12:00:00 2001+++ D:/Temp/XPx86/install/O201/i386/dosnet.inf Sat Aug 18 12:00:00 2001@@ -101,6 +101,7 @@ d1,hidparse.sys d1,usbd.sys d1,usbport.sys+d1,usbehci.sys d1,usbohci.sys d1,usbuhci.sys d1,usbhub.sys@@ -3503,6 +3504,7 @@ d1,hardware.chm d1,harrow.cur d1,HCAppRes.dll+d1,hccoin.dll d1,hcross.cur d1,hdwwiz.cpl d1,Headsp~1.wmz@@ -7938,6 +7940,7 @@ d1,urgent.cov d1,url.dll d1,urlmon.dll+d1,USB.cab d1,usb.inf d1,usb8023.sys d1,usbaudio.sys@@ -7945,6 +7948,7 @@ d1,usbcamd2.sys d1,usbccgp.sys d1,usbd.sys+d1,usbehci.sys d1,usbhub.sys d1,usbmon.dll d1,usbohci.sys...but I keep being told that "The file usbehci.sys is corrupted". My understanding was that I didn't need layout.inf entries if they were compressed, but just in case I copied those over: --- D:/Temp/XPx86/install/O200/i386/layout.INF Sat Aug 18 12:00:00 2001+++ D:/Temp/XPx86/install/O201/i386/layout.inf Sat Aug 18 12:00:00 2001@@ -223,8 +223,8 @@ serenum.sys = 1,,14976,,,,4_,4,0,0,,1,4 parport.sys = 1,,76160,,,,,4,0,0,,1,4 cdrom.sys = 1,,47488,,,,5_,4,0,0,,1,4-usbuhci.sys = 1,,18944,,,,4_,4,1,3,,1,4-usbport.sys = 1,,123264,,,,4_,4,1,3,,1,4+usbuhci.sys = 1,,20608,,,,4_,4,1,3,,1,4+usbport.sys = 1,,143872,,,,4_,4,1,3,,1,4 rasl2tp.sys = 1,,48256,,,,,4,0,0,,1,4 ndistapi.sys = 1,,9600,,,,,4,0,0,,1,4 ndiswan.sys = 1,,87296,,,,,4,0,0,,1,4@@ -3476,6 +3476,7 @@ hardware.chm = 1,,32139,,,,,21,0,0 harrow.cur = 1,,766,,,,,,3,3 HCAppRes.dll = 1,,6656,,,,,,3,3 +hccoin.dll = 1,,7168,,,,,2,1,3,,1,2 hcross.cur = 1,,766,,,,,,3,3 hdwwiz.cpl = 1,,150016,,,,,2,0,0 Headsp~1.wmz =1,,242446,,,,,,3,3 @@ -7677,6 +7678,7 @@ usbcamd.sys = 1,,23808,,,,,4,0,0,,1,4 usbcamd2.sys = 1,,23936,,,,,4,0,0,,1,4 usbccgp.sys = 1,,24960,,,,4_,4,1,3,,1,4+usbehci.sys = 1,,30208,,,,4_,4,1,3,,1,4 usbohci.sys = 1,,15616,,,,4_,4,1,3,,1,4 usbport.inf = 1,,18385,,,,,20,0,0 usbprint.inf = 1,,1670,,,,,20,0,0...but it still complains and dies. So...thanks for reaching the end. Any ideas what I'm doing wrong here? Whilst I wait for replies I'm going to try uncompressing the files in I386 and seeing if that works, as that's one area I'm particularly unfamiliar with. Ideally I'd like them to remain compressed though (for de-duplication purposes), and it has to be possible, I just don't understand if setup is not recognising them as compressed (in which case they will indeed seem corrupted!) or there is some other error...

Thanks for the reply. See, that's what I initially read, and did, but as I say - I'm able to get this working without touching dosnet - as long as I have a copy in I386. Even then when I only specified the .sys file in dosnet.inf it still copied the folder with the .cat and .inf files by the end of GUI setup... ...and IIRC, even when I specified the .sys in the subdirctory in dosnet.inf I still got the "cannot be found" error when referencing it in txtsetup.sif.

I'm doing a spot of tinkering right now, and I'm trying to learn how to manually integrate a few drivers into my various XP sources. I've modified txtsetup.sif, but don't seem to need to modify dosnet.inf (which is nice) I've added a directory tree under I386 ("I386\DRIVERS\FIRADISK"), and added in the SourceDisksNames and the WinntDirectories. I've also added in the files: firadisk.cat = 1982,,,,,,,1982,0,0firadisk.inf = 1982,,,,,,,1982,0,0firadisk.sys = 1982,,,,,,,1982,0,0firadisk.sys = 1,,,,,,,4,0,0...that works, but I have to duplicate the .sys file by adding it to the I386 directory, which seems strange. So I tried: firadisk.cat = 1982,,,,,,,1982,0,0firadisk.inf = 1982,,,,,,,1982,0,0firadisk.sys = 1982,,,,,,,1982,0,0firadisk.sys = 1982,,,,,,,4,0,0...but that doesn't work. Boo! The install fails, reporting that the file "could not be found". I have a work around (have a second copy in I386), but I'd like to understand why it's not copying the file from the directory? Any ideas? All I can speculate is that whatever does the copying can't handle the same file going to multiple destinations...but then if I try to copy from my directory to only system32\drivers it still fails, so that's weird: firadisk.cat = 1982,,,,,,,1982,0,0firadisk.inf = 1982,,,,,,,1982,0,0;firadisk.sys = 1982,,,,,,,1982,0,0firadisk.sys = 1982,,,,,,,4,0,0

Right, solved it. I'd plugged my external drive into a USB3 port for speed whilst forgetting that XP doesn't have drivers for it in an untouched install. Plugging it into a USB2 port and it's all fine. D'oh!

Answering my own question - I'm an id***. I didn't notice that the supposedly "redundant" firadisk floppy image I commented out so I could supply drivers for my RAID controller with a floppy was in fact solving this issue when booting from the multiboot. I guess I'll have to offer two options then: One with the firadisk driver slipsteamed in and F6 available (but obviously not untouched), and another untouched, but with F6 unavailable as that'll be used to load firadisk. That's one mystery solved...still no progress on the USB-BD drive though.

That's interesting - I saw a few things like that, but I was of the impression that Grub's mem mapped drives were driverless - i.e. they hooked into the BIOS interrupts. As long as the OS uses those, it works. If it doesn't, the drives vanish. I looked into the USB-BD error as well - seems you can get the 0x7B error if the USB ID isn't recognised so it doesn't know what driver to use. Thing is, I think my drive is already in there: USB\VID_04DA&PID_0B01 = "usbstor" ...still, the challenge is part of why I'm doing all this in the first place!

I'm trying to install WinXP x64 SP2 as part of a large multiboot disk project. The various XP32 installs are fine, but the x64 installs fail with the classic 0x7B error (Inaccessible boot device, IIRC). I've never seen this in text mode though, but I've read this is because it is losing access to the disc volume. Now, I'm attempting to install this initially via the USB multiboot, which is a basic Grub4DOS mem mapping of the ISO into RAM, but whilst this works great for x86, it fails for x64. To try and narrow down the problem I burnt the ISO to a physical disc, and booted it using a USB3-connected external Bluray drive. This too fails with error 0x7B at the same point. Now, my suspicion is that both Grub and my BIOS's emulation of a drive both in RAM and over USB is being wiped out by the x64 kernel firing up. It's fine in 32-bit mode (probably due to all the compatibility layers), but x64 doesn't have all that "baggage" so probably assumes it has Carte Blanche to do whatever it likes... Does this sound plausible? I'm going to have to try removing the drive from its caddy and hooking it up directly via SATA and see if that works, which should confirm my suspicions...and also trying a clean XP64 ISO, though given where its failing I don't think the multiboot layout is the issue at all as short of a couple of lines in txtsetup.sif and a scattering of files it's all clean already...

One last important caveat I neglected to mention above. When using this, System Restore, being a bit rubbish, gets upset. It really doesn't like ramdisks AFAICT. It also really hates it when you have reparse points pointing to other drives that may not be present 100% of the time. I've tried adding the junction points to system restore's exclusions list in the registry, but it still seems to monitor them, even if only to then ignore the changes. Anyone who figures out how to get it to either not follow reparse points and/or actually ignore directories in the exclusions list, please do let me know. Personally, I don't use it so it's no loss to me, but I've picked up that for some reason people do seem to use it, so be warned.

Fair enough, devcon.exe attached. My understanding of the license is I only need to include it with the source, which is obviously available upon request. But, just in case, it's reproduced in full here, in the spoiler below, for easy reference Devcon.exe

Hello all. I've been using this site as a reference for quite some time and figured I should probably give something back. No idea if anyone will find it useful or not, but here it is, regardless. Basically, I've been tweaking away on a final customised XP install so I never have to fiddle with the d**n thing again and when I need it, it'll be ready. To this end, I've done a fair bit of tweaking and integrating, but there were a few things that I didn't spot cropping up anywhere, so here they are. I'll separate them into multiple posts to keep things coherent. Handy tidbit #2 - Automating ramdisk management of Gavotte's ramdisk (and friends) I want to make use of the RAM in my machines, even when running XP for whatever reason. I found out about the "unmanaged memory" techniques et al., and after much (much) faffing around, I settled on Gavotte as it offered the behaviour and configuration I needed in the most minimal package. I have attached the package I have built to run during my setup. It installs a service that will run at startup and will check and configure the ramdisk with a swap and temp directory on it, and will set up the various junctions to point at it so you don't have to use a drive letter. It will cache the initial state of the built ramdisk in the registry so it will start up faster next time. Now, I've made it very configurable, but I've only fully tested it in my use case, namely, no drive letter, and temp and swap on it where possible. Did I mention, it looks how much RAM you have installed and only moves swap to the ramdisk where it makes sense to? (i.e. > 4GB). I've tested this exhaustively in vmware by adjusting memory amounts - it should handle any sizes (fingers crossed!). As I started to mention, it's pretty configurable. There's a reg file in there with the default values that you can add, and then easily change (i.e. if you don't want any temp management, change the NOTEMP reg value from 0x0 to 0x1...or indeed, anything other than 0x0). It also has some desktop.ini files hardcoded in there with icons you probably won't have. I should probably make those easier to change with out fiddling with the script, but I'm pretty sick of fiddling with this thing now, so I'll leave that as an exercise for the user. As part of this project, I needed devcon.exe and srvany.exe, neither of which are redistributable, so if I wanted to share, I had to find alternatives. Well, I found that Microsoft have made devcon a sample bit of code that, if I read the license correctly, I can redistribute, if I compile it myself and maintain all copyright notices. You can find the original source here. I've fixed it up to compile under my old copy of VS2008 on XP, and it works a treat. I'll package that up some other time if anyone asks. As for srvany, that was a bit harder, but I found an open source reimplementation of it here. This required a fair bit of fixing up to make drop-in compatible with the stock version, but it now is. Again, I'll package up that source when someone asks. The complied binaries for both are naturally in the 7z SFX executable attached. I don't really have the time to support any of these properly, but let me know and I'll do what I can. I just figured it was better to share something rather than nothing. Thanks to you all for the help you unknowingly have been giving me. EDIT: for anyone worried about opening strange EXEs (and well you should!), I've attached the raw 7z archive...though you could just open the exe in 7z if you liked RAMDISK - Gavotte - 1.0.4096.5 - 20081113 - x86.7z RAMDISK - Gavotte - 1.0.4096.5 - 20081113 - x86.exe

Hello all. I've been using this site as a reference for quite some time and figured I should probably give something back. No idea if anyone will find it useful or not, but here it is, regardless. Basically, I've been tweaking away on a final customised XP install so I never have to fiddle with the d**n thing again and when I need it, it'll be ready. To this end, I've done a fair bit of tweaking and integrating, but there were a few things that I didn't spot cropping up anywhere, so here they are. I'll separate them into multiple posts to keep things coherent. Handy tidbit #1 - Complex renaming of the program files directory. The winnt.sif options for program files are deceptively restrictive - if they're invalid, setup will just ignore them and use the defaults. IIRC, they have to be in 8.3 format, and IIRC, can't have subdirectories (can't be too sure as I put this together a couple of months ago, but gist is - it's flaky) However, I found that if you simply update the registry yourself at T-39, then you're fine, as long as you take a couple of precautions as setup.exe's environment won't be refreshed, and scripts started by it will inherit that environment. All you have to do is manually update the variables and you're fine. Here's my detached.cmd @ECHO OFFSetlocal EnableDelayedExpansionecho Detached > %SYSTEMDRIVE%\setupcomplete.logdate /T >> %SYSTEMDRIVE%\setupcomplete.logtime /T >> %SYSTEMDRIVE%\setupcomplete.logset >> %SYSTEMDRIVE%\setupcomplete.logSET val=FOR /F delims^=^"^ tokens^=2 %%i in ('findstr /B "ProgramFilesDir" %SystemRoot%\System32\$WinNT$.inf') DO SET val=%%iECHO Program Files Dir specified as !val! >> %SYSTEMDRIVE%\setupcomplete.logIF NOT "%val%" == "" ( IF "%val:~0,1%" == "\" SET val=%SystemDrive%!val! ECHO Program Files Dir set to !val! >> %SYSTEMDRIVE%\setupcomplete.log REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion /v ProgramFilesDir /t REG_SZ /d "!val!" /f >> %SYSTEMDRIVE%\setupcomplete.log)rem ECHO REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion /v ProgramFilesPath /t REG_EXPAND_SZ /d %%ProgramFiles%% /f >> %SYSTEMDRIVE%\setupcomplete.logSET val=FOR /F delims^=^"^ tokens^=2 %%i in ('findstr /B "CommonProgramFilesDir" %SystemRoot%\System32\$WinNT$.inf') DO SET val=%%iECHO Common Program Files Dir specified as !val! >> %SYSTEMDRIVE%\setupcomplete.logIF NOT "%val%" == "" ( IF "%val:~0,1%" == "\" SET val=%SystemDrive%!val! ECHO Common Program Files Dir set to !val! >> %SYSTEMDRIVE%\setupcomplete.log REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion /v CommonFilesDir /t REG_SZ /d "!val!" /f >> %SYSTEMDRIVE%\setupcomplete.log)set >> %SYSTEMDRIVE%\setupcomplete.logEndLocalEXIT...this parses the local copy of the winnt.sif file and extracts the actual value you specified, and updates the registry with it. The corresponding safety stub in your other scripts is: REM Make sure we're using what the registry says - setup won't pick up changes REM and will pass its environment to child processesFOR /F "delims= tokens=3" %%i in ('reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion /v ProgramFilesDir') DO SET ProgramFiles=%%iFOR /F "delims= tokens=3" %%i in ('reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion /v CommonFilesDir') DO SET CommonProgramFiles=%%i...and that's pretty much it. You will end up with an empty "Program Files" directory that setup creates, but that can be safely deleted whenever you like. All installers will have the correct paths, and scripts (and installers launched from them) will be correct as long as you update the environment as above. Personally, I have mine set to: ProgramFilesDir="\Opt\i386-Win32" CommonProgramFilesDir="\Opt\i386-Win32\Common Files" ...and it all works fine.

Weeeell, seems I've had some partial luck with my experiments that I figured I should share with people on the off-chance they come in useful. I don't expect anyone to consider this a good idea - but I always take being told you can't do something you used to be able to do as a challenge - hence why I stuck at it Basically, Windows quite happily supports running from a directory with any name, as I thought. What fails however is dism.exe and dismhost.exe - these seem to have some horrible bugs forcing you to have a C:\Windows directory. dism.exe has a parameter that lets you specify the windows directory, but in my tests it seems to ignore this. I used my shim to rewrite the command line args being passed to the correct ones and some DISM functionality doesn't even try to use it - it just goes straight for C:\Windows. I tested this using ProcessMonitor with which I watched what was happening during the installation. My set up was preparing my image with a renamed directory and a pre-edited offline registry (as mentioned before, ideally I want to transform a clean image dynamically so it's configurable - but this test is a proof of concept) - the first bit of setup copies this across fine. Setup then tries to fix up the offline registry - but annoyingly does so by - you guessed it - explicitly loading the hives from "c:\Windows\System32\config\". Workaround there is to add a junction back to the desired location and this bit then completes fine. The final phase is to install all the packages etc. and this is where dism's bugs come to the fore - despite the shim you still get the occasional access via C:\Windows - minimal, but still there. Right at the very end however another bug pops up - "CBS", whatever it is, has a bug with paths - my desired path here is "C:\SBin\x86_64-Win64" - however this bit tries "C:\x86_64-Win64". Workaround here is another temporary junction and that gets you past it. I've just let it finish downloading and installing all the updates and I now have a fully working up to date system with my system root in a non-standard location.

Well, I gave up on my attempt (covered in another thread) to make this all configurable using custom autounattend.xml sections and piggybacking off setup.exe (couldn't suppress offline setup's reboot to give it time to do its thing), and decided to go back to modifying the install image directly (dirs and registry). The Program Files twins are quite happy in their new locations, and I've just finished up modifying the system and profiles dirs. I suspect if there's a problem it'll be with the system dir...but given WinPE's happy running from X:\Windows, I have hope it'll work... ...but that fateful install can wait until tomorrow.

Thanks - may go down that route in the future. Was trying to avoid duplicating setup's functionality if possible, but I guess you can't piggyback off of it

Actually, answered my own question having poked around setup with process explorer - what I want to do has to be done in the windowsPE pass as once the first reboot happens it's too late - the new installation is hosting the setup environment. So my options are either: Run an asynchronous command that watches and waits until everything completes, inhibits the reboot, then does it's thing and rebootsExtend the setup proxy I built to run the recovery environment to give me the ability to run commands after setup terminates.The latter sounds more robust than the former...IMHO

I want to do unspeakable things to my custom Windows install without changing the WIM, if possible. To that end, I want to wait until the initial "windowsPE" pass has completed, and only then run my commands. Unfortunately, if I specify RunSynchronous commands they seem to execute at the beginning of the pass, and there's no way to specify I want them at the end. No problem, I thought, I'll put them in the next phase - "offlineServicing". Ah - components I've found only let me specify driverpaths, no custom commands. Given that the driver installers are running, am I correct in assuming I'm going to have to bodge what I want to do into fake driver or some kind of other package? By the time we get to the "specialise" pass, the new windows install is running and it's too late to monkey around with system files and directories that will be in use, so I'm kinda stuck between a rock and a hard place. Just thought I'd ask if I'd missed anything or if the fake driver/custom package route is the best I can hope for?