Error installing Windows 8.1 Update for x64-based Systems (KB2919355) - error 80070005

My computer is not able to install this latest update from Microsoft. It has already been upgraded to 8.1 without any issues.

I ran ProcessMonitor and found this:

Date & Time: 2014-04-26 05:30:50 PM

Event Class: File System

Operation: SetLinkInformationFile

Result: ACCESS DENIED

Path: C:\Windows\WinSxS\amd64_microsoft-windows-b..nager-efi.resources_31bf3856ad364e35_6.3.9600.16384_en-gb_680d99c9c1bb411e\bootmgr.efi.mui

TID: 3056

Duration: 0.0000421

ReplaceIfExists: True

FileName: \SystemRoot\WinSxS\amd64_microsoft-windows-b..nager-efi.resources_31bf3856ad364e35_6.3.9600.17031_en-gb_68408c0dc1958b90\bootmgr.efi.mui

The process details:

Description: Windows Modules Installer Worker

Company: Microsoft Corporation

Name: TiWorker.exe

Version: 6.3.9600.17031 (winblue_gdr.140221-1952)

Path: C:\WINDOWS\winsxs\amd64_microsoft-windows-servicingstack_31bf3856ad364e35_6.3.9600.17031_none_fa50b3979b1bcb4a\TiWorker.exe

Command Line: C:\WINDOWS\winsxs\amd64_microsoft-windows-servicingstack_31bf3856ad364e35_6.3.9600.17031_none_fa50b3979b1bcb4a\TiWorker.exe -Embedding

PID: 3316

Parent PID: 672

Session ID: 0

User: NT AUTHORITY\SYSTEM

Auth ID: 00000000:000003e7

Architecture: 64-bit

Virtualized: False

Integrity: System

Started: 2014-04-26 05:21:13 PM

Ended: (Running)

Modules:

 Having a look at the permissions on the bootmgr.efi.mui files in both referenced locations shows that SYSTEM can only read and execute these files, which is most likely why the update fails.

My machine originally had a local account, and when I installed the 8.1 upgrade it changed my local account to a live account against my wishes. This should not have anything to do with it, as Windows Update does not run as me, right?

Is it safe to change the permissions so that SYSTEM has write access as well?

EDIT: After all this, the solution found here is quite simple: just reboot and only open Windows Update and install the update. It seems some files might have been held by other processes.

SSL connection issues when using client certificate authentication

The SSL subsystem in Windows has a limitation as to the maximum size of the Trusted Issuers list the server sends to the client during the client certificate authentication process. This causes the list to be truncated, and if the issuer of your client certificate is not listed, causes the authentication to fail with the following message

HTTP/1.1 403 Forbidden
Content-Length: 0
Server: Microsoft-HTTPAPI/2.0
Date: Fri, 04 Apr 2014 10:00:13 GMT

This will be accompanied by an entry with Event ID 36885 in the Windows System Eventlog

When asking for client authentication, this server sends a list of trusted certificate authorities to the client. The client uses this list to choose a client certificate that is trusted by the server. Currently, this server trusts so many certificate authorities that the list has grown too long. This list has thus been truncated. The administrator of this machine should review the certificate authorities trusted for client authentication and remove those that do not really need to be trusted.

There are two approaches to fix this:

• remove certificates from the list of Trusted Issuers (not always easy or safe, you might delete certificates required by the operating system or other installed software), or
• create a registry setting that will cause the SSL subsystem to no longer send the list of Trusted Issuers to the client

I personally prefer the 2nd option, as there is less chance of disaster IMHO.

MS article: http://support.microsoft.com/kb/2464556

Other ref: http://blog.codit.eu/post/2013/04/03/Troubleshooting-SSL-client-certificate-issue-on-IIS.aspx