2014-11-30 18:21:32, Info CBS Not able to find package: Package_1_for_KB2889543~31bf3856ad364e35~amd64~~6.3.1.0 from the cached windows update index. [HRESULT = 0x800f090e - CBS_E_EMPTY_PACKAGE_MAPPING_INDEX]
http://support.microsoft.com/kb/2889543
<quote>
Article ID: 2889543 - Last Review: September 24, 2013 - Revision: 2.0
</quote>
Why in the world are you being given such an obsolete update? Did you try doing some kind of cleanup (which would have deleted or at least compressed WinSxS modules)?
To try to find out the state of your Flash* modules please try the following Powershell pipeline. Run it as Administrator: Windows Powershell (e.g. elevated) to try to minimize warning messages.
| PS C:\windows> **dir -Re -Fi "Flash*" | ** **Sort-Object Name, CreationTime | ** <br>ft Length, FullName -AutoSize |
|---|
Note that I am giving the actual command line including the prompt to give the directory level you should start it from. Also, note that even when we specify -AutoSize that the output may be truncated depending on the window size, so please make sure that your window is big enough to capture the full path of the longest name.
For some time I have had the opinion that updates misuse the module timestamp and the results from this output for my case are confirming this in spades. So, I consider just the Length to be the most significant factor in what version a module is. E.g. in particular where the System modules sort for CreationTime bears no resemblance to what version they actually are (according to their Length). Otherwise I was expecting to see the System modules ordered after the SxS copy. YMMV.
Checking System Update Readiness.
(p) CSI Payload Corrupt wow64_adobe-flash-for-windows_31bf3856ad364e35_6.3.9600.16407_none_270c708771a3c5dc\FlashPlayerApp.exe
Repair failed: Missing replacement payload.
(p) CSI Payload Corrupt wow64_adobe-flash-for-windows_31bf3856ad364e35_6.3.9600.16407_none_270c708771a3c5dc\FlashPlayerCPLApp.cpl
Repair failed: Missing replacement payload.
(p) CSI Payload Corrupt wow64_adobe-flash-for-windows_31bf3856ad364e35_6.3.9600.16407_none_270c708771a3c5dc\FlashUtil_ActiveX.dll
Repair failed: Missing replacement payload.
(p) CSI Payload Corrupt amd64_microsoft-windows-dssec_31bf3856ad364e35_6.3.9600.16384_none_4b24378dd07ed912*dssec.dat*
Repair failed: Missing replacement payload.
What is dssec.dat? And again, why are you seeing reports about such ancient (16384) modules? There is something fishy here. Both system versions are the same length? Neither appear in the SxS by those lengths? Weirder still the version that you are having trouble with appears to have been archived recently (length 12 bytes but sorting just before the two system versions.) But all the others appear compressed (length 8489) so we can't use this to check for version. There is no FileVersion for a .dat file anyways and it looks as if LastWriteTime might be a better sort key. Well, at least that gets the version "build" numbers into a logical order. Otherwise the ordering is still inconsistent with my expectation. YMMV
| PS C:\windows> dir -Re -Fi "dssec.dat" | Sort-Object Name, LastWriteTime | ft Length, FullName -AutoSize<br><br><br>Length FullName <br><br>------ -------- <br><br>215943 C:\windows\System32\dssec.dat <br><br>215943 C:\windows\SysWOW64\dssec.dat <br><br> 12 C:\windows\WinSxS\amd64_microsoft-windows-dssec_31bf3856ad364e35_6.3.9600.16384_none_4b24378dd07ed912\dssec.dat <br><br> 12 C:\windows\WinSxS\x86_microsoft-windows-dssec_31bf3856ad364e35_6.3.9600.16384_none_ef059c0a182167dc\dssec.dat <br><br> 8489 C:\windows\WinSxS\amd64_microsoft-windows-dssec_31bf3856ad364e35_6.3.9600.17415_none_4b70d269d045459a\dssec.dat <br><br> 8489 C:\windows\WinSxS\x86_microsoft-windows-dssec_31bf3856ad364e35_6.3.9600.17415_none_ef5236e617e7d464\dssec.dat |
|---|
HTH
Robert