Topic: [SLVD] Problem with 12.02

Hi guys,
Thanks again for your hard work in creating the driver packs, your efforts are greatly appreciated.

I seem to have found a problem, not certain exactly where it lies. I'm installing Win 7 SP1 (doesn't matter if it's x64 or x32) onto a Dell Optiplex 990 using an automated installation. This problem is not limited to that hardware, though, as it happened at least once under VMWare Player, too. I've added the expanded Mass Storage drivers to the $WinPEDriver$ folder in the root of the boot media (either a DVD or USB thumb drive). The message 'Setup is starting' appears and after a lengthy pause a message box appears with the following text:

'Windows Setup could not install one or more boot-critical drivers. To install Windows, make sure that the drivers are valid, and restart the installation.'

You can click OK, but the installation seems to just stop at that point with no further messages.

When setup stops, I examined setupact.log and the last line contains the error message and the lines before contain messages about loading various OEMxx.INF files:

2012-03-01 21:54:09, Info                         PnPIBS: Installing driver X:\windows\INF\oem23.inf ...
2012-03-01 21:54:09, Info                         PnPIBS: Installing driver X:\windows\INF\oem24.inf ...
2012-03-01 21:59:10, Info       [0x0640ae] IBSLIB PublishMessage: Publishing message [Windows Setup could not install one or more boot-critical drivers. To install Windows, make sure that the drivers are valid, and restart the installation.]

On looking at OEM24.INF I see it is one of the Intel drivers from \All\M\Intel\3 renamed. I removed the 3 folder, and tried again, but then got the same message referring to the INF in \All\M\Intel\4. Removed that folder and the machine installed correctly. I also found that if I changed the BIOS of the machine from the default 'RAID' to ACHI that installation proceeded even with both 3 and 4 folders in place.

An earlier version of my installation disk had an earlier version of the driver pack (sorry not sure which one, but there was only a 1 and a 2 folder under Intel) works fine, too. I'm trying to support the widest range of hardware possible, so don't wish to remove these to sacrifice that support.

The relevant output from the HWID tool is below:

Any ideas or suggestions?
Rod

============
RAID Devices
============
PCI\VEN_8086&DEV_2822&SUBSYS_047E1028&REV_04\3&11583659&0&FA
    Name: Intel(R) Desktop/Workstation/Server Express Chipset SATA RAID Controller
    Hardware ID's:
        PCI\VEN_8086&DEV_2822&SUBSYS_047E1028&REV_04
        PCI\VEN_8086&DEV_2822&SUBSYS_047E1028
        PCI\VEN_8086&DEV_2822&CC_010400
        PCI\VEN_8086&DEV_2822&CC_0104
    Compatible ID's:
        PCI\VEN_8086&DEV_2822&REV_04
        PCI\VEN_8086&DEV_2822
        PCI\VEN_8086&CC_010400
        PCI\VEN_8086&CC_0104
        PCI\VEN_8086
        PCI\CC_010400
        PCI\CC_0104
1 matching device(s) found.

Last edited by Rambo (2012-03-02 15:34:09)

I never know what to put in a signature.

Re: [SLVD] Problem with 12.02

That's an interesting problem and it's one that nobody else has reported.
I'm not certain that there is a problem with dpms itself or the method that you're using them.  So I'll leave the thread here (we might move it to "Universal Imaging" later if it's appropriate).

Your HWID is supported in \All\M\Intel\3\iastor.inf but not folder 4.  So that particular error related to folder 4 is very odd.

In practice, the "RAID" BIOS option should not be enabled unless you actually are running a RAID array.  AHCI is the best option for single drives.

We need to look into this a little deeper, hopefully cdob or one of our other imaging pros will stop by for a chat.

Re: [SLVD] Problem with 12.02

Thanks for the reply. I agree that it seems unusual to set the BIOS to RAID even though there is only one disk, nonetheless that is the way Dell shipped them (we bought eight at once, all the same). Ideally this should work either way.

Looking a little deeper, can you confirm that what happens is that there is a 'simple' match of HWID to string in INF file to determine the driver to use? If that is the case, is this a problem because the IaStor.inf in All\M\Intel\1, 3, and 4 are almost identical and contain essentially the same HWID's? They appear to be just later versions of the same thing and my HWID seems to match all of them...

I don't quite understand how you say my HWID matches 3, but not 4, when to me they look the same! You have way more experience at this than I do, have I missed something? What are the consequences of removing duplicates - all the same hardware should still be supported, shouldn't it?

Regards,
Rod

All\Intel\1\
; **    Filename:  iaStor.INF
; **    Revision:  Version 10.1.0.1008
DiskName                                    = "Intel Rapid Storage Technology Driver"
*PNP0600.DeviceDesc                         = "Intel RAID Controller"
PCI\VEN_8086&DEV_2682&CC_0104.DeviceDesc    = "Intel(R) ESB2 SATA RAID Controller"
PCI\VEN_8086&DEV_27C3&CC_0104.DeviceDesc    = "Intel(R) ICH7R/DH SATA RAID Controller"
PCI\VEN_8086&DEV_27C6&CC_0104.DeviceDesc    = "Intel(R) ICH7MDH SATA RAID Controller"
PCI\VEN_8086&DEV_2822&CC_0104.DeviceDesc    = "Intel(R) Desktop/Workstation/Server Express Chipset SATA RAID Controller"
PCI\VEN_8086&DEV_282A&CC_0104.DeviceDesc    = "Intel(R) Mobile Express Chipset SATA RAID Controller"

All\Intel\3\
; **    Filename:  iaStor.INF
; **    Revision:  Version 10.8.0.1003
DiskName                                    = "Intel Rapid Storage Technology Driver"
*PNP0600.DeviceDesc                         = "Intel RAID Controller"
PCI\VEN_8086&DEV_27C3&CC_0104.DeviceDesc    = "Intel(R) ICH7R/DH SATA RAID Controller"
PCI\VEN_8086&DEV_27C6&CC_0104.DeviceDesc    = "Intel(R) ICH7MDH SATA RAID Controller"
PCI\VEN_8086&DEV_2822&CC_0104.DeviceDesc    = "Intel(R) Desktop/Workstation/Server Express Chipset SATA RAID Controller"
PCI\VEN_8086&DEV_282A&CC_0104.DeviceDesc    = "Intel(R) Mobile Express Chipset SATA RAID Controller"

All\Intel\4\
; **    Filename:  iaStor.INF
; **    Revision:  Version 11.0.0.1032
DiskName                                    = "Intel Rapid Storage Technology Driver"
*PNP0600.DeviceDesc                         = "Intel RAID Controller"
PCI\VEN_8086&DEV_27C3&CC_0104.DeviceDesc    = "Intel(R) ICH7R/DH SATA RAID Controller"
PCI\VEN_8086&DEV_27C6&CC_0104.DeviceDesc    = "Intel(R) ICH7MDH SATA RAID Controller"
PCI\VEN_8086&DEV_2822&CC_0104.DeviceDesc    = "Intel(R) Desktop/Workstation/Server Express Chipset SATA RAID Controller"
PCI\VEN_8086&DEV_282A&CC_0104.DeviceDesc    = "Intel(R) Mobile Express Chipset SATA RAID Controller"

============
RAID Devices
============
PCI\VEN_8086&DEV_2822&SUBSYS_047E1028&REV_04\3&11583659&0&FA
    Name: Intel(R) Desktop/Workstation/Server Express Chipset SATA RAID Controller
    Hardware ID's:
        PCI\VEN_8086&DEV_2822&SUBSYS_047E1028&REV_04
        PCI\VEN_8086&DEV_2822&SUBSYS_047E1028
        PCI\VEN_8086&DEV_2822&CC_010400
        PCI\VEN_8086&DEV_2822&CC_0104
    Compatible ID's:
        PCI\VEN_8086&DEV_2822&REV_04
        PCI\VEN_8086&DEV_2822
        PCI\VEN_8086&CC_010400
        PCI\VEN_8086&CC_0104
        PCI\VEN_8086
        PCI\CC_010400
        PCI\CC_0104
1 matching device(s) found.

I never know what to put in a signature.

Re: [SLVD] Problem with 12.02

Sorry, I got confused.  I was looking at the 64-bit pack which is different than the 32-bit.
Yes, your HWID matches all the above drivers in the folders you mentioned.
What happens is the system will scan the available drivers, then select whichever meets all the below criteria (in this order):
1) Digitally signed
2) Matches the exact HWID
3) Newer than the others
4) Matches a partial HWID

So the only way for you to fix your particular problem is you know for certain that a newer driver doesn't work is to remove that driver from the pack (or don't integrate it).

Re: [SLVD] Problem with 12.02

Thanks,
Switching to 64-bit, then, I see similar behaviour. If I put the entire driver pack into $WinPEDriver$ then I get the 'unable to load boot-critical drivers' message.

I think what is happening is that Windows Setup is getting 'confused' have multiple versions of drivers for the same HWID. Perhaps this is unique to this method of integration rather than using DSIM? This method suits my situation as it is a little quicker/simpler to make quick changes (though I notice you've got some batch files for automating the DISM process).

If I make sure that there's no duplicate drivers/HWIDS by doing the below to the IaStor.Inf in the x64 or x32 driver pack:

All\M\Intel\1
[INTEL_HDC.ntamd64]
%PCI\VEN_8086&DEV_2682&CC_0104.DeviceDesc% = iaStor_Install, PCI\VEN_8086&DEV_2682&CC_0104
;%PCI\VEN_8086&DEV_27C3&CC_0104.DeviceDesc% = iaStor_Install, PCI\VEN_8086&DEV_27C3&CC_0104
;%PCI\VEN_8086&DEV_27C6&CC_0104.DeviceDesc% = iaStor_Install, PCI\VEN_8086&DEV_27C6&CC_0104
;%PCI\VEN_8086&DEV_2822&CC_0104.DeviceDesc% = iaStor_Install, PCI\VEN_8086&DEV_2822&CC_0104
;%PCI\VEN_8086&DEV_282A&CC_0104.DeviceDesc% = iaStor_Install, PCI\VEN_8086&DEV_282A&CC_0104

Then doing the below, depending on version:

x64\All\M\Intel\2
Delete

x64\All\M\Intel\3
Untouched...

x32\All\M\Intel\3
Delete...

x32\All\M\Intel\4
Untouched...

If I've done this correctly, this means that there is no duplicate drivers, but all the same devices are supported - do you agree?

Certainly after doing this, Windows Setup completes successfully on this machine (and in a VM, too) and all drivers appear load correctly.

Regards,
Rod

I never know what to put in a signature.

Re: [SLVD] Problem with 12.02

Hmm, I'll have to take a closer look at the packs contents.

Re: [SLVD] Problem with 12.02

I'd certainly appreciate it if you could do that.

Rod

I never know what to put in a signature.

Re: [SLVD] Problem with 12.02

OK, here's an example breakdown for the dpms 64-bit AHCI Intel drivers. 
Unique HWIDs are in GREEN and duplicated HWIDs are in RED.

x64\All\M\Intel\1\iaAHCI.inf   DriverVer=11/06/2010,10.1.0.1008
PCI\VEN_8086&DEV_2681&CC_0106
PCI\VEN_8086&DEV_27C1&CC_0106
PCI\VEN_8086&DEV_27C5&CC_0106

PCI\VEN_8086&DEV_2821&CC_0106
PCI\VEN_8086&DEV_2829&CC_0106

PCI\VEN_8086&DEV_2922&CC_0106
PCI\VEN_8086&DEV_2929&CC_0106
PCI\VEN_8086&DEV_3A02&CC_0106
PCI\VEN_8086&DEV_3A22&CC_0106
PCI\VEN_8086&DEV_3B29&CC_0106
PCI\VEN_8086&DEV_3B2F&CC_0106
PCI\VEN_8086&DEV_3B22&CC_0106
PCI\VEN_8086&DEV_1C02&CC_0106
PCI\VEN_8086&DEV_1C03&CC_0106

x64\All\M\Intel\2\iaAHCI.inf   DriverVer=10/17/2011,10.8.0.1003
PCI\VEN_8086&DEV_27C1&CC_0106
PCI\VEN_8086&DEV_27C5&CC_0106
PCI\VEN_8086&DEV_2922&CC_0106
PCI\VEN_8086&DEV_2929&CC_0106
PCI\VEN_8086&DEV_3A02&CC_0106
PCI\VEN_8086&DEV_3A22&CC_0106
PCI\VEN_8086&DEV_3B29&CC_0106
PCI\VEN_8086&DEV_3B2F&CC_0106
PCI\VEN_8086&DEV_3B22&CC_0106
PCI\VEN_8086&DEV_1C02&CC_0106
PCI\VEN_8086&DEV_1C03&CC_0106

x64\All\M\Intel\3\iaAHCI.inf   DriverVer=11/29/2011,11.0.0.1032
PCI\VEN_8086&DEV_27C1&CC_0106
PCI\VEN_8086&DEV_27C5&CC_0106
PCI\VEN_8086&DEV_2929&CC_0106
PCI\VEN_8086&DEV_3A02&CC_0106
PCI\VEN_8086&DEV_3A22&CC_0106
PCI\VEN_8086&DEV_3B29&CC_0106
PCI\VEN_8086&DEV_3B2F&CC_0106
PCI\VEN_8086&DEV_3B22&CC_0106
PCI\VEN_8086&DEV_1C02&CC_0106
PCI\VEN_8086&DEV_1C03&CC_0106

PCI\VEN_8086&DEV_1E02&CC_0106
PCI\VEN_8086&DEV_1E03&CC_0106

Now you would think that the logical action would be to remove folder \2 because it's duplicated between folders \1 & \3, BUT...not all the HWIDs in folder \2 are duplicated in the newer folder \3. 
My motherboard has PCI\VEN_8086&DEV_2922&CC_0106 which isn't supported by the newer folder \3.  So my best match is folder \2.  I wouldn't want to be stuck with the older driver if I didn't need to be and I'm not the only one that feels that way.

The 32-bit dpms is similar.

So if you can prove that one folder ON IT'S OWN fails, then we can remove it from the pack.  One of the great things about the DriverPacks is that they are modular and you can add/delete/modify each one to suit your needs.
Looking at the IaStor drivers it's probably perfectly safe to remove the v10.8.0.1003 iastor.inf (and sundry) because it's a 100% duplicate with v11.0.0.1032
I'm sure that more testing is in order though.

*Edit
Oh, and editing the .inf will break driver signing and the Windows setup will use ANY other matching driver as long as it's signed.  That's one of the quirks with driver signing is that setup will always default to a signed driver over any other driver.

*Edit 2
I'll try to confirm your bug on my system using your methods.

Re: [SLVD] Problem with 12.02

Thanks for your work on this - I think the problem is with the iastor.inf files, but not sure...

I'm going to try DSIM to integrate the drivers as they are and see if that resolves the issue. In the end, I'm happy to use that method if it works.

Will update here how I get on.

Rod

I never know what to put in a signature.

Re: [SLVD] Problem with 12.02

Well I just tried a win7 64 bit source on my USB drive with the $WinPEDriver$ at the root containing the 64 bit dpms (untouched) and the pre-setup (up to the drive selection) went without a problem at all.  This is on my main tower (mentioned above).
I'll try again later with the 32 bit flavor.

Re: [SLVD] Problem with 12.02

Here's a great reference from Microsoft regarding loading drivers in an offline image.

Driver Ranking

One of the most common issues in deploying drivers occurs when a driver is successfully imported into the driver store but, after the system is online, Plug and Play finds a higher-ranking driver and installs that driver instead.

The Windows PnP manager ranks the following driver package properties in order of importance:

1. Signing
2. Plug and Play ID match
3. Driver date
4. Driver version
For example, if a device has a better Plug and Play ID match but is unsigned, a signed driver with a compatible ID match takes precedence. In addition, a newer driver can be outranked by an older driver if the older driver has a better Plug and Play ID match or signature.

Re: [SLVD] Problem with 12.02

I love MS documentation, makes what sounds simple very complex, but there's usually good reasons for it that I wouldn't have thought of in a million years. Doesn't surprise me much that this is hard to replicate, remember it doesn't happen on every one of my test boxes and on the ones that it does, changing to ACHI instead of RAID mode in the BIOS 'fixes' it, too.

I've used DISM to add the drivers to my x64 BOOT.WIM (index 2), pointing it to the same source folder as I use for $WinPEDriver$. It integrated 91 drivers without problem and when I run setup from that, it works!

So this problem only happens for drivers loaded via $WinPEDriver$ and then only on quite specific types of hardware. If the DISM method works for x32, too, then I think I'll just do things that way, it's slower doing updates to drivers, but I don't typically have to do that too often.

Since DISM integration of drivers works, this will be my work around. I'm happy to try to help get to the bottom of this further, but it will get a little more difficult as I have to return the machine to my client.

I appreciate your efforts,
Rod

I never know what to put in a signature.

Re: [SLVD] Problem with 12.02

Confirming that the DISM method works for both x32 and x64 bit, but I do get the problem referred to when added via $WinPEDriver$ folder.

I'm going to use DISM for now, at least, until or unless someone finds a solution.

Thanks mr_smarepants for your assistance.

Rod

I never know what to put in a signature.

Re: [SLVD] Problem with 12.02

Please see this reference for further info: http://forum.driverpacks.net/viewtopic.php?id=6169

Using both DISM injected PE drivers as well as $WinPEDriver$ folder WILL cause problems.

Re: [SLVD] Problem with 12.02

Interesting article - I'll read in detail later, but at first glance it does look to explain the possibility of problems.

I certainly agree with minimising the number of injected drivers for several reasons, but this is another one, too.

Really appreciate you remembering this old call and drawing the new information to my attention.

If only I could get service like that for the products I pay for.

Thanks,
Rod

I never know what to put in a signature.