Discussion in 'Article Discussion' started by Gareth Halfacree, 14 Jun 2013.
Also affects Windows Server 2012, RT.
It sounds as though the update is compressing archived update files, but the System File Checker (Which uses those files for rollbacks and the like in case something goes wrong) notices the hashes on the files have changed/don't match what it has on record ('cause they're compressed now), throws an error, and carefully restores the files back to the way they were, at which point the compression system notices they're old and uncompressed and compresses them, and the whole cycle begins anew.
Chances are, the patch to the SFC service to enable it to read the compressed files hasn't applied properly, or the SFC service hasn't been restarted (so the in-memory version doesn't have the patch applied). It could also be related to permissions and/or UAC issues (If the compression service and the SFC service are running as different users with different permissions, it could stop one or the other from being able to read/write the files).
The DISM command listed there essentially throws away SFC's list of system files and their hashes, forcing it to start again from scratch and accept the hashes of the (now compressed) files as good.
Of course, this is all speculation on my part, but speaking as a programmer it's the kind of corner-case that can easily turn up if even one little step goes awry.
Is it only a recent thing that Microsoft seem to be botching updates and not bothering to patch other security flaws such as the one reported and published by Tavis Ormandy.
It is worrying when taken in context with providing intelligence agencies with information about bugs before it publicly releases a fix
I had an issue occur on Wednesday after I'd installed 13 Windows Updates where sfc /scannow reported hundreds of errors when I reviewed the CBS.log. I was concerned because I'd just installed a clean copy of Windows 8 Pro on my new i7-4770K build so it didn't make sense that there'd be so many errors unless my SSD was faulty. Even though I subsequently fixed it by running DISM.exe, as suggested in the article, thanks to a fellow forumer's advice, I never did find out what caused it... until now.
Microsoft really should do more testing IMO; it seems more and more issues are cropping up from these updates which are supposed to FIX them not CREATE new ones!!!
It seems Microsoft has never heard of or done regression testing. Needs a better QA team me thinks.
Koola, they've needed that for a number of years, I've lost count of how many updates MS have released that have caused systems to hang or not boot correctly, when previously they have been running fine, resulting in either reinstallation or rollback. I think cutting QA testing in a lot of big companies is a big mistake and pretty much unforgivable for a company of Microsoft's stature.
Agreed. It seems updates to Windows break more often than the updates of cutting-edge distros of Linux. Also, it seems Windows updates more often take up disk space than they free. Their patches seem to be like trying to fix a pipe leak with duct tape, where if they see a little water drip, they just wrap more tape around it. The fix might work but it's not the best approach.
Separate names with a comma.