Bâshrat the Sneaky

You cannot simply put it that way... they both have their own conditions before they get executed. But I do have found the error... take a look: IF NOT EXIST %C%CR GOTO DPSA2 IF EXIST %D%ha10kx2k.sys ( IF EXIST %D%ha20x2k.sys ( IF EXIST %C%CR\1\Ctzapxx.ini ( EXPAND -R %C%CR\1\*.* %C%CR ... COPY /Y %C%\CR\1\common\i386\CtPanel.exe %S% > NUL START %C%CR\1\CTZAPXX.exe /S =====> GOTO DPSA2 <===== ) ) IF EXIST %C%CR\2\Ctzapxx.ini ( EXPAND -R %C%CR\2\*.* %C%CR ... COPY /Y %C%\CR\2\common\i386\CtPanel.exe %S% > NUL START %C%CR\2\CTZAPXX.exe /S ) ) Check the marked statement: that one was missing and therefore the second one was being executed after the first one. Your problem should be solved now. The updated DriverPacks BASE should be online within hours.

Glad it's solved Topic closed.

Erm? If you delete the files => no more drivers will be found and installed automatically! I think you've still misunderstood that...

Ehm... First of all, the DriverPacks are not built for Windows Server 2003, as I've said numerous times. I *do* have modified the scripts so they can work with Windows Server 2003, though. Secondly: it should work just fine with Windows Server 2003, CERTAINLY the slipstreaming; IF there are any problems, they should be related to incompatible drivers and such. I'm confident YOU are doing something wrong, though I'm not entirely sure of that, of course P.S.: this is NOT an attack towards you, it's just for your own interest

Fixed in DriverPacks BASE V6.03.1 (to be released within hours). Topic closed.

Request implemented, topic closed.

If you want to keep these drivers available AFTER setup (so that if you add new hardware later on, that the drivers will still be available for installation), you can NOT delete them, if you do so, Windows will search these folders for drivers and will fail to find anything. Windows will indeed search these folders by default when new hardware has been added to the system. You won't have to use the 'advanced' option anymore (which was the option that enabled you to select (manually) additional folders where Windows should look for drivers). This indeed enables a post-install unattended driver installation.

And I can imagine it will take even much longer on slower systems. That's why first copying the files and then let Windows search them, might be faster after all!

You're very right. The problem is I cannot remove the non-X-Fi driver (you could call it the 'old Audigy driver'), since it supports some devices the (new) X-Fi driver doesn't. That's why it's installing both on your system. Though it should only install 'the best driver'. Very odd... Could you please attach your %SystemRoot%\setupapi.log?

Ehm... sttray.exe has to be SOMEWHERE! I've set it to copy to both system32 and the folder in the %programfiles% folder. I think you won't care for those few additional files on your HDD P.S.: you may need another reboot before the driver will be fully working.

Ehm... AFAIK that's how it SHOULD work. KB888111 shouldn't get slipstreamed when used with Windows Server 2003!

Of course that's also possible. To achieve it, run the DriverPacks BASE and choose method 1. Then move the contents (not the folder itself) of the UWXPCD_ROOT to a temporary folder (C:\dps_m1). Then slipstream the DriverPacks for real, but now use method 2. After that it's easy: just move the files from C:\dps_m1\DPfiles (move the 'D' folder) into your UWXPCD (into your OEM folder (result: OEM\D)) and then alter the presetup.cmd: %CDDRIVE%\OEM\bin\SetDevicePath.exe %CDDRIVE%\OEM\D That's it. Added to the list of informative topics.

You've been messing with your cmd.exe settings. Your system automatically changes the default current directory or something like that. Are you using an XPized system?

Please attach your dosnet.inf file!

Then I'm very confident that this is not being caused by a script of the DriverPacks BASE, but by some script you've added yourself.

Exactly my point for asking what the use of the request would be!

The cause for that error should probably be searched on the scripts that you've used to slipstream the DriverPacks into the UBCD, since the DriverPacks BASE only works for Windows 2000, XP and multiboot discs so far.

Request implemented in DriverPack Sound A V6.03 (to be released tomorrow). Topic closed.

Yes, already implemented in DriverPack Sound A V6.03 (should be released tomorrow). Topic closed.

You should be able to install Windows XP onto that mass storage controller even without my DriverPacks or any other drivers slipstreamed: during textmode setup it will be used as a generic PATA controller. I also think the cause for this error should be searched somewhere else, in a hardware failure or something alike.

May I ask what the use for that would be?

The DriverPacks are packages that contain 3rd party drivers. Therefore the DriverPacks cannot be signed themselves, but the drivers they contain can. I try to use as many signed drivers as possible: IF signed drivers are available, they ARE being used!

Just copy the driver's .inf file to $OEM$\$$\inf and the .sys file to $OEM$\$$\system32 and it should get recognized automatically, during and after setup! OR Create any folder on your HDD, for example C:\Windows\myDrivers\ and add it to the DevicePath regkey (google for it). Windows XP will now automatically search this folder for drivers when new hardware is found!

Request implemented, topic closed.

Very strange: there is no reference to this file in the driver's .inf file! Added the file in V6.03 of DriverPack Sound B (which is about to be released). Topic closed.