ok thanks when I integrate this KB, it appears in the updates installed (when Windows 7 is installed) I don't think there was an error you must install this KB "online " and do not integrate there are others where the files are not updated by installing this KB? if you could check, I'd would like to know if this is normal or not thanks
About Updates to install and do not integrate you too when you integrate the KB943790, it's not integrated? must install thanks
Yes, its normal that the hotfix does NOT update the system32 files, even if you install it and get no errors Could be a bug or a "on purpose"
The winsxs is where all versions of files are stored. So if you're updating a version of a file that is not actively in use, the one in system32 doesn't get updated until needed - or sometimes doesn't get placed in system32 until an SP upgrade. When you install a KB, it'll update the sxs, then if needed, update the active version. I've seen a lot of posts around here where there is confusion about this (especially related to the USB drivers) and people are assuming that the latest version of any driver should be the one in system32 - which is not always the case. Windows is pretty dynamic about deciding which drivers should be in the sxs and which should be in system32.
In regards to USB, I can understand usbohci.sys, but when it comes to usbehci.sys, usbd.sys, usbport.sys, usbhub.sys, osbuhci.sys and usbccgp.sys, all files which are in use but Windows on a typical Intel machine (AMD may not need usbehci.sys, but can't confirm that?...) anyways, they are 'active' files in the sense that usbehci.sys, usbhub.sys, usbport.sys is used by the Enahnced USB controller (Intel USB 2.0 implementation), usbuhci.sys, usbhub.sys, usbport.sys by the Universal USB controller (the other USB 2.0 implementation), usbccgp.sys by the 'USB composite device' (when certain things are plugged into USB, you are most likely to have at least one of these), and usbd.sys, usbhub.sys by the USB root hubs. Therefore, going by the 'active' file definition, all these files should be updated to the latest relevent version, whether it be GDR or LDR. However, this is NOT the case, some are still using RTM files even though the newer files are available. To me, that is an error. If you install no other USB related update and just install KB2529073, which contains all the files listed above that are 'active', all these should be updated to the GDR version of that update upon next boot. They are not, therefore there is an issue causing this. If the files have not changed, why give them a new version and include them? or at lesat why change the version and include them whereas in other updates the old version number is used when the unchanged files are included... I don't accept this as a 'as design', I see it as a bug! I can see that if something is truly inactive, where the components aren't loaded or the feature is turned off, that the files aren't actively updated till used, but not something which is actively used like the USB drivers. Also, things like pkgmgr.exe, they aren't typically active as they are only used when you need it, so if I tried to run it now it magically updates itself once I already have it open (making it unable to update unless you reboot?!!!)...
Besides the servicing stack file non-updateness, can people find other updates that are non-updating files?
AMD does use usbehci.sys. Anyway, the system doesn't look at the latest version of each binary, it looks at the latest version of each inf file (although there's considerably more logic than just the latest in deciding which), and grabs the binaries that were shipped with that version of each inf file. The issue you're specifically referring to with 2529073 - updates both usb.inf and usbhub.inf. The way this was packaged was with a forced version number update, even if binaries are identical to RTM. When you apply the other fix, it just had usb.inf, so the files that are included in this package have priority over the ones from the previous update - because usb.inf is a higher version. Again, it doesn't matter what version the actual binaries are, just what version the inf is. (also, if an inf is included in an update, it *has* to include all the files referenced in the inf).
Ah ok, what about the servicing stack and the pkgmgr.exe etc files? there are files that aren't updated that are clearly not just file version changes, not only by the date and version of the files, but by the filesize and the fact that the other half of the files have the original dates and versionings...
These ones definitely change in updates, but I believe windows just ignores what version is in system32 for these files, and grabs the correct one directly out of the sxs whenever it needs to load these up. I'm pretty sure this is the case for the servicing stack but I'm not sure about pkgmgr.
I think he may be right, I recall my last integration session glancing at my dism log and thought I saw the winsxs version being used/called on
I was thinking the same thing for a little while... but if that were the case, you could simply copy the files from winsxs over the ones in the system32\drivers folder without worring about pending file operations! however, since these files are open by windows this isn't the case!...
Well, these particular files just don't use the ones in system32 I think. It doesn't make a copy at runtime, it just ignores the system32 version.
burfadel, instead of using /quiet why not use >>log.txt to show what updates installed successfully, otherwise one will not know if a update installed or had an error