I couldn't reproduce the problem...

Integrated latest mass storage DP using latest DP Base in unmodified MSDN XP Pro SP3, left default Base options- second method, KTD disabled and Text mode checked. Tested on Dell laptop with Intel ICH7M in AHCI mode.

Used latest WinSetupFromUSB to put everything on a USB disk. Program modifies only, in regards to Bâshrat the Sneaky driver packs, presetup.cmd and path to OEM folder in it to reflect directory structure changes, e.g. \OEM -->\WINSETUP\XPpSP3\OEM

Thought presetup.cmd design might have changed and I missed that, but that's not the case. Since the first version I make sure the program is aware of sources with Bâshrat the Sneaky driver packs integrated.

Text mode used iastor7, GUI mode found iastor in C:\D\M\I7 and installed it automatically, no prompts or anything wrong.

Please ignore the quoted statement above about DP, this issue reminded of a similar one with DPMS, which makes use of Bâshrat the Sneaky mass storage DP and DriverPack_MassStorage_wnt5_x86-32.ini:

Anyway, if xp_user is interested we can troubleshoot it further, and thanks again for all your work.

Sorry to raise the topic. Was going to ask similar question if anyone observed this behavior as I don't have a test machine to confirm my expectations.
I believe the issue is that I3 and I4 do not have iastor renamed to iastor78 and iastor86 respectively, whereas in txtsetup.sif the renamed files are used.

When during Text mode Setup detects lets say PCI\VEN_8086&DEV_3A23&CC_0106="iastor86", it will create a service with the same name, put the HWID with the service name in HKLM\SYSTEM\ControlSet001\Control\CriticalDeviceDatabase\ and copy the sys file (iastor86.sys) as this driver is critical.
This doesn't relate to GUI mode enumeration and searching for correct driver.

During GUI mode Setup will pick the inf file from \D\M\I4 and install the driver, creating another service, iastor this time, which will use iastor.sys from the same folder.
Is the above scenario correct?

I read that the reason I3 and I4 to have iastor not renamed is possible issues with driver signing:
http://forum.driverpacks.net/viewtopic. … 041#p28041

Would running 2 instances of the very same driver cause any problems, or renaming iastor in I3 and I4 is preferable?

I am creating a small batch file to allow easy change IDE->AHCI and moving around Intel boards using I1-I4 HWIDs. Renamed iastor and changed infs in I3-4 as well, but needed additional information and tests before make it public:

I wish browsers had "unique" or "the very best", alongside bookmarks/favorites lol

Heh, nice one smile

All the best and thanks again for the warm welcome smile

Wow, thank you, that's more than welcome, appreciate it smile

What about the riddle, how do you know?


In order to resolve some issues with unattended setup from USB, a fake Setup + presetup.cmd seem to be the best option for now.
Asking you for permission to include and use Setup.exe and WatchDriverSigningPolicy.exe from Bâshrat the Sneaky pack with WinSetupFromUSB, would you mind?

Thanks in advance.

Found an interesting tool from Microsoft, which may be handy- Pnpids.exe. Extracts HWIDs off single or multiple INF files to a text file.
Couldn't test it further, as it seems to run on Win2000 only.

Direct download:
http://download.microsoft.com/download/ … X86_EN.exe

I am using the posted from Dietmar ntdetect.com, what _exactly_ it does/does not I don't think is published, at least it helps when USB bus is reset, windows not to lose connection to the USB disk.
It cures most of the 0x7B BSODs when starting from USB.
http://www.911cd.net/forums//index.php? … 1&st=0
http://www.msfn.org/board/0x0000007B-Bl … ntry738009

In my case it had nothing to do with mass storage pack. Even if booting PE from the CD, with USB disk was attached resulted in 7B. I just didn't expect USB disk to affect it, and blamed the last changed thing- mass storage pack.
Remove USB disk- boots OK, add it, replace ntdetect.com on the CD- boots OK.
Start from the USB disk- 7B, replace ntdetect.com - OK.
Just another silly BIOS.

The interesting part was that 7B usually means inaccessible _BOOT_ device, and the USB disk was not such.

Similar issue- boot XP setup from USB. On most systems if you don't have the driver for SATA controller, it simply won't show the disks attached to it.
However, on some systems it will bluescreen 7B, even with the other ntdetect.com. Add the needed driver for SATA, even though booting from USB stick/disk- no more 7B.

Sorry for the late reply, board didn't send me email for the reply.

Ohh bugger smile

It bluescreens because of the USB disk connected, no matter if you boot PE from USB or the CD.
Putting the modified NTDETECT.COM on the USB disk and boot from it- no BSOD. May try to put it on the CD too, curious what would happen.

This is something new to me, 0x7B is not inaccessible _BOOT_ device only. Other storage controllers are also playing role.
Similar issues had people, when booting XP Setup from USB, even with the modified NTDETECT.COM, but missing or something wrong with the drivers for their SATA/SCSI controler.

edit: yep, with the modified NTDETECT.COM it started fine from CD too, with USB disk connected.

original topic title was
BSOD 0x7B using UBCD4Win and 8.05 mass storage DP on VIA P4M266A m/b

Getting 0x0000007B on Asus P4VP-MX motherboard with VT8235 south bridge.
DP base is the latest as well as the mass storage pack- 8.05.

Here is some Hardware IDs, pulled them from the installed a while ago XP, which had mass storage pack version 7.12 integrated. It used videX32.sys.
Added at the bottom a few IDs as reported by Device manager.

PCI Devices 
PCI\VEN_1106&DEV_0571&SUBSYS_80A11043&REV_06\2&EBB567F&0&89 : VIA Bus Master IDE Controller - 0571
PCI\VEN_1106&DEV_3038&SUBSYS_80A11043&REV_80\2&EBB567F&0&80 : VIA Rev 5 or later USB Universal Host Controller
PCI\VEN_1106&DEV_3038&SUBSYS_80A11043&REV_80\2&EBB567F&0&81 : VIA Rev 5 or later USB Universal Host Controller
PCI\VEN_1106&DEV_3038&SUBSYS_80A11043&REV_80\2&EBB567F&0&82 : VIA Rev 5 or later USB Universal Host Controller
PCI\VEN_1106&DEV_3059&SUBSYS_810F1043&REV_50\2&EBB567F&0&8D : Multimedia Audio Controller
PCI\VEN_1106&DEV_3065&SUBSYS_80FF1043&REV_74\2&EBB567F&0&90 : VIA Rhine II Fast Ethernet Adapter #2
PCI\VEN_1106&DEV_3104&SUBSYS_80A11043&REV_82\2&EBB567F&0&83 : VIA USB Enhanced Host Controller
PCI\VEN_1106&DEV_3148&SUBSYS_00000000&REV_00\2&EBB567F&0&00 : VIA Standard Host Bridge
PCI\VEN_1106&DEV_3177&SUBSYS_00000000&REV_00\2&EBB567F&0&88 : VIA Standard PCI to ISA Bridge
PCI\VEN_1106&DEV_B091&SUBSYS_00000000&REV_00\2&EBB567F&0&08 : VIA CPU to AGP Controller
PCI\VEN_5333&DEV_8D04&SUBSYS_807B1043&REV_00\3&8A00C89&0&0008: Video Controller (VGA Compatible)
PCI_HAL\PNP0A03\0                                           : PCI bus
12 matching device(s) found.
USB Devices 
USB\ROOT_HUB\3&1BA3757E&0                                   : USB Root Hub
USB\ROOT_HUB\3&2E5D2623&0                                   : USB Root Hub
USB\ROOT_HUB\3&8E9C4D9&0                                    : USB Root Hub
USB\ROOT_HUB20\3&3456F08&0                                  : USB Root Hub
USB\VID_046D&PID_C016\4&263E72A6&0&2                        : USB Human Interface Device
USB\VID_05E3&PID_0702\4&E55CC72&0&3                         : USB Mass Storage Device
7 matching device(s) found.
Input Devices 
HID\VID_046D&PID_C016\5&24C1E5AE&0&0000                     : HID-compliant mouse
1 matching device(s) found.
ACPI Devices 
ROOT\ACPI_HAL\0000                                          : Standard PC
1 matching device(s) found.

Hardware IDs:
Compatible IDs:
Matching ID:

I see PCI\VEN_1106&DEV_0571 matches VIAIDE in txtsetup.sif, but why the BSOD?
I tried to comment out all relevant entries in txtsetup.sif about VIAIDE, hoping that it will use PCIIDE instead, but BSOD 7B again.
Tried from CD and USB boot- same result. As far as I remember I had no issues with BartPE disks months ago on thise machines, when mass storage pack was 7.something.

Or is it another driver which causing the BSOD?

Galapo wrote:
ilko wrote:

Not quite sure if you can deploy the image and make the new contents visible to PE and OFSP without restart, but should be doable.

Might depend on the imaging software used perhaps. I use DriveSnapshot myself and can run OSP after imaging without a reboot..

Just tested with Paragon HD manager 8.0 SE, which I think is still available with free registration- deployed image and everything showed up without restart.

@DeTard- I agree, since you put that much effort and it works, why starting something new...

I am curious for comments on the legal matter for using NTLDR from x64 smile

When you launch Sysprep from OFSP, choose to restart PC on completion.
In this case start PE in RAM, run OFSP, remove the CD/USB and go on the next PC. Or make 10 copies of that CD as long as you have the proper license from MS smile
BTW runing Syspep doen't take that much time if bmsd is not used as you know.
Not quite sure if you can deploy the image and make the new contents visible to PE and OFSP without restart, but should be doable.

OFSP comes handy when you have to maintain many different types of hardware, on which making a good sysprep.inf takes too much time.
Or if you have already your generic image, and lets say buy a new hardware, or replace a motherboard with different one.
Imagine a PC field technician, who has to reinstall client's PCs, all them different and is paid per job. With OFSP you can do that in 15 mins.

If you have a limited number of hardware, then the old sysprep way should be sufficient.

I hope that gives you clearer picture about the differencies, may be it will suit your needs. I am done with the presentation, back to NTLDR smile


You deploy your image using some program anyway.
Instead of that program, you deploy your image from PE, and run OFSP right after deploying. Reboot the PC and let Sysperp finish it's work. No need of extra steps after mini-setup.

Typical scenario:
generic installation- syspep- imaging- deploying on target- mini setup

With OFSP:
installation- imaging- deploying on target- OFSP- mini setup

Run OfflineSysPrep(OFSP) from PE disk packed with a generic image (not sysprep-ed) on the computer, being deployed. Deploy your generic image first, then run OFSP.
HAL could be detected and changed, no need to change it during mini-setup.
Mass storage drivers could be detected and injected.
The PE disk in this scenario gives you freedom to deploy that image on almost any type of machines.

AFAIK there is no other tool of this sort, which can change between *incompatible* HALs.
I.e. change from Standard to Uni or Multiprocessor.

If I recall correctly image with Uni HAL, deployed on Multi machine is autodetected and changed by Windows, and vice versa.
Have a look here too:
http://forum.driverpacks.net/viewtopic. … 481#p12481

And list of compatibles:

How many HALs you have to support?

Nope, forgot about them smile
Will do it tomorrow, too late here.

Just tried it with NTLDR from i386 SP3 and x64 SP2, switched to standard HAL and added /detecthal- no result, neither error messages, nor HAL changed.

I put NTLDR from SP3 on the same virtual machine, where x64 NTLDR was used. No NTFS.SYS errors :S
If the same NTLDR is used for a first boot after injecting drivers it fails. x64 sSPx ones do not.
As you know in my previous tests similar happened when drivers were enabled one by one, using XP SP2 NTLDR.
So it must matter windows to write all the registry keys for the new drivers. But I'd rather not dig that deep again, for me is enough that we have the needed file in a public available download.

As for the legal side- isn't it the same story when using Setupldr.bin and ramdisk.sys from 2k3 for SDI/ISO in RAM boot, or the modified ntdetect.com?
I haven't seen in MSFN or 911cd that it violates licensing, which of course doesn't necessarily means that it does not smile
This is not something I am good at, let someone else comment it.

geo411m wrote:

For anyone who is interested, the memory limit has been fixed with SP3. Now we don't have to worry about licence violation.


SP3 didn't help here- NTLDR is changed, same size but different contents. Are you sure you were testing with more than 80 drivers injected?

However, here is the good news- NTLDR from XP x64 SP1 and the same from x64 SP2 DOES work- no limit reached.
Injected 125 drivers from latest mass storage driver pack + the Microsoft's IDE drivers, using latest OfflineSysPrep.
No TAGs used, NTDETECT.COM is the regular from SP2 i386.
Tested on VMware, VirtualBox 1.6, Gigabyte 965p- DS3P with C2D 4300+2GB RAM and to push it a bit on old Celeron 1,7GHz machine with 128MB RAM. Success on all of them, no issues using x64 NTLDR on machine, not compatible with 64bit instructions.
Change NTLDR back to XP SP2 or SP3 one- the known NTFS.SYS error.
Many thanks for the clue, I had forgotten an old goal, now it's accomplished.

Million thanks to Galapo for his fast updates and implementations of all the crazy ideas and suggestions smile
Not at least- many thanks to the DriverPacks team- brilliant project.


Hi, first of all- great site, great project and exceptional work on these driver packs, respect smile

I was looking for ages for a script or a way to automate sysprep mass storage section, using MS DP, even started doing it by hand, a post in 911cd.net showed me this thread, great job smile

JakeLD wrote:

...Is there any way to update the HAL after running sysprep ???

I tried with the boot.ini options and it didnt work at all.

Hi, what options did you use in boot.ini?
I have successfully switched between all possible HALs (incl. standard), on the vary same installation, transferred on 5 different type machines, including old P233 board, using the boot.ini options as described here:
http://www.microsoft.com/technet/sysint … otini.mspx


[boot loader]
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Standard PC" /fastdetect /KERNEL=Ntoskrnl.exe /hal=Halstd.dll
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Compaq SystemPro" /fastdetect /KERNEL=Ntoskrnl.exe /hal=Halsp.dll
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Advanced Configuration and Power Interface (ACPI) PC" /fastdetect /KERNEL=Ntoskrnl.exe /hal=Halacpi.dll
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="ACPI Uniprocessor PC" /fastdetect /KERNEL=Ntoskrnl.exe /hal=Halaacpi.dll
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="ACPI Multiprocessor PC" /fastdetect /KERNEL=Ntkrnlmp.exe /hal=Halmacpi.dll

Get the needed files from SP2.CAB, rename hal.dll to halstd.dll and put them in SYSTEM32 folder. When switching HALs first run must be in SAFE MODE, or it hangs.

About the sysprep masstorage pack- I have also encountered the same infinite loop, haven't had time recently to dig deeper what was happening.

AFAIK what sysprep does with the mass storage section is to add the HID in HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\CriticalDeviceDatabase  with the relevant service, copy the files needed and install the service itself. My point is that once this is achieved, these entries can be exported and imported in a generic installation with the needed files copied, thus next sysprep could be without the mass storage section. I know it may take long to collect all bits and pieces, but once this is done, the settings will be somehow "universal", and could be used pretty easy to prepare a generic installation to become "universal", even without using sysprep.