bigfoot wrote:

There are only x64 beta packs out for win8.

I was going to ask where... guess I skimmed too quickly. Each forum has a BETA post. Awesome thanks!

New Update: I've tried integrating the pack (with those problematic drivers removed) into the folder Windows\inf\amd64 and it seems that when using those drivers (x86 packs) windows 8 BSOD after the initial setup right before OOBE.

Seems like these packs are not fully compatible with Windows 8 (even though I've read on the forum they are...)

Are there beta driver packs out there that are fully compatible with Windows 8? If not, what's the ETA on Win8 compatibility?

FYI It was an HP G62 that gave the BSOD after deployment.

BTW:
1. using the newest stable x86 drivers (Problem may mirror to x64 as well)
2. integrating drivers to both index:1 (PE) and index:2 (Setup)
3. Some boot tests were done on two computers (laptop/desktop) to mostly eliminate hardware-dependence of BSOD

It turns out that C/AMD/1/SB9xx is also causing boot.wim to BSOD. It does work when integrating C/L/M, but that's without the USB folder in C. With the USB folder, SB9xx will cause a BSOD and it will boot fine when its removed.

USBFilter must be conflicting with some USB 3.0 driver.

So, in summary, if you wish to integrate the current version of x86 C/L/M drivers into Windows 8 boot.wim, you'll have to remove Win7/USB/Via/2 and Win7/C/AMD/1/SB9xx.

UPDATE: FOR THE 64 BIT DRIVERS (C/L/M) AND INTEGRATING INTO BOOT.WIM!
I didn't integrate the same two problematic drivers (Win7/C/AMD/1/SB9xx and Win7/USB/Via2) but I also had to delete Win7/C/USB/FTDI. These would not even integrate using DISM, threw an error.

All is well. No BSODs while booting Windows 8 Setup.

Sorry I'm posting this bug here, but I'm sure a dev could expedite it vs. figuring out how to post to the bugtracker for this project.

Anyway, using dism to inject drivers into a boot.wim for Windows 8 (issue on x64 and x86 ). Usually I inject C/L/M, but got a blue screen.

Integrated packs and then folders one by one and it came out to be x86/Win7/USB/Via/2. I don't know about x86/Vista/USB/Via/1 since I deleted that (and the rest of the Vista folders) straightaway.

Cheers.

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 : 1.3.3.70

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:

http://social.technet.microsoft.com/For … 406f096ff/

http://forum.driverpacks.net/viewtopic.php?id=4516

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!

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.

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.

FirstStart.vbs
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
DeleteSelf

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
Tasks.bat
@ECHO OFF

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

:stillcopying

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

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

ping 127.0.0.1 -n 4 > NUL
GOTO stillcopying

:donecopying

rd /s /q "C:\Users\%USERNAME%\AppData\Local\Google\Chrome\User Data\Default"
ping 127.0.0.1 -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

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