Update KB3000850 fails to install

1216015  C:\WINDOWS\WinSxS\wow64_adobe-flash-for-windows_31bf3856ad364e35_6.3.9600.16407_none_270c708771a3c5dc\Flash.ocx

1863328  C:\WINDOWS\WinSxS\amd64_adobe-flash-for-windows_31bf3856ad364e35_6.3.9600.16407_none_1cb7c6353d4303e1\Flash.ocx

40214    C:\WINDOWS\WinSxS\amd64_adobe-flash-for-windows_31bf3856ad364e35_6.3.9600.16407_none_1cb7c6353d4303e1\FlashUtil_ActiveX.dll

595283   C:\WINDOWS\WinSxS\wow64_adobe-flash-for-windows_31bf3856ad364e35_6.3.9600.16407_none_270c708771a3c5dc\FlashUtil_ActiveX.exe

228016   C:\WINDOWS\WinSxS\amd64_adobe-flash-for-windows_31bf3856ad364e35_6.3.9600.16407_none_1cb7c6353d4303e1\FlashUtil_ActiveX.exe

The dssec.dat results:

Length FullName

---

215943 C:\WINDOWS\System32\dssec.dat

215943 C:\WINDOWS\SysWOW64\dssec.dat

215943 C:\WINDOWS\WinSxS\amd64_microsoft-windows-dssec_31bf3856ad364e35_6.3.9600.17415_none_4b70d269d045459a\dssec.dat

215943 C:\WINDOWS\WinSxS\x86_microsoft-windows-dssec_31bf3856ad364e35_6.3.9600.17415_none_ef5236e617e7d464\dssec.dat

215943 C:\WINDOWS\WinSxS\x86_microsoft-windows-dssec_31bf3856ad364e35_6.3.9600.16384_none_ef059c0a182167dc\dssec.dat

  8489 C:\WINDOWS\WinSxS\amd64_microsoft-windows-dssec_31bf3856ad364e35_6.3.9600.16384_none_4b24378dd07ed912\dssec.dat

Good work.   So now you can see what the problem is, although I still don't understand why DISM is not sorting it out for you:  all of those "missing payloads" that were being wanted are either compressed or missing entirely.   So presumably they have to be either decompressed (somehow) or uncompressed copies of the same things downloaded from somewhere and installed (somehow). 

Did you see SuWii's good work figuring out how to do that for a similar circumstance?

http://answers.microsoft.com/en-us/windows/forum/windows8_1-windows_update/windows-81-store-error-0x80070002-comprehensive/2b0ed3e1-1835-4517-97dd-0a7abb6ef74c?page=3

If I had been thinking we could have reduced the output by including that 16407 build version term in the search filter (though then we would have missed being able to check on the versions that you have active in the System directories).  In fact, I don't have anything like that.  So maybe we are trying to repair some things which could be removed and thereby fix the discrepancies that way?

FWIW  here is a filter which I think would find your Flash modules but in my case just finds some directories where there are some manifests for other updates with the same build number.

HTH

Robert

Fixed wrong URL after Richard pointed out my error.

Hi Robert,

Thanks again for your help. Here are the results of that command:

PS C:\WINDOWS> dir -Re -Fi "*16407*" | Where-Object -FilterScript {!$_.FullName.EndsWith(".manifest")} | Sort-Object Name, LastWriteTime | ft Length, FullName -AutoSize

dir : Access to the path 'C:\WINDOWS\System32\LogFiles\WMI\RtBackup' is denied.

At line:1 char:1

• dir -Re -Fi "*16407*" | Where-Object -FilterScript {!$_.FullName.EndsWith(".mani ...

    + CategoryInfo          : PermissionDenied: (C:\WINDOWS\Syst...es\WMI\RtBackup:String) [Get-ChildItem], UnauthorizedAccessException

    + FullyQualifiedErrorId : DirUnauthorizedAccessError,Microsoft.PowerShell.Commands.GetChildItemCommand

Length FullName

       C:\WINDOWS\assembly\NativeImages_v4.0.30319_32\System.Reac207edc4d#\777b416407de8291e1685a4d815e5b57

       C:\WINDOWS\WinSxS\amd64_adobe-flash-for-windows_31bf3856ad364e35_6.3.9600.16407_none_1cb7c6353d4303e1

       C:\WINDOWS\WinSxS\amd64_intelpep.inf_31bf3856ad364e35_6.3.9600.16407_none_b5bc98d7fccb5ce6

       C:\WINDOWS\WinSxS\amd64_microsoft-windows-a..atibility-assistant_31bf3856ad364e35_6.3.9600.16407_none_24de6842f6da7242

       C:\WINDOWS\WinSxS\amd64_microsoft-windows-a..bility-assistant-ui_31bf3856ad364e35_6.3.9600.16407_none_39de10a89282150d

       C:\WINDOWS\WinSxS\amd64_microsoft-windows-a..ence-infrastructure_31bf3856ad364e35_6.3.9600.16407_none_c628e5ed206d46db

       C:\WINDOWS\WinSxS\amd64_microsoft-windows-appx-deployment-client_31bf3856ad364e35_6.3.9600.16407_none_a6f9b19bae09dffb

       C:\WINDOWS\WinSxS\amd64_microsoft-windows-dui70_31bf3856ad364e35_6.3.9600.16407_none_48cc91ffd1ce370f

       C:\WINDOWS\WinSxS\amd64_microsoft-windows-e..host-shellnamespace_31bf3856ad364e35_6.3.9600.16407_none_95b2639d38eb8fd8

       C:\WINDOWS\WinSxS\amd64_microsoft-windows-e..namespace.resources_31bf3856ad364e35_6.3.9600.16407_en-gb_8e36f83f43c7bbec

       C:\WINDOWS\WinSxS\amd64_microsoft-windows-e..riseclientsync-host_31bf3856ad364e35_6.3.9600.16407_none_bf2b5d1a4a48280a

       C:\WINDOWS\WinSxS\amd64_microsoft-windows-globalization_31bf3856ad364e35_6.3.9600.16407_none_042b8cd1b2a4e905

       C:\WINDOWS\WinSxS\amd64_microsoft-windows-mediaviewer.resources_31bf3856ad364e35_6.3.9600.16407_en-gb_f468723d2ca10172

       C:\WINDOWS\WinSxS\amd64_microsoft-windows-oobe-machine-plugins_31bf3856ad364e35_6.3.9600.16407_none_c04e1573dae506d4

       C:\WINDOWS\WinSxS\amd64_microsoft-windows-performancetoolsgui_31bf3856ad364e35_6.3.9600.16407_none_8d21a05a74a76028

       C:\WINDOWS\WinSxS\amd64_microsoft-windows-psmcoreserver_31bf3856ad364e35_6.3.9600.16407_none_9be9460656382b1e

       C:\WINDOWS\WinSxS\amd64_microsoft-windows-s..client-ui.resources_31bf3856ad364e35_6.3.9600.16407_en-gb_ccf92227d6e4beac

       C:\WINDOWS\WinSxS\amd64_microsoft-windows-s..on-onlineid-runtime_31bf3856ad364e35_6.3.9600.16407_none_39a0d3389005d9f3

       C:\WINDOWS\WinSxS\amd64_microsoft-windows-settingsync_31bf3856ad364e35_6.3.9600.16407_none_8232a0bccde86f49

       C:\WINDOWS\WinSxS\amd64_microsoft-windows-twinapi_31bf3856ad364e35_6.3.9600.16407_none_ac7511533a51dff8

       C:\WINDOWS\WinSxS\amd64_microsoft-windows-twinui.resources_31bf3856ad364e35_6.3.9600.16407_en-gb_183bd1ec7a3afca0

       C:\WINDOWS\WinSxS\amd64_wdma_bt.inf.resources_31bf3856ad364e35_6.3.9600.16384_en-us_8bbc16407af64369

       C:\WINDOWS\WinSxS\amd64_windows-id-connecte..t-provider-wlidprov_31bf3856ad364e35_6.3.9600.16407_none_3099d640567975ca

       C:\WINDOWS\WinSxS\Temp\InFlight\214f9309b787cf0102000000a00c280a\wow64_adobe-flash-for-windows_31bf3856ad364e35_6.3.9600.16407_none_270c708771a3c5dc

       C:\WINDOWS\WinSxS\wow64_adobe-flash-for-windows_31bf3856ad364e35_6.3.9600.16407_none_270c708771a3c5dc

       C:\WINDOWS\WinSxS\wow64_microsoft-windows-a..ence-infrastructure_31bf3856ad364e35_6.3.9600.16407_none_d07d903f54ce08d6

       C:\WINDOWS\WinSxS\wow64_microsoft-windows-appx-deployment-client_31bf3856ad364e35_6.3.9600.16407_none_b14e5bede26aa1f6

       C:\WINDOWS\WinSxS\wow64_microsoft-windows-e..host-shellnamespace_31bf3856ad364e35_6.3.9600.16407_none_a0070def6d4c51d3

       C:\WINDOWS\WinSxS\wow64_microsoft-windows-globalization_31bf3856ad364e35_6.3.9600.16407_none_0e803723e705ab00

       C:\WINDOWS\WinSxS\wow64_microsoft-windows-performancetoolsgui_31bf3856ad364e35_6.3.9600.16407_none_97764aaca9082223

       C:\WINDOWS\WinSxS\wow64_microsoft-windows-s..on-onlineid-runtime_31bf3856ad364e35_6.3.9600.16407_none_43f57d8ac4669bee

       C:\WINDOWS\WinSxS\wow64_microsoft-windows-twinapi_31bf3856ad364e35_6.3.9600.16407_none_b6c9bba56eb2a1f3

       C:\WINDOWS\WinSxS\wow64_microsoft-windows-twinui.resources_31bf3856ad364e35_6.3.9600.16407_en-gb_22907c3eae9bbe9b

       C:\WINDOWS\WinSxS\wow64_windows-id-connecte..t-provider-wlidprov_31bf3856ad364e35_6.3.9600.16407_none_3aee80928ada37c5

       C:\WINDOWS\WinSxS\x86_microsoft-windows-a..bility-assistant-ui_31bf3856ad364e35_6.3.9600.16407_none_ddbf7524da24a3d7

       C:\WINDOWS\WinSxS\x86_microsoft-windows-dui70_31bf3856ad364e35_6.3.9600.16407_none_ecadf67c1970c5d9

       C:\WINDOWS\WinSxS\x86_microsoft-windows-settingsync_31bf3856ad364e35_6.3.9600.16407_none_26140539158afe13

I think the link you provided for Suwii's problem is actually for this page but I did a search and found that page. Suwii is definitely more technically knowledgeable than myself but it seems that was a permissions problem.

Regards,

Richard

Here are the results of that command:

PS C:\WINDOWS> dir -Re -Fi "*16407*" | Where-Object -FilterScript {!$_.FullName.EndsWith(".manifest")} | Sort-Object Name, LastWriteTime | ft Length, FullName -AutoSize

Interesting!  It isn't doing what I expected it to.  Back to the drawing board.  I was thinking we were doing the equivalent of a  dir/a/b/s  *16407*   which would find some modules which happened to have that string in their path and then since I saw some ending with .manifest I didn't want to show those.  But evidently Powershell is just stopping when it finds a path with that pattern in it.  Otherwise where are the Flash* modules that we saw before?  Also, no Length fields were reported in what your search found.

Has your WinSxS been cleaned up now so that you don't have any more of those?  E.g., is the DISM still reporting the same errors?

Just to make sure that I'm not missing something by using Powershell please try this cmd window pipeline instead.  It will show only file names but when I do it I get no files (the first stage proves that the .manifest are files but I am stripping them by the second stage.)  Note that the last (unwritten, fourth) "stage" of this pipeline is manual:  Paste the output into a Notepad window to examine it--easier than trying to do that there than in a cmd window regardless of its buffer size.

And again, in retrospect I realize that I could have given you a Powershell equivalent which eliminated the directories first too.  Sorry about that.

I think the link you provided for Suwii's problem is actually for this page but I did a search and found that page. Suwii is definitely more technically knowledgeable than myself but it seems that was a permissions problem.

Good grief.  I have never done that before.  Oops.  Thanks.  I'll fix that.  What I was hoping you would notice is the technique which was used to resolve the errors which DISM reported.  E.g. find a source of the missing modules, somehow, somewhere and install it so that it can be referenced by DISM's /source: operand.  But maybe WU has beaten us to that goal and already fixed those problems.

What's next?   ; )

HTH

Robert

Hi Robert,

I tried the DISM command again, same errors.

I also tried the command:

C:\Windows>dir/a-d/b/s *16407* | find /i /v ".manifest" | clip

but got the following error:

dir/a-d/b/s : The term 'dir/a-d/b/s' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

At line:1 char:1

• dir/a-d/b/s *16407* | find /i /v ".manifest" | clip

    + CategoryInfo          : ObjectNotFound: (dir/a-d/b/s:String) [], CommandNotFoundException

    + FullyQualifiedErrorId : CommandNotFoundException

I haven't used the dir command since something like 1990 (when things were way simpler) but I added a space so it was like:

C:\Windows>dir /a-d/b/s *16407* | find /i /v ".manifest" | clip

but then got the following error:

dir : Cannot find path 'C:\a-d\b\s' because it does not exist.

At line:1 char:1

• dir /a-d/b/s *16407* | find /i /v ".manifest" | clip

    + CategoryInfo          : ObjectNotFound: (C:\a-d\b\s:String) [Get-ChildItem], ItemNotFoundException

    + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand

FIND: Parameter format not correct

It's probably a command syntax error, right?

Regards,

Richard

probably a command syntax error, right?

Yes.  Sorry.   By "cmd line pipeline" I was imagining you would know to start it in a cmd window (not a Powershell window).   ; )

But actually you don't even need to have a separate window.   Instead you could just enter cmd in a Powershell window to get into a cmd shell environment and then enter the "cmd pipeline" there.   To leave that environment and go back to Powershell you would then just enter "exit".

In fact, part of the confusion for you is probably in the Powershell where we are using the dir command which is really an alias of a real Powershell cmdlet for the convenience of cmd window users who are used to typing that when getting lists of modules.  For the convenience of UNIX users ls is another alias.  The real Powershell cmdlet is incongruously called Get-ChildItem which even hardcore Powershell users would probably want to reduce to gci  to simplify typing.   

Maybe I should start  using ls instead of dir in my Powershell examples.  That would be more comfortable for me than "gci" and might not confuse people as much as dir seems to.  However, ls in Powershell probably has its own syntax quirks that UNIX users would have to get used to too.

Coincidentally, I recently became aware of the need for some more switches even when listing stuff under a User Profile, so maybe you will need the same extra switches to see what the other pipeline was showing us before (for who knows what reason)?   In any case please amend the Powershell pipeline to

and again, with that, all I find are directories but taking out the filter for manifest proves that the syntax should find files (e.g. items which report lengths) too.

BTW the same time that I found the need for these extra switches also made it more apparent how unreliable file timestamp data can be (worse than I suspected) so the Sort step may or may not do anything helpful and we will just have to try to match up module "versions" by their lengths, particularly in the case of whatever results are given for the Lengths that you already showed you have in System directories.  We could do a separate list of them or just refer back to the one that you have already given for that matching.  Note that they will be eliminated from this list because 16407 will not appear anywhere in their "FullName" property.

Let's do a separate list for those anyway, save switching back and forth between two separate posts and scanning through a different sort order trying to find a match.

HTH

Robert