Potential bug of either W7T, or DISM

[RicaNeaga]

I can't reply to a closed thread, so I'm trying to elucidate a potential (unresolved) problem of your app.

I can confirm that in the 51 beta build of 1.3.0 the cosmetic problem of the Intel chipset drivers beeing displayed as only x64 ones was resolved. However, this doesn't assure me that the real problem is fixed.

The real problem was the drivers were slipstreamed (maybe it was because of DISM fault) as x64 only, so in a x86 environment they weren't recognised by the 7 OS, and weren't associated with the proper hardware (Microsoft 2006 drivers were the newest for at least 6 Intel chipset HWIDs).

So, can you confirm that this glitch was also resolved? I'll also retest it on a live x86 Intel-based system probably on tuesday.

Also, another 2 Marvell AHCI and one AMD IDE drivers that are mixed ones (x86&x64) are seen as only x64. You can see that here and here, and can find those drivers here.

[Legolash2o]

I can't reply to a closed thread, so I'm trying to elucidate a potential (unresolved) problem of your app.

I can confirm that in the 51 beta build of 1.3.0 the cosmetic problem of the Intel chipset drivers beeing displayed as only x64 ones was resolved. However, this doesn't assure me that the real problem is fixed.

The real problem was the drivers were slipstreamed (maybe it was because of DISM fault) as x64 only, so in a x86 environment they weren't recognised by the 7 OS, and weren't associated with the proper hardware (Microsoft 2006 drivers were the newest for at least 6 Intel chipset HWIDs).

So, can you confirm that this glitch was also resolved? I'll also retest it on a live x86 Intel-based system probably on tuesday.

Seem's like it's a problem with dism, just to check are you using VirtualBox, VirtualPC, VMWare, etc.. to test if your drivers are integrated?

Also, another 2 Marvell AHCI and one AMD IDE drivers that are mixed ones (x86&x64) are seen as only x64. You can see that here and here, and can find those drivers here.

Fixed...

Edited October 16, 2011 by Legolash2o

[RicaNeaga]

Seem's like it's a problem with dism, just to check are you using VirtualBox, VirtualPC, VMWare, etc.. to test if your drivers are integrated?

Nope, live system. I'll reply on this matter on tuesday, when I'l make another disk with at least version 51 beta. Hope you'll also have some time to investigate it further until then.

And sorry I haven't mentioned it before, ALOT of features work more than ok in W7T, version 51 looks to me more of a close-to-final version Except Unattended Creator, of course

[Legolash2o]

What's wrong with the Unattended Creator lol?

[RicaNeaga]

Can't auto-Select Language, Locale and Keyboard Locale, and also can't leave the serial blank. AND, most important, its interface isn't sexy

LE: Really a joke last one :grin:

Edited October 16, 2011 by RicaNeaga

[Legolash2o]

Why would you want to leave the serial key blank? just dont tick it lol.

[RicaNeaga]

Unfortunately the bug is still present in version 52 of your app. And I repeat, 90% probably a DISM bug.

I don' think it's system/configuration specific - the version 50 was the best version so far that recognized drivers that would not be integrated properly. Version 52 only masks this; for example I remember that the USB drivers for Intel chipsets were integrated fine, weren't red marked by your app (and also considered x86 ok by DISM).

I dunno how I can help you further. I'm sure 100% that integrating those chipset drivers for another windows and another Intel configuration will give the same results for an x86 environment

[Legolash2o]

You don't seem to be getting the point that the column in the list that says that's it's either x86, x64 or Mix is just for show, W7T does not even look at that information when integrating, i'll have a look at my code and report back later on

EDIT: Is the problem just USB drivers? can you upload or link to some usb drivers for me to test please?

EDIT: When you click prompt drivers in options does it show your drivers as integrated in the list?

Edited October 19, 2011 by Legolash2o

[RicaNeaga]

1. I understand that now they are just for show, but in version 50 they showed what drivers would be integrated wrong by DISM. It really did.

2. The only drivers that are integrating ok from the 9.2.3.1022 version of chipset Intel drivers in a x86 environment are the USB drivers. AND in version 50 they WEREN't red marked. If this doesn't mean anything for the way DISM sees things - you know better.

3. It's only happening in a x86 environment. I haven't had such problems in a x64 environment, but I'll check when I'll have the time.

4. The drivers were integrated through your app, but probably were marked as only x64 by DISM. Or I don't have an explanation for why this is happening.

5. You can find ALL the chipset drivers here - please download version 9.2.3.1022.

Hope my feedback help and hope you'll sort this out. It's a very important bug. I'll be back later for other info.

[Legolash2o]

So if you integrate x86 drivers into and x86 image they don't work when using x64 OS as the current OS...

[RicaNeaga]

Nope, if you install a x86 os with x86 drivers integrated in a x86 os, you're in trouble if you have a Intel chipset for the machine you're installing the os to.

If you install a x64 os with x64 drivers integrated in a x64 os, everything it's ok.

The problem is how DISM (probably) sees mixed x86/x64 Intel chipset drivers - as only x64 ones. Or it isn't integrating them as it should.

Edited October 19, 2011 by RicaNeaga

[Legolash2o]

So its just the mixed ones it's affecting?

[RicaNeaga]

Yep, and only Intel.

I'll try again next week on another system (last time I used an old laptop, now going to try on a Sandy Bridge desktop), again with a x86 version of windows, and report back if the same thing happened with the Intel chipset drivers.

[crashfly]

Yep, and only Intel.

I'll try again next week on another system (last time I used an old laptop, now going to try on a Sandy Bridge desktop), again with a x86 version of windows, and report back if the same thing happened with the Intel chipset drivers.

You could always just use the driverpacks like I do. There they have x86 and x64 both separate so you do not have a "mixed" issue.

[RicaNeaga]

Ok, I found out what was the trouble. So...

If I installed only 7 without any drivers pre-slipstreamed, and then installed the official Intel chipset driver from its .exe, it didn't installed for this old laptop any drivers besides an AHCI one, that was later updated by the official RST.

So, Intel preffers windows 7 to use its native Microsoft drivers for this old Intel configuration. However, in the chipset unpacked drivers, there is a windows 7 folder (named WIN7) that doesn't include any updates for the chipset drivers of my laptop, but there is also a universal folder (named All) thet contains drivers for xp and vista mainly, and if I point the driver update option to the All folder, the drivers are updated to these xp/vista versions.

Same thing happens if I slipstream the All folder - the Microsoft drivers are updated by vista/xp ones. So there isn't any problem with DISM or W7T.

In conclusion, I wasn't the only one to have a bad thinking - the guys at driverpacks are also in the same situation. They shouldn't make combined packs of drivers for vista and 7, because there are some manufacturers like Intel that prefers to have a very different approach regarding vista and 7 (in this case, chipset drivers, the WIN7 folder is 7 only, and All is for vista and older operating systems),

I'll soon make a thread with the revised & sorted Windows 7 only specific drivers... to give an alternative is unfortunately is the only solution to the stubbornness of the guys from driverpacks, that continue to consider 7 and vista as the same os.

[Legolash2o]

Glad to know, thanks