Search options

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:
http://www.datafilehost.com/download-a548acb9.html

Heh, nice one

All the best and thanks again for the warm welcome

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.

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
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

ilko

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:
http://support.microsoft.com/kb/309283

How many HALs you have to support?

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
This is not something I am good at, let someone else comment it.