You're misunderstanding the problem. The file fnsh_log.cmd is no longer used since version 6.08 of the DriverPack Sound B! It's only used in versions before that. That's why I've been asking where you've referenced it. And that's why I've now suggested to rebuild your uwxpcd as the easier way to fix this problem.

1) It's not referenced in the GUIRunOnce section of the winnt.sif file.
2) You're absolutely positive that you're not using RunOnceEx.
3) You're not using anything such as WPI or XPlode to install applications or whatever other tasks.
4) It's not referenced in the batch file you're using for cleanup.

BUT it has to be referenced SOMEWHERE. You must be overseeing something. The easiest solution in this case (since you cannot find the reference), is to rebuild your installation CD/DVD. Then the problem should vanish automatically.

Is the fnsh_log.cmd referenced insice your batch file (XPSP2+_Nettoie.cmd)?

I've contacted the author of WPI (Kelsenellenvian) and he's solve the problem. The bug that prevented the DriverPacks Finisher from doing its work properly will be solved in WPI 5.5, which will be online in a couple of days, he has told me.

930

(4 replies, posted in Feature Requests)

If I have to use multiple servers, then I also have to code a reliable syncing mechanism - or at least USE one. That'd be yet another task. Plus I cannot oversee the reliablity of those servers, nor the speed. This doesn't make me change my view, I'm sorry.

Grrr unbelievable! Are you also using RunOnceEx for something? Or anything else to install applications, apply registry tweaks... ?

932

(9 replies, posted in Feature Requests)

Save this as copyI368.au3 and compile it with AutoIt 3 (http://www.autoitscript.com/). Now you'll have copyI386.exe. You can of course name it whatever you want. Also add it to GUIRunOnce/RunOnceEx/XPlode/WPI to execute it, or whatever you're using of course.

local $possibleDriveletters[24] = ["c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m", "n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z"]
local $set_driveLetter

; find drive letter
for $i=0 to uBound($possibleDriveletters)-1
	if fileExists($possibleDriveletters[$i] & ":\I386") then
		$set_driveLetter = $possibleDriveletters[$i] & ":"
		exitLoop
	endIf
next

; copy I386\* directory to %systemroot%\source\I386\*
dirCopy($set_driveLetter & "\I386", @windowsDir & "\source\I386")

; update the 
regWrite("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion", "SourcePath", "REG_SZ", @windowsDir & "\source\I386")
regWrite("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup", "SourcePath", "REG_SZ", @windowsDir & "\source")

That should do the job!

933

(4 replies, posted in Feature Requests)

It's too much work for now. We'd need a very powerful server attached to a huge bandwidth internet connection (VERY costly) and it's far from easy to maintain such a system in a reliable way. I think you can imagine the costs of that would prevent me from keeping it donationware only. It'd become payware: it's not doable to keep this alive without bankrupting me. And I don't think many of you would be willing to pay for this, would you?

934

(13 replies, posted in Feature Requests)

Sorry for the late reply!

You'd like to use method 2 when you're NOT using RIS? But what installation would you be using then? A regular CD/DVD installation or would it rather be a sysprep-based image installation?

Sorry for the late reply.

I'm afraid I don't completely understand your first feature request:

slipstreaming an old slipstreamed folder is sure at 100%?
if so no prob at all, but if can produce some error, why not add a "use this folder for the process:_______ " ?

ISO creation has been requested already, but what do you mean with this:

with a gift like "include this folder in the iso image" and "folder name" was perfect, i think (at the moment tongue)

? And more specificly: what would be the use of having such an option?

At this point, I will assume that you first install the image and then boot it. But first I need to know HOW this image is created. I have never had the ability to work with an OPK deployment system, since that's only available for the big companies (i.e. those with enough money), afaik at least. I cannot access the documentation about OPK, since it's preserved for those who have licensed it.
So my questions are:
1) Are drivers (and application setups for that matter) included in the image, or are they installed from a share, or are they downloaded from a share by WinPE and then inserted to the installed image?
2) Can you use WinPE to insert files into the installed image?
3) How and when is the installation of device drivers?
4) The HAL is automatically set to the correct one?

937

(14 replies, posted in DriverPack Graphics)

I have updated the WDM driver included in ATI's 6.09 Catalyst (the .1074 version) in the new DriverPack Graphics A indeed. So don't worry, it's updated wink

Well, then the best solution is clear. You should use the latest DriverPack Chipset, but remove the ich7* files, the ich4core.* and the 945.* files.

Then copy the same files from DriverPack Chipset 6.05 and ALSO copy the ich2br.* files. That should be the work-around that allows you to install on the Dell GX520 flawlessly and at the same time keep the highest compatilibity with all other chipset devices as possible.

Let me know if this works!

OH

You're trying to install the drivers on Windows Server 2003. I had not noticed that earlier. Well, then the drivers don't get installed because they simply do not support Windows Server 2003. I'm very sorry, but then I can't help you wink That's the consequence of using modern multimedia targeted hardware in combination with a server OS. I strongly advice you to use Windows XP SP2 instead, if you want to get it working.

Please post your winnt.sif. You've still got an old entry in it, somehow.

Yes, that's what I thought the cause would be. But it'd be useful if you could post your svcpack.inf, just to confirm that.

942

(6 replies, posted in DriverPack Graphics)

Helmi wrote:
Bâshrat the Sneaky wrote:
Helmi wrote:

Don't forget to include the WDMs this time! wink smile

I only forgot the WDM driver in the old Catalyst 6.5 driver in DriverPack Graphics B! wink And no, I won't forget it again.

But if you see this thread (http://forum.driverpacks.net/viewtopic.php?id=651), how do you explain the missing and outdated files in DriverPack Graphics A I encountered?

I did not however try whether they install correctly since I don't have the proper card in my test machine...

I've not posted a detailed explanation in that topic, I'm sure that you'll agree with me after reading it.

943

(14 replies, posted in DriverPack Graphics)

1) Added the 6.5 WDM driver to D\G\A\6 in DriverPack Graphics B.
2) The WDM driver is missing in Catalyst 6.9 (the WDM_SP directory in the driver, that is), I'll keep on using the one from Catalyst 6.6, since that's the latest version in which it was included (although it's the same driver as the on in Catalyst 6.5, it has not been updated since 2004!). The WDM driver in the directory AVS_T200 is however still included in Catalyst 6.9, so I will keep on updating that driver.
3) I HAVE included the latest AVS_T200 WDM driver in DriverPack Graphics A 6.09.

Conclusion: one WDM driver was missing, NONE were outdated.

Well, please verify that your ISP doesn't obligate you to use a proxy. I really think that'd be the cause. Or perhaps there's STILL a firewall that's blocking internet access.

Nope that just won't work. That's a limitation of this method. You're the first one in at least the past year to complain about this, which reflects the amount of people who actually use that feature. You can enable it again if you slipstream the DriverPacks using method 1, then the original setup will be restored.

The work-around you're suggesting won't work - too bad but that would be too easy wink

Perhaps driverpacks.net was down at the time of testing? Does the UpdateChecker work now?

melombar and [dk], what are your locales (Windows XP languages)?

Please enable debug mode in the DriverPacks Finisher by adding the following line to the first section of DPsFnshr.ini:

[Settings]
debug = true

And now run it again. Then post here your DPsFnshr.log.

It *must* be something specific on your systems, since it's working fine for hundreds of other users.

Yep, the updated DriverPack CPU will solve your problem!

That's not your slipstream log. I need the DPs_BASE.log of the time that you actually SLIPSTREAMED the DriverPacks. May I ask you to slipstream again with the exact same settings? (The slipstreamed and edited files will be deleted, the original files will be restored.)

Did you slipstream DriverPack Sound A?