SQL Server 2005 hotfix, Cumulative Update or Service Pack installation fails with error 1053

You may be trying to apply one hotfix, one Cumulative Update or one Service Pack on top of your SQL Server 2005 instance and it fails, showing the following information in the setup log, and ERRORLOG, respectively:

From setup log:

<Func Name='SetCAContext'>
<EndFunc Name='SetCAContext' Return='T' GetLastError='0'>
Doing Action: ComponentUpgradeInstall
PerfTime Start: ComponentUpgradeInstall : Tue Jul 03 14:09:57 2007
<Func Name='ComponentUpgradeInstall'>
<Func Name='ComponentUpgrade'>
Failed to add file 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG\ERRORLOG' to datastore in AddFileToFailureHandling
Service MSSQLSERVER with parameters '-r' is being started at Tue Jul 03 14:09:57 2007
SQL service MSSQLSERVER started successfully waiting for SQL service to accept client connections
Failed to start service MSSQLSERVER. Error code 1053
Service control operation timeout (1053)
Error Code: 0x8007041d (1053)
Windows Error Text: The service did not respond to the start or control request in a timely fashion.
Source File Name: sqlsetuplib\sqlservice.cpp
Compiler Timestamp: Sat Oct 7 09:44:29 2006
Function Name: sqls::SqlService::Start
Source Line Number: 112

From ERRORLOG:

2007-07-03 14:10:00.30 Server Microsoft SQL Server 2005 - 9.00.3042.00 (Intel IA-64)
Feb 10 2007 01:00:35
Copyright (c) 1988-2005 Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 5.2 (Build 3790: Service Pack 1)
2007-07-03 14:10:00.31 Server (c) 2005 Microsoft Corporation.
2007-07-03 14:10:00.31 Server All rights reserved.
.
.
.
2007-07-03 14:10:25.99 spid12s Starting up database 'msdb'.
2007-07-03 14:10:25.99 spid15s Starting up database 'MyVLDB'.
2007-07-03 14:10:28.61 spid10s Starting up database 'tempdb'.
2007-07-03 14:10:28.81 spid10s Analysis of database 'tempdb' (2) is 100% complete (approximately 0 seconds remain). This is an informational message only. No user action is required.
2007-07-03 14:12:07.60 spid15s Recovery of database '

MyVLDB' (7) is 0% complete (approximately 35536 seconds remain). Phase 2 of 3. This is an informational message only. No user action is required.
2007-07-03 14:12:27.61 spid15s Recovery of database 'MyVLDB' (7) is 0% complete (approximately 4129 seconds remain). Phase 2 of 3. This is an informational message only. No user action is required.
2007-07-03 14:12:47.95 spid15s Recovery of database 'MyVLDB' (7) is 0% complete (approximately 4400 seconds remain). Phase 2 of 3. This is an informational message only. No user action is required.
2007-07-03 14:12:55.27 spid15s Recovery of database 'MyVLDB' (7) is 1% complete (approximately 4603 seconds remain). Phase 2 of 3. This is an informational message only. No user action is required.
2007-07-03 14:13:15.29 spid15s Recovery of database 'MyVLDB' (7) is 1% complete (approximately 4900 seconds remain). Phase 2 of 3. This is an informational message only. No user action is required.
.
.
.
2007-07-03 14:40:10.45 spid15s Recovery of database 'MyVLDB' (7) is 40% complete (approximately 2524 seconds remain). Phase 2 of 3. This is an informational message only. No user action is required.
2007-07-03 14:40:30.50 spid15s Recovery of database 'MyVLDB' (7) is 40% complete (approximately 2510 seconds remain). Phase 2 of 3. This is an informational message only. No user action is required.
2007-07-03 14:40:49.28 spid15s Recovery of database 'MyVLDB' (7) is 41% complete (approximately 2478 seconds remain). Phase 2 of 3. This is an informational message only. No user action is required.
2007-07-03 14:41:09.28 spid15s Recovery of database 'MyVLDB' (7) is 41% complete (approximately 2445 seconds remain). Phase 2 of 3. This is an informational message only. No user action is required.

This occurs because SQL Server 2005 hotfix and Service Pack installers allocate a timeout which, in some case, is not sufficient to complete the recovery of all databases recovery (((databaseCount * 30) + (30 * 60)) * 1000 milliseconds). The only feasible workaround we can provide for cases were the recovery of all your databases could take longer than that, is to detach those databases before applying the hotfix or Service Pack and re-attach it when the build upgrade is finished.

A bug is filed for this already, so that the product team takes this issue into account and fixes it as soon as possible.

See you in the next post!