Issue with installing updates on Windows 8.1.

I really appreciate the information supplied by JW0194. I intend to use that information as soon as I am able to find a Win 8.1 ISO. It makes no difference to most users whether a poster has a badge or title as most of us are looking for answers to problems rather than viewing a poster's profile.

I wouldn't place too much credence on what JW0194 writes Robert. That post of his is just a copy/paste from a couple of other sites. If you look at his profile, he's been around since 2009, but has yet to get his "First Answer" badge even.

Also, /Resetbase will prevent the user from uninstalling all previous updates: http://technet.microsoft.com/en-us/library/hh825265.aspx

Hi Robert

Sorry, I was just being lazy/tired. I used to teach unix shell scripting so I'm quite familiar with pipes and filters.

My output is:

211968 C:\Windows\softwaredistribution.bak\Download\367ea478b6d14d929c45a19dc20a53e5\x86_microsoft-windows-d..ervicing-management_31bf3856ad364e35_6.3.9600.17031_none_f37c59e329204af6\Dism.exe

188416 C:\Windows\System32\Dism.exe                                                                                                                                                             

188416 C:\Windows\SysWOW64\Dism.exe                                                                                                                                                             

245760 C:\Windows\WinSxS\amd64_microsoft-windows-d..ervicing-management_31bf3856ad364e35_6.3.9600.16384_none_4f680322e1a371ba\Dism.exe                                                          

 35983 C:\Windows\WinSxS\amd64_microsoft-windows-d..ervicing-management_31bf3856ad364e35_6.3.9600.17031_none_4f9af566e17dbc2c\Dism.exe                                                          

188416 C:\Windows\WinSxS\x86_microsoft-windows-d..ervicing-management_31bf3856ad364e35_6.3.9600.16384_none_f349679f29460084\Dism.exe                                                            

211968 C:\Windows\WinSxS\x86_microsoft-windows-d..ervicing-management_31bf3856ad364e35_6.3.9600.17031_none_f37c59e329204af6\Dism.exe 

Same files, different locations! What a mess.

Thanks Xircal but I have done both those dozens of times now to no effect at all.

Next...?

Doesn't mean much to me. I can't see dism.exe in winsxs

Let me try to explain the pipeline that you just executed, more or less successfully.  FWIW I didn't have any authorization issues but they are easy to deal with using a few more flags on the dir command.  Actually dir in Powershell is just an alias for the Get-ChildItem cmdlet but I think you can get the same help for either using  get-help or -? appended to your command.

The first stage does a search of all subdirectories of C:\Windows (your current directory) for files (and directories) which match the pattern  *dism.exe.  The pipe operator, similar to the pipe operator in cmd shell just passes all the objects found in the first stage to the second stage.

The second stage is just a second way of processing the file names that the first stage found, in order to maximize the amount of information we can display about each, including especially the version information for each.  

It would probably help for you to look at the properties that each object found passes with it this way.

E.g. doing that would show you that there is no magic in the Property name I picked for Get-Item to be done to.   It is just a way of maintaining the current directory and examine the properties of each of the files which were found as fully qualified names instead of somehow relatively named ones.

In fact, now I just realized that we don't even need that second stage at all.  Apparently this will do the same thing, except that now I do get that authorization error on C:\Windows\CSC (whatever it is).

Oh well.   As I said, I'm no Powershell expert; I just use it.   ; )

Looking at your output though I am perplexed.  There are differences that I would not expect, particularly regarding the lengths.  Try this pipeline next and compare with my output.

What I thought you might be able to do was just copy the AMD64 17031 from WinSxS to System32 but I can't suggest that if we have different lengths.   We do seem to have consistent lengths in the 32-bit case though, so perhaps you could try the same repair on it instead, e.g. copy the X86 17031 from WinSxS to SysWOW64.  

That is assuming that SFC doesn't fix this for you, of course.  Have you tried that?  Aha.  I just noticed that  SFC  has a rarely used option which might be ideal for this.  /SCANFILE=  So, if the standard syntax doesn't fix it, have a go with that instead?  Otherwise plan B would be the manual copying--but only if the lengths make sense.  I think the versions make sense but this may be an instance of real corruption.

HTH

Robert