I have a SQL Server instance running SQL 2008 R2 on a Hyper-V virtual Windows 2012 R2 server. After applying the security update for SQL Server 2008 R2 SP3 (KB4057113), the instance failed to start successfully. The SQL Error Log contained the following error messages:
2018-01-30 18:08:28.17 spid9s Exporting ##MS_AgentSigningCertificate## to S:\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\MS_AgentSigningCertificateEDA2C2C9-78C0-4500-8B20-000B27D64CA0.cer
2018-01-30 18:08:28.17 spid9s Error: 15240, Severity: 16, State: 1.
2018-01-30 18:08:28.17 spid9s Cannot write into file ‘S:\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\MS_AgentSigningCertificateEDA2C2C9-78C0-4500-8B20-000B27D64CA0.cer’. Verify that you have write permissions, that the file path is valid, and that the file does not already exist.
2018-01-30 18:08:28.19 spid9s Error: 912, Severity: 21, State: 2.
2018-01-30 18:08:28.19 spid9s Script level upgrade for database ‘master’ failed because upgrade step ‘sqlagent100_msdb_upgrade.sql’ encountered error 15240, state 1, severity 16. This is a serious error condition which might interfere with regular operation and the database will be taken offline. If the error happened during upgrade of the ‘master’ database, it will prevent the entire SQL Server instance from starting. Examine the previous errorlog entries for errors, take the appropriate corrective actions and re-start the database so that the script upgrade steps run to completion.
2018-01-30 18:08:28.20 spid9s Error: 3417, Severity: 21, State: 3.
2018-01-30 18:08:28.20 spid9s Cannot recover the master database. SQL Server is unable to run. Restore master from a full backup, repair it, or rebuild it. For more information about how to rebuild the master database, see SQL Server Books Online.
Interestingly, the program had successfully written a file to the same directory one second earlier:
2018-01-30 18:08:27.37 spid9s Created #InstmsdbAgentCertPath with value S:\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\MS_AgentSigningCertificate.cer
Manually, I granted full control to the S:\MSSQL10_50.MSSQLSERVER\MSSQL\DATA directory for the service account being used by the SQL instance (and the SQL Agent Service) and restarted the instance.
The patch installation completed without error and the instance started successfully.
I have applied this hotfix to multiple other servers, including servers on the same SQL and OS version as well as others, without incident.
UPDATE: This server failed a few days later due to disk issues, so in retrospect, I think the patch issues were probably tied to the disk issues and unrelated to the patch.