I love Quake / UT Quad-Damage... LOL

that is why i am checking this out...

I need a specific example i can "look" at

There is no I5 folder in mass 805???

You're right. I copied and pasted from an earlier post that was showing the nightly build. I guess my point was to show the identical hardware IDs for two different drivers. Sorry for the confusion.

The issue is that the finisher will run against the location of INF's for driverpacks (C:\D) and miss all the drivers that windows has in it's collection (C:\Windows\inf) by default. And the reason why it chooses the driverpacks version is because it's newer. I think the only real way to accomplish this is to somehow change the version of the original driver to a later date than the one in the driverpacks. Or the other way around. However, I haven't tested this, it's only a theory.

Perhaps an option for the SoFI ini would be to skip driverpacks in favor of the windows driver?

I like your way better also, but my specific problem is:
PCI\VEN_8086&DEV_27C0=C:\D\M\I5\ich7id2.inf
  PCI\VEN_8086&DEV_27C0=C:\D\M\I5\ich7ide.inf
  PCI\VEN_8086&DEV_27C4=C:\D\M\I5\ich7id2.inf
  PCI\VEN_8086&DEV_27C4=C:\D\M\I5\ich7ide.inf
  PCI\VEN_8086&DEV_27DF=C:\D\M\I5\ich7id2.inf
  PCI\VEN_8086&DEV_27DF=C:\D\M\I5\ich7ide.inf

id2's will lockup the 620s. An install from the CD will pick the right driver, but after imaging XP will grab the wrong one. Can you think of another way to "prioritize" the ide.inf's to prevent the lock ups? I would prefer to live my life w/ out sysprep.

PNF's made simple:
It's a "catalog cache" of the currently available drivers, a table of contents if you will.
windows will check the PNF files first before doing a full blown search or the hardware wizard
if you are old enough you may remember window 98 say building a driver information database I belive this is an extention of that...
this is a speed increase for finding drivers for new hardware  (and possably input reduction)

when you prepare your image don't let the finisher run... !

this will leave the drivers in place and ready to go
(make pnf has been done and so has the PnP search path in the registry)

Run the finisher at deployment on the target machine

this will install any required control panels or other required software
and then remove the driverpacks and clean up reg entries ect...

old method
I used to do this manually after checking device manager...
and then make "per machine type" image if i had some identical machines.

a better idea is to
simply set a runonceex or guirunonce command...
copy the DPINST.exe and DPInst.xml files to the \D\ folder
(they are in the  dp_base\bin\wnt5_x86-32  folder)

1) call dpinst.exe /c /s /sh
2) call the finisher

since most imaging software do compression creating the image haveing the packs extracted is NBD.

You could use the Stand Alone Drivers (SAD) platform feature of base.
This will be a far superior way to do this...
We are still in beta testing on this feature though.
and it has a few rough edges still - but not for long!
(i am going to rename SAD to SoFI  Software First Installer... )

SOLVED! An associate here at work was able to narrow down the problem to the ich7id2.inf file. This file causes the GX620 to crash on boot; the file, ich7ide.inf, is the one that is needed by this chipset. The fix is to not run the makePNF command. For some reason this will cause windows to grab the wrong driver. ...or at least that's in layman's terms.

I am running into the same problem with a GX620 on my XP image that I built in late August on DP 8.05 and the packs available at the time.  I build the image in VMware from install media integrated with the DriverPacks.   I don't however use sysprep.  I simply set the IDE interface to Standard IDE and the HAL as ACPI.  I also build a PIC HAL image for older PCs.   I boot right from the restored image, wait for keyboard and mouse detection and proceed to answer any prompts that might come up for undetected hadware.  It's a beautiful thing. 

What impact would disabling makePNF have on the image booting for the first time on a target PC and how would I go about disabling it?

Best regards to the DP team,
-felipe

I'm not running it either cause I have heard some people having issues with it. Thanks for letting us know.

sysprep has been running for over 3 hours and it looks like there's no end in sight

3 possible reasons:

1. one of your HWID is wrong
2. one or your INF path or filename is wrong
3. There is an HWID duplicated in your sysprep.inf For example nvidia nForce4 has 2 flavor of the same driver one for intel one for AMD. You can only use one of the INF in the sysprep.inf because the driver share the same HWIDs and the sys file name is identical. So they overwrite eachothers.

Same thing happens for intel iastor.inf, intel has different drivers but they all use the same inf file name. So the last one specified in your sysprep.inf overwrite the previous ones...That's why OfflineSyprep is way better, it only inject the drivers you need so no conflicting driver!

You must verify every lines and make sure they are valid. Take notes that when we update the mass storage pack you must reverify all your paths since they can change.

[SysprepMassStorage]
  ;Intel IDE Controllers (ICH7 to ICH10)
  PCI\VEN_8086&DEV_2680=C:\D\M\I5\ESB2id2.inf 
  PCI\VEN_8086&DEV_2680=C:\D\M\I5\ESB2ide.inf 
  PCI\VEN_8086&DEV_269E=C:\D\M\I5\ESB2id2.inf 
  PCI\VEN_8086&DEV_269E=C:\D\M\I5\ESB2ide.inf 
  PCI\VEN_8086&DEV_27C0=C:\D\M\I5\ich7id2.inf 
  PCI\VEN_8086&DEV_27C0=C:\D\M\I5\ich7ide.inf 
  PCI\VEN_8086&DEV_27C4=C:\D\M\I5\ich7id2.inf 
  PCI\VEN_8086&DEV_27C4=C:\D\M\I5\ich7ide.inf 
  PCI\VEN_8086&DEV_27DF=C:\D\M\I5\ich7id2.inf 
  PCI\VEN_8086&DEV_27DF=C:\D\M\I5\ich7ide.inf 
  PCI\VEN_8086&DEV_2820=C:\D\M\I5\ich8id2.inf 
  PCI\VEN_8086&DEV_2820=C:\D\M\I5\ich8ide.inf 
  PCI\VEN_8086&DEV_2821=C:\D\M\I5\ich8ahci.inf 
  PCI\VEN_8086&DEV_2824=C:\D\M\I5\ich8ahci.inf 
  PCI\VEN_8086&DEV_2825=C:\D\M\I5\ich8id2.inf 
  PCI\VEN_8086&DEV_2825=C:\D\M\I5\ich8ide.inf 
  PCI\VEN_8086&DEV_2828=C:\D\M\I5\ich8id2.inf 
  PCI\VEN_8086&DEV_2828=C:\D\M\I5\ich8ide.inf 
  PCI\VEN_8086&DEV_2829=C:\D\M\I5\ich8ahci.inf 
  PCI\VEN_8086&DEV_2850=C:\D\M\I5\ich8id2.inf 
  PCI\VEN_8086&DEV_2850=C:\D\M\I5\ich8ide.inf 
  PCI\VEN_8086&DEV_2920=C:\D\M\I5\ich9id2.inf 
  PCI\VEN_8086&DEV_2920=C:\D\M\I5\ich9ide.inf 
  PCI\VEN_8086&DEV_2921=C:\D\M\I5\ich9id2.inf 
  PCI\VEN_8086&DEV_2921=C:\D\M\I5\ich9ide.inf 
  PCI\VEN_8086&DEV_2922=C:\D\M\I5\ich9ahci.inf 
  PCI\VEN_8086&DEV_2923=C:\D\M\I5\ich9ahci.inf 
  PCI\VEN_8086&DEV_2926=C:\D\M\I5\ich9id2.inf 
  PCI\VEN_8086&DEV_2926=C:\D\M\I5\ich9ide.inf 
  PCI\VEN_8086&DEV_2928=C:\D\M\I5\ich9id2.inf 
  PCI\VEN_8086&DEV_2928=C:\D\M\I5\ich9ide.inf 
  PCI\VEN_8086&DEV_292D=C:\D\M\I5\ich9id2.inf 
  PCI\VEN_8086&DEV_292D=C:\D\M\I5\ich9ide.inf 
  PCI\VEN_8086&DEV_3A00=C:\D\M\I5\ichaid2.inf 
  PCI\VEN_8086&DEV_3A00=C:\D\M\I5\ichaide.inf 
  PCI\VEN_8086&DEV_3A06=C:\D\M\I5\ichaid2.inf 
  PCI\VEN_8086&DEV_3A06=C:\D\M\I5\ichaide.inf 
  PCI\VEN_8086&DEV_3A20=C:\D\M\I5\ichaid2.inf 
  PCI\VEN_8086&DEV_3A20=C:\D\M\I5\ichaide.inf 
  PCI\VEN_8086&DEV_3A26=C:\D\M\I5\ichaid2.inf 
  PCI\VEN_8086&DEV_3A26=C:\D\M\I5\ichaide.inf

I also suggest you use the latest chipset pack:
http://driverpacks.sytes.net/driverpack … 32_810D.7z

Well, the latest build of the mass storage DP /w these drivers added to sysprep.inf is yielding the exact same problem. where the PC freezes after sysprep runs. Am I looking in the right place?
Thanks,

Thanks for the all your help I'm still working on a couple of your suggestions. My problem now is I've setup everything Kickarse has suggested (minus the sysprep driver scanner ....I'll get to it though) and sysprep has been running for over 3 hours and it looks like there's no end in sight. Also, are there any good fixes to accept the driver warning messages while sysprep is running? I have the driver policy set to ignore, but it's not really ignoring everything.

btw. Do you guys do contract work?
Thanks,