Another “Wait on the Database Engine Recovery handle failed” – SQL Server 2000 to 2008R2 upgrade

I was given the task of upgrading our SQL Server 2000 instance to SQL Server 2008R2. I ran through the following steps to make sure the upgrade would be a success:

  • Took a snapshot of the VM
  • Upgraded to SQL Server 2000 service pack 4
  • Installed the updated Windows Installer 4.5
  • Launched the “System Configuration Checker” (found no issues)
  • Ran the “Upgrade Advisor” and addressed all issues

To this point, I figure I’m golden. Running the upgrade, it finishes with the always daunting, ever elusive error:

“Wait on the Database Engine Recovery handle failed. Check the SQL Server error log for potential causes.”

This occurred during the “SqlEngineDBStartConfigAction_upgrade_configc_Cpu32” portion of the upgrade. The error log showed:

Googling took me to a number of sites but this one was the most useful:

Not sure why the answer was marked the way it was, but I had to scroll to the bottom of the post to this reply:

“This issue has been resolved.  It still goes back to the complex password issue.  I had to turn off complex password policy on my domain, run the install repair, and it worked successfully.  It does not help to just make the SA password complex.  There are many blogs out there that point to an account being used in the install script that does not meet the complex password.  I could not find that account in my case, so I had to turn off my policy temporarily.”

I had changed the SA password a few times, made sure it was correct by logging in and actually using that account to perform the service pack 4 installation, and was confident that it met the complexity policy.  According to the above, it’s not the problematic user. Once I disabled the password complexity policy the engine started up without issue.

Some tools that helped me:

To change the ‘sa’ password in SQL Server 2000 (run as a member of ‘sysadmin’, no need for the old password)

EXEC sp_password @new='AG00dlongP@ssword!', @login='sa'

Running the SQL Server .exe from the command line with the -M option gave more information. Change directory to the location of the .exe and issue the following command (see below). It will output messages to a file in that same directory called ‘error.txt’ (useful for debugging as DOS buffer is inadequate):

sqlserver.exe -M > error.txt