Topic: Chipset Pack... Sysprep... Windows PE... Conflicts.... Headache!

First off, I wanted to voice my appreciation for this community and the developers of these packs... You are all seriously a GOD-send!

My issue is when integrating the Windows 7 x64 Chipset Driverpacks into a System Image.
I'm aware of the MANY methods to do this. I'm using Windows 7 and wanted to have the sysprep startup sequence scan for the drivers and install them, but I didn't want them to stick around in the system after the deployment (~4GB).

What I did was just make a subdirectory with all the drivers in: %SYSTEMROOT%\inf\x64 with all the driverpacks extracted since this is the only folder that is RECURSIVELY searched for drivers. Adding a directory to the DriverPath registry key only searches the root folder specified.

Works well. The only downside is a little slowdown of the installing devices sequence, no big deal considering it's all automatic.

Afterwards, a startup VBS scripts performs some operations then calls a BATCH script which deletes this x64 folder (alll occurs on first login), without issues I may add... except for one.

When integrating the Chipset package, along with all the others, on an Intel integrated graphics system, there is a driver conflict. The Intel HD Graphics (on a B940 Laptop and issue was duplicated on a new LucidLogix enabled mobo using Intel HD3000 ie. i7-2600k) always come up with a yellow exclamation mark giving Code 12. I believe it said not enough resources and that it couldn't start. I tried restart, reinstalling, deleting drivers and reinstalling... nothing would work save a reformat.

Now, I came to the conclusion that specifically the Intel folder in the Chipset driver pack caused this issue. I integrated ALL other drivers (including the Chipset Pack without the Intel Folder) and all was nominal, on both systems, including an ASUS laptop using an NVIDIA graphics card (Intel integrated completely disabled, no LucidLogix Virtu).

This issue also crept up when I integrated them into a boot.wim for a WindowsPE image. I just used the Windows 7 SP1 MSDN boot.wim image to integrate drivers with Rt7lite and enable EFI boot and Shift-F10 to get a CMD and use the tools eg. imagex, diskpart. It gave me a bluescreen on bootup and as soon as I just integrated the USB (not full chipset package) along with Mass Storage, LAN, and WLAN... issue was gone! (This was on the ASUS system with NVIDIA graphics).

SO! Just wanted to mention this issue and clear the air for someone who may be in the same predicament. This all came about through MANY images and MANY re-formats to test and isolate the issue.

It probably has to do with the new Intel Management Engine drivers (as I have not imaged in about a year so I've never tried integrating them...), but a more experienced person may have some better insight on this.... (Hint: INSIGHT WELCOMED! lol)

Happy imaging! smile

Last edited by rootMBX (2011-12-25 12:40:59)

Re: Chipset Pack... Sysprep... Windows PE... Conflicts.... Headache!

Sounds like a very similar install method to our SAD2 script here:
Maybe you could contribute/post your code there so we could use it to improve our script also (unless yours is a "trade secret").

Your problem was reported with an earlier DriverPack Chipset but I thought we fixed that.  I myself don't have hardware that supports that dual-hybrid-video...yet.  (I'm building a wish-list for a system upgrade that will incorporate that hybrid graphics on z68 chipset).

If you could tell us which specific driver folders cause the problem (or better yet, the driver files themselves), then we can quickly isolate the problem and issue a fix.

BTW, WTH are you doing posting this on Christmas day!?  Go away and be with your family! wink

Re: Chipset Pack... Sysprep... Windows PE... Conflicts.... Headache!

he actually posted on Christmas eve... but still big_smile

I am surprised the issue persisted once you tried integrating the chipset pack into the Boot Wim.

DP BartPE Tutorial   DP_BASE Tutorial   HWID's Tool     Read BEFORE you post    UserBars!
The DriverPacks, the DP_Base program, and Support Forum are FREE!.

Re: Chipset Pack... Sysprep... Windows PE... Conflicts.... Headache!

The folder is the Intel One in the Chipset Pack... The issue did occur whether or not on the Z68 chipset machine because I did a  PRESYSPREP image and captured and deployed with imagex to a Acer laptop (B940 Sandy Bridge) that just had an integrated Intel graphics chipset, not dual GPU.

The issue persisted in Boot.WIM actually on a third machine... ASUS laptop with Nvidia GTX 460M. The other Acer laptop with integrated graphics could boot the boot.wim WinPE with the intel chipset folder integrated just fine. I believe the same with the Z68... not 100%. FYI The ASUS had an HM55 chipset. The Acer had  a newer HM65.

That's as specific as I could get since I didn't want to try integrating each folder one at a time and deploy an image for each scienario... Don't have the time.

I've actually tried using SAD2 (props to the complex script... can't wait till we have a new NT 6 compatible BASE...), but am not 100% sure what it accomplishes or the specific scenarios it is useful for... DPInst has to be executed manually (script).. and then what? Automatic scanning of all devices? This has to happen upon first login? It'll delete all drivers after completed if KTD not activated? A bit too complicated for me since, at the time, I didn't have as much experience with scripting or coding in general. An explanation would be appreciated.

Nothing special about the scripts I used... Here are the relevant parts:

Tasks.bat is run by FirstStart.vbs. This is to avoid seeing the black cmd window upon first login. FirstStart.vbs is placed in Startup folder of the default profile so it runs everytime a new user first logins and the Tasks.bat is placed one directory up from that to avoid automatic running in the Startup folder. It won't work if either are hidden (tried for purposes of hiding my "revolutionary" scripts).

The vbs actually started off as the one on the IT Bros site that organizes Taskbar Icons on first startup since Windows 7 does not save the configuration through Sysprep, but I have found that the icons and their orientation are kept in tact if you copy the entire folder of the User you customized to the Default profile, manually. I cut that part of the script out ever since that discovery was made. I used to use Windows Enabler to enable the Copy To button under Advanced System Settings -> User Profile -> Settings to copy the customized User to Default user, but manually copying the folder in Explorer copied ALL the files (including taskbar icon orientation) and the sizes of the profiles came out exactly the same.

In fact, most of these techniques/code was just found googling around and modified slightly for my purposes, so I can't take too much credit.

Tasks also does some other stuff like moves Chrome cache to a RAMDisk and creates a junction for that purpose.

Both scripts delete themselves after running, but are still stored in the Default user profile of course so that when a new user is created, they execute upon first login.

Option Explicit

'Run Batch Script

Dim sBatFile
Dim oShell
Dim oFSO
Dim sBatFileShort
Dim objNetwork

Set oShell = CreateObject("WScript.Shell")
Set oFSO = CreateObject("Scripting.FileSystemObject")
Set objNetwork = CreateObject("WScript.Network")

sBatFile = "C:\Users\" & objNetwork.UserName & "\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Tasks.bat"

' just in case there is spaces in the path
sBatFileShort = oFSO.GetFile(sBatFile).ShortPath

' Run the batch file hidden, and let the VBScript wait for the batch file to finish
oShell.Run sBatFileShort, 0, True

'Delete the script

Sub DeleteSelf()       
        Dim objFSO
        'Create a File System Object
        Set objFSO = CreateObject("Scripting.FileSystemObject")
        'Delete the currently executing script
        objFSO.DeleteFile WScript.ScriptFullName
        Set objFSO = Nothing
End Sub

xcopy /yqei "C:\Users\%USERNAME%\AppData\Local\Google\Chrome\User Data\Default" "R:\Program Files\Chrome\%USERNAME%\Default Profile" > NUL


tasklist /fi "imagename eq xcopy.exe" | find /i "xcopy.exe" > NUL

if /i not %ERRORLEVEL%==0 (
goto donecopying

ping -n 4 > NUL
GOTO stillcopying


rd /s /q "C:\Users\%USERNAME%\AppData\Local\Google\Chrome\User Data\Default"
ping -n 4 > NUL
mklink /j "C:\Users\%USERNAME%\AppData\Local\Google\Chrome\User Data\Default" "R:\Program Files\Chrome\%USERNAME%\Default Profile" > NUL

rd /s /q "C:\Windows\inf\x64"

del %0

Last edited by rootMBX (2013-12-20 12:29:47)

Re: Chipset Pack... Sysprep... Windows PE... Conflicts.... Headache!

The issue came back with the Acer on a subsequent reformat without the Chipset/Intel folder... A code 12 on an Intel Integrated Graphics Card.

Not sure what it could be anymore.

Re: Chipset Pack... Sysprep... Windows PE... Conflicts.... Headache!

Well that's disappointing! sad
When you get it up and running, can you post your entire HWID list?

Re: Chipset Pack... Sysprep... Windows PE... Conflicts.... Headache!

Just learned how to Google, apparently...

Issue has come up more than once. All point to the AMD PCI Express Filter Driver for the Northbridge.

Found out after I removed the Driverpacks completely and I still had a Code 12 on the Intel Integrated Graphics. That drove me crazy... The few times that it worked may have been a fluke; windows not scanning that particular driver or installing the proper driver before installing this AMD one, no idea.

Used DISM to remove and found it listed as the following:

Published Name : oem18.inf
Original File Name : atipcie.inf
Inbox : No
Class Name : System
Provider Name : Advanced Micro Devices Inc
Date : 3/10/2010
Version :

Removed it and all is well in Imaging-Land.

Sorry for the confusion. Turns out it was part of the Chipset pack and was moved to a separate driverpack due to this exact same issue... that's probably the problem that was fixed before that mr_smartepants was referring to.

Also, it seems to have been included in the base system image that I used; Windows 7 Ultimate x64 SP1 (MSDN), because it did show up in the DISM driver listing. Otherwise, it was installed through Windows Update (which I kept an eye on the list, so I don't think so...).

SO... I removed the driver from the image as oem18.inf and then didn't include the AMDFilter driverpack and it all works finally!

I also found many other threads referring to the Code 12 error, the AMD 3GIO driver, and the Intel Integrated Graphics all over the internet. The AMD driver is a pain in many situations, it seems.

The threads referring to this issue: … 406f096ff/

BTW what program would you use to enumerate the HWIDs for a Windows PC?

Also... what is LH64A vs W764A? LH = Legacy Hardware...???

Thanks for all the help!

Last edited by rootMBX (2012-01-04 11:31:36)

Re: Chipset Pack... Sysprep... Windows PE... Conflicts.... Headache!

Glad to hear you got it sorted out.  I still don't understand how that one AMD driver can screw up an Intel install. neutral

rootMBX wrote:

BTW what program would you use to enumerate the HWIDs for a Windows PC?

You can use the HWIDs tool linked in my signature.