lightsout

Not that I'm aware of... in fact, I'm certain I've not set that. I think the basic problem is that it isn't replacing all of the system drivers with the ones in the driverpacks. I'm not really sure why this is happening mind. Glad to know it isn't just me though.

Ok, to reply to myself. The driver I want, is already present in CR\6 in Sound Driver Pack B. My actual problem it seems, is that my HWID is in both the CR\4 and CR\6 inf files. The CR\4 driver doesn't work, but the CR\6 one does appear to. Help?! EDIT - If I remove the CR\4 directory, then my system installs ok. Are the CR\4 and CR\6 duplicates? Or is CR\4 a legacy driver?

I'm having problems with the Creative Sound Blaster AudioPCI 128D driver as well. It simply doesn't install, and in device manager I get the exclamation mark with no drivers loaded. A c:\sbpci directory has been created with sblang.dll, sbsetup.ini & sbsetup.exe in it mind. If I then click on "update driver" in device manager, it then does sucessfully install it! Perhaps it may be worth using muiz's driver instead? It does seem to be the same version as the latest one available from Creative - http://ccftp.creative.com/manualdn/Drivers...rvsV5_12_01.exe.

Hey all, Just an odd problem here. I'm using SMS OSD, which is effectively sysprep. My reference system is Nvidia based, and my target systems have been ATi based so far. They've worked fine, the Catalyst Drivers have installed and all is well. When I install it onto my reference system (it has been cleaned first), the system installs fine. During the mini-setup, the system changes resolution to 1280*1024 (native mode of the TFT it is displaying to) and the Windows mini-setup remains in a small box in the centre of the screen. On reboot into Windows proper, it defaults into 640*480 in 4-bit colour!! I can't change the resolution, and reboots don't resolve it. The only way to fix it is to un-install the Nvidia driver, and on reboot it is detected correctly. Now, to my surprise, the nv4_disp.dll in system32 does not match any of the versions in the driverpacks. It is 6.14.10.5673 - which I believe is the default Windows version. In device manager, some of the DLLs the card is using are marked as 6.14.10.8198 which is the latest version provided by the driver packs. The Ti4200 itself is marked as using "Driver Version: 8.1.9.8". What I presume is happening is that as the reference system is Nvidia, some of the "default" Nvidia drivers are being used. While part of the drivers are being updated from the driverpacks, not all of them are (especially nv4_disp.dll). The control panel icon under display -> advanced doesn't appear either, but an un-install of the driver and it does appear. This is all with the latest driverpacks, as of this posting. Ideas? I can post HWIDs if needed. Thanks!

I've not done it, so I'm not sure. Try it and see! My thoughts based on what I've read about this: 1. Newer PCs will work with older HALs, but they don't work as efficiently (e.g. don't take advantage of extra things the newer HALs can do like extra interrupts). 2. Updating HALs using UpdateUPHAL will work, but it is not supported by Microsoft. I could be wrong of course on either count, so if someone reads this and thinks I'm wrong then do post! I'd give it a try and see what happens to be honest!

It looks the same to me in v6.02.1 EDIT - There are 6 .INI files present in the main driver I*.INI - if these are added, then the driver installs ok. Can you add them Bashrat? BIG EDIT - These files are also required: It seems the present of sthda.ini points to the other I*.INI files depending on the HWID. Then the stacgui.cpl, sttray.exe & stlang.dll are required from the contents of the I*.INI files. Thanks!

It depends on your hardware I suppose. For me, most of our computers are new or are about to be replaced anyway. So in device manager under computer, they show "ACPI Uniprocessor PC". If I deploy this image to a dual core machine, then the HAL automatically changes to "ACPI Multiprocessor PC". Basically, if the machines are modern then WinXP can handle it. Anything with a P4 or AthlonXP should fall into this basket. I've found a P3 system here with an older HAL, and it bombs on reboot after the install. The UpdateHAL and UpdateUPHAL look to be for when you deploy from an older machine onto a newer one. I've not gone down this path, although you may need to but only you will know this for sure! This link http://support.microsoft.com/?kbid=309283 maybe useful. In a nutshell though, it is probably best to install your reference system on as an older system as possible. Newer systems can use the older HALs, but the older systems can't use the newer HALs. You can get a script to update the HAL line in the post-install phase depending on the model. You can find it on google somewhere.

I wouldn't add it directly to the registry, I'd let sysprep add it for you to be honest. Especially as what is entered to the registry should have %SystemDrive% prepended to each entry. Your basic sysprep.inf will do the job, but you should really add more stuff to it. Look at the ref.chm & deploy.chm that come with sysprep to see what you can do! SMS OSD will also add some extra enteries for you anyway.... I've booted my reference system off a BartPE CD so I can view the C: drive just after the restore of the WIM image. The sysprep.inf has a lot of extra info in it.

1. It is called "oempnpdriverspath.cmd" and it currently present in the methods_v6026.7z archive within the BASE BTS package. 2. I've not done this, so I'm not really sure. You'd need to copy them to a location, and then update HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\DevicePath so that those locations are included. This is the key which tells Windows uses to search for drivers, and the sysprep.inf enteries are inserted into it. You could modify oempnpdriverspath.cmd to generate a suitable registry entry for you and then use regedit -s to include it. 3. Yes, the driver packs have been plenty sufficient for my needs. If you've got anymore questions, post them here so that they can be recorded for future reference and so people can correct me if necessary.

No, you have to add each individual directory I'm afraid.... the BTS driver packs have a script which does this automatically, I just modified that slightly for my purposes! Or, you can do it by hand. But I would not recommend it. Currently, to update the drivers you need to re-create the whole image. Yes, it is a pain. When Vista comes, it has an updated WIM format that will be editable so you can modify the WIM image (to add drivers) without having to re-build the whole image. You could work around this, say, only include the LAN drivers and have a script that copies the rest from the network during the post-install phase or something like that. That doesn't seem worth it to me, as I'll generally only update the drivers if some new hardware isn't covered.

Bashrat, Indeed, I saw it and eventually the penny dropped. I've even posted in it. Close this topic anyway, probably best everyone using the other thread. Cheers.

Ok, it looks like I worked out how to do it the old fashioned way first! The target I had in mind were the Intel SATA drivers, so I some Intel specific lines to my sysprep.inf: If you look at the .inf files, you'll be able to extract the necessary codes. Imaged my system, and the worked just fine. When sysprep -reseal is run, it builds the rest of the .inf files before adding all the services for each driver.

Well it took me a few minutes to work out what was going on, so I'm just glad I wasn't going mad. These driverpacks are excellent tho!

Bâshrat , Are you sure about this? Looking in the mass storage v602 driver pack I've got, the directory D\M\IN\1 still contains the older 5.1.0.1022 driver. Looking here - http://www.driverpacks.net/Projects//Drive...MassStorage.htm - it seems to suggest they are in the D\M\I\1 directory which they are not. The I\1 & I\2 directories are mentioned twice though, so I think something is a bit broken here. Cheers!

Ah cheers dude! : I suspect it is something to do with method 2, given this thread http://www.msfn.org/board/index.php?showtopic=62501 which we've now both posted in. I've got a machine running a method 2 install right now to give it a test!

One question - what exactly do you mean by this? Expand the mass storage .7z into the $OEM$\$1\D directory?? Cheers!

This tool: http://www.vernalex.com/tools/spdrvscn/ Also does a similar job of setting the DevicePath using a GUI, or commandline.

Hey all, I'm using SMS OSD to deploy WinXP SP2, but that isn't too important. OSD uses sysprep to prepare the image for deployment, so it'd be the same case as using deployed a sysprep image via ghost per example. The problem is, I do have this in my sysprep.inf: And I also have this, which points to BTS' driverpacks: The problem is, when sysprep does the BMSD bit it simply doesn't process the mass storage drivers provided by BTS. So if, like me, you try to install it on a system that doesn't have drivers within Windows (e.g. Intel's AHCI SATA driver) it hangs. All other hardware is detected successfully using BTS' drivers - but the problem here is that it can't boot from the device to scan for the drivers so mass storage drivers are a "special" case. What I want to do, is somehow include the mass storage drivers so when I run sysprep -bmsd that they are also processed so all drivers are available for me. I know I can turn off SATA and run in IDE compat mode, but that isn't the point. One idea I have is to make a copy of Windows which has the mass storage drivers slipstreamed into it, and then image that instead. Another would be to manually add it to sysprep.inf, but I'm not sure how to do that. But if anyone else has any other suggestions, then I'm happy to hear them!! Cheers!

"robocopy" isn't in your path is one problem I suspect. It is provided in the driverpacks in the "files" directory, copy it to %windir%\system32 and try again or something like that.

I think it is related to power management. If Cool'N'Quiet is enabled (minimal power management configured in control panel) then this seems to happen. What happens if you turn off Cool'N'Quiet?

I'm still using method one - which seems to work ok for me. Well, I'm still nervous of the 4096 limit mind! Can you describe exactly what you do to use method 2 with OSD? I can get the LAN drivers into WinPE, but when I tried the mass storage using RISult, every new mass storage driver seems to trigger an error. The first was VMWare SCSI driver, so I modified DOSNET.INF and TXTSETUP.SIF to remove references to it. It then moved to the next driver in line (some VIA one). So I gave up. Or more likely, I'll till the time I actually need to add mass storage drivers!

Looking at Nvidia's release notes for the 81.98 drivers, it doesn't list the GF2 GTS as a supported device. The GF2 MX cards are however. So either need a older driver, or a hacked 81.98??

Yeah, I tried that and it didn't work... (I got the STOP 0x000000bb error) but I found the cause! The system involved uses a Broadcom NIC, and although I did copy the correct *.sys and *.inf file for it, there was a *.sy_ compressed version of the older driver (which RISult did I think) which doesn't work with these NICs. So I had to delete that first, and then it worked. Nice. B) I'd say the only problem I now have is that I'm worried this will happen again in the future. Is there anyway to resolve a clash between the .sy_ and .sys files automatically (or via a script)? Can I make RISult not compress the drivers?

Not sure if I'm missing something, or if it simply not been done yet. I've had a look at BTS, RISult, AutoRIS, etc but I can't find what I want - I want to integrate the mass storage and LAN drivers into a bootable RIS image. I gave RISult a try, and it did do fine with the mass storage drivers (although the integration of the mass storage drivers was done by BTS' scripts) but the LAN drivers did not seem to be slipstreamed. So can this be done? If so, how! Thanks!

Well I thought it may be worth putting this isscript.msi in as well. It seems to want version 9 only, so if this directory doesn't exist: Then it should install the isscript.msi first before installing the CCC. Otherwise it'll fail.