By the way, I should also mention that I was finally able to get 2919355 to install by adding the "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\System Tools" folder as others have recommended. Will post more details soon, but things seem to be okay
now.
Summary: So I finally got this to install yesterday, by adding a "System Tools" folder as I mentioned. I get that this won't work for everyone, but it’s likely the easiest thing to try.
As a bit of explanation, I should mention that the first time I got an error message for this update, I ran DISM and SFC, which found that CNBJ2530.DPB was corrupted. DISM couldn’t download a correct version of this, but I was able to patch it manually.
Somewhere in the upgrade process, though, DISM also wound up finding two more corrupted files: amd64_microsoft-windows-ieframe_31bf3856ad364e35_11.0.9600.16412_none_68562a4a9121d484\ieframe.dll and amd64_microsoft-windows-ie-runtimeutilities_31bf3856ad364e35_11.0.9600.16412_none_4b5768046f86fb7e\iertutil.dll.
DISM wasn't able to download correct versions of these either and gave the error code 0x800f081f. I was able to patch these files by expanding the CAB file from the installer for that particular update -- kb2884101 -- and using that expanded folder as a source
folder for the DISM command.
As well, each failed kb2919355 update left behind several folders, which DISM was able to clean using /startcomponentcleanup and the /remove-package command others have mentioned. Even after all of this, DISM was still giving 0x800f081f, even though the
DISM logs showed that there were no packages that needed to be repaired, and the update was still failing.
So at this point I tried to add the “System Tools” folder to “C:\ProgramData\Microsoft\Windows\Start Menu\Programs”, which had been recommended at
http://chentiangemalc.wordpress.com/2014/04/03/case-of-the-kb2919355-installation-failure-windows-8-1-update-1/[http://atarasevich.blogspot.ca/2014/04/error-0x80070002-when-installing-new.html](http://atarasevich.blogspot.ca/2014/04/error-0x80070002-when-installing-new.html) and which Susan Bradley had also recommended in her excellent blog post. I had
been a bit hesitant to try this, quite frankly, since it seemed like a pretty silly reason for the update to fail: it’s the sort of thing the installer should have corrected for, not to mention that I hadn’t moved any Start Menu folders around anyways. The
weird thing was that after I added this folder, it still wasn’t visible in Explorer (even if I displayed hidden files and system files), so I ran a dir command in the Command Prompt and found out that it (and the shortcuts within it) already existed and had
a last-modified date of August 22. And now that I’ve installed the update, the shortcuts still have the same last-modified date – so if no changes were made to this Start Menu folder during the update, why did the installer need it in the first place?
I still had a few corrupt files in DISM and SFC after installing the update – some of these related to IE, and I think those were the same ones that got left behind after the failed update installations I mentioned earlier. As before, since DISM couldn’t
download the correct versions of these files, I was able to repair them by expanding the CAB files from the installers of kb2919355 and kb2934018 (note that kb2934018 is one of the updates normally installed as part of kb2919355), and using these as source
folders for DISM. Now, DISM and SFC come up totally clean, and things seem to be working fine.
Of course, this whole procedure isn’t something I’d ever want to have to explain over the phone to someone, and I would have liked to see Microsoft take a more active role in putting this right. If this is failing on even fresh installations of Windows 8.1,
that’s a good sign Microsoft screwed up somewhere in the process and should have tested this one more thoroughly, even though as a programmer, I get that there’s no way for them to test their updates on the infinite variations of software and hardware that
people might have installed. This isn’t to say that the user’s at fault for having installed third-party software or anything; unfortunately, it’s just the way these things work. And I can’t help but think that I’d still end up doing this much tweaking someday
if I switched to Linux.
I’m sure Microsoft will get this fixed before the 8.1 support deadline – and if they don’t, I’m sure that they’ll extend the support deadline, since there’s no way they can let these errors slide – but as long as your computer is still working okay without
the update, and as long as this remains an optional update, it’s not the end of the world, not yet. I also don’t think we’ve got enough evidence on our end to peg the blame on the new Windows 8 interface people have been ranting about, or to say that something
like this could never happen to Windows 7. All that being said, I’m glad we’re all having this discussion so that this can hopefully be resolved soon.
Peace out, and have a good week, everyone. To Susan, the MVPs, and anyone else, I’m happy to share some of my log files.
P.S. One last tip, which I've mentioned before: if you're seeing Chinese characters in dism.log, open it up in Microsoft Word, and select UTF-8 as the character encoding. This file was invaluable for me during my troubleshooting.