This saying is rarely used correctly. I service my car even though it runs well, I don't wait for it to stuff up before I change the fluids and typical serviceable parts (spark plugs etc). Installing the SP is as much of a preventative measure as this. The case where that term may apply is installing all the hotfixes, internal Microsoft or otherwise (if they are ever released...), sure they may be unnecessary for the most part, but then again, a car enthusiast will tweak the car, use performance parts where possible, and installing these hotfixes is the computer equivalent. The difference is... if it weren't broke, there wouldn't be different file versions to make up hotfixes, updates, and service packs in the first place!
Huh? When installed using the integrated ISO, all copies of usbport.sys are 7601. When a 7600 is updated to 7601 via the update executable, the "base" copies of usbport.sys (found in SxS and the DriverStore) are updated to 7601, but the active copy in drivers is unchanged (I think that's a bug). So, in the case of usbport.sys, it's not a matter of inclusion (b/c it is included in both the executable and the ISO)...
... but I think it is a bug with the executable updater that it fails to update the active copy (while updating the repository copies, whatever good that does...). I've confirmed this problem on both x86-32 and x86-64...
Well for me its the same with a fresh install straight from the Wzor 7601.17514 ISO (supposedly the RTM one). Even though 7601.17514 files are available, only 7600.16385 files are used, and its not only the USB files that are affected. Some drivers are the new ones, others are the old ones even though newer versions are available. I believe Microsoft have truly stuffed up in regards to this. Maybe they realised their mistake and are preparing a fixed build without these stupid mistakes... or at least preparing and testing updates for immediate distribution once SP1 becomes available. Since its supposedly released to manufacturers, changes to the SP1 base code will most likely piss off a lot of companies who have already spend resources on it.
Speaking in the case of usbport.sys, how is that even possible, when there isn't even a 7600 version of usbport.sys install in either system32/drivers or in the repository? AFAICT, there are no 7600 builds of usbport.sys anywhere in the integrated ISO, and in my test install using the integrated 7601 ISO, I can't find any 7600 builds of usbport.sys. Perhaps for other files (I haven't looked at any others aside from usbport.sys, since that's the one you singled out), but I simply don't see any 7600 builds of usbport.sys when using the integrated ISO. Are we talking about the same ISO here? I'm talking about the integrated 7601 ISO from which you do a clean install of Windows, not the ISO that contains the SP1 update for three different microarchitectures.
Be real, why M$ should recomple every single file? And only because of build number change? C'mon, its unnesssasery if file is not chainged.
Thats exactly right, and its not that which is in question. The issue is old files are being utilised when installed with SP1, with the sp1 exe or true original iso, even though there are SP1 builds available! The reason why I used usbport.sys as an example is that is clearly and definitely in error that 6.1.7600.16385 is used, since in the file repository its 6.1.7601.17514 thats present and refuses to install. I totally agree that they shouldn't make new files just to change the build number, and they do not do this! But why should we be stuck with 7600.16385 builds when Microsoft have replaced them with 7601.17514 builds, and the newer builds should be the ones used! It doesn't matter whether its a driver file, DISM, or anything else in the system, if there was a sp1 build made, they made it for a reason. Whehther its a security, compatibility, performance, or bugfix, I would rather have the proper files utilised so I know everything is right, not for some reason have usbport.sys or whatever file it is stuck at the RTM version and be prone to the very fixes that sp1 were meant to fix with the 7601.17514 files that ARE ACTUALLY PART OF THE SERVICE PACK!!! Not having all the proper SP1 files installed when they are meant to be is clearly a critical bug, and although things may seem to work fine, who knows how long it will be before there is a critical error that causes data loss?
Case point, the usbport.sys anomaly: C:\Windows\System32\drivers --> 6.1.7601.17514 C:\Windows\System32\DriverStore\FileRepository\usbport.inf_amd64_neutral_f935002f367d5bb0 --> 6.1.7601.17514 C:\Windows\winsxs\amd64_usbport.inf_31bf3856ad364e35_6.1.7601.17514_none_1be864e21a2d2b97 --> 6.1.7601.17514 Driver files of device states: C:\Windows\system32\drivers --> 6.1.7600.16385 So, work that one out? definitely a bug, one would think its actually 6.1.7601.17514 thats utilised, but how can you be sure? If it is a bug, what else have they stuffed up? are other files really as they are meant to be, or is Windows thinking some other version is installed instead? If installed from an ISO, does that mean things are good despite what might be claimed? Does the sp1 update on an already installed system actually update like it is meant to? How will these version anomalies or incorrect files affect future updates?...
We could discuss this for ever or until M$ officially make statement and release service pack, you would think it was WZT who officially release windows OS people forget this is just a warez group. I do agree normally there releases are the normally real thing but without M$ releases or crc values or file hashes everything is still speculation.
Don't take this off-topic. You may notice that we are not (at least, I am not) questioning the legitimacy or finality of either the executable or the ISO. We are simply investigating what appears to be a bug. What this bug means with respect to the legitimacy or finality of the SP is not under discussion (though, for the record, I never doubted the legitimacy, and as for finality, I highly doubt that MSFT would recall the SP over something as minor as this; if this is a bug, they'll just issue a hotfix to resolve it). I personally want to know the extent and nature of this bug so that I can take it into account when deploying SP1. While it is true that there was some pointless speculation regarding what DISM meant for legitimacy earlier in the thread, ever since the topic moved onto the USB discrepancy, nobody--except you--have made any comments about whether this is "real".
Could you be more specific? What do you mean by "Driver files of device states"? Is that looking at the driver under device manager? If so, are you talking about the actual list of driver files that you get when you click to get more details (which should come from the file itself, and a discrepancy there would be... strange), or the overall version listed by the device manager (where the version comes from a string in an INF file)...
Okay, I see what you mean. If I look at "c:\windows\system32\drivers\usbport.sys" in Explorer, it reports 7601. But the same file listed in the device manager's driver details (where it lists every file used by the driver) says 7600. This is a very fascinating discrepancy... First, the output of sigcheck: Code: C:\>sigcheck -q C:\Windows\system32\drivers\usbport.sys c:\windows\system32\drivers\usbport.sys: Verified: Signed Signing date: 1:37 PM 11/20/2010 Publisher: Microsoft Corporation Description: USB 1.1 & 2.0 Port Driver Product: Microsoft« Windows« Operating System Version: 6.1.7600.16385 File version: 6.1.7600.16385 (win7_rtm.090713-1255) That's interesting, that sigcheck is reporting a file version of 7600 while reporting a signing timestamp of November 2010 (when 17514 was built). The signature time agrees with what Explorer reports, but not the file version. My suspicion at this point is that this is an artifact of caching and memory mapping. When Windows loads a driver file, the file is loaded and mapped into memory. It is possible (though very strange and unusual in this case) for regions of that file in memory to be modified or overwritten. And then if another application accesses the file in a certain way (specifically, if it asks for the file to be mapped into memory), Windows, since it already has a memory-mapped copy of the file, will point the application to that instead of loading it fresh from disk into memory. To confirm this theory, test #1: Code: C:\>strings C:\Windows\system32\drivers\usbport.sys | grep 760 6.1.7601.17514 (win7sp1_rtm.101119-1850) 6.1.7601.17514 So the file really does have a 7601 version string and it does not have a 7600 string. To confirm this theory, test #2: Code: C:\>copy c:\windows\system32\drivers\usbport.sys . 1 file(s) copied. C:\>sigcheck usbport.sys C:\usbport.sys: Verified: Signed Signing date: 1:37 PM 11/20/2010 Publisher: Microsoft Corporation Description: USB 1.1 & 2.0 Port Driver Product: Microsoft« Windows« Operating System Version: 6.1.7601.17514 File version: 6.1.7601.17514 (win7sp1_rtm.101119-1850) So if we make a copy of the file and check that copy (so that we are not checking a copy that is already memory-mapped), we get the results that we expected. So, what does this all mean? Don't always trust the device manager to give you the correct file version string. The file you see really is 7601, even if the device manager somehow thinks it's 7600 (why it's doing that and where that overwrite/alteration of the memory-mapped file came from, I honestly don't know). A fresh install from the ISO is indeed clean and uncorrupt, but an executable upgrade still leaves the active copy unchanged (probably a bug).
As I said, the file itself is fine, it's 7601, and your own post confirmed that. The device manager reports an inaccurate file version (as explained above), but the file itself is correct.
Here me back, after a very very long time. I think within few weeks, when M$ releases official windows 7 sp1 isos on MSDN/Technet area we will see, doing a fresh installation, if the WZOR release is the final and true RTM or a previous stage rtm version. Anyway, even having same issues described few pages ago, I've successfully slipstreamed my own language (italian) into Windows 7 Ultimate x64 SP1 retail ISO (the one coming from WZOR) and everything is working like a charm. I'm very happy about this.