Error 912: Script Level Upgrade Failed After a Cumulative Update

Fix it now

A patch replaced the binaries and the upgrade scripts then failed, so the instance takes the database offline and will not finish starting. Error 912 names the script and the inner error; 3417 reports that master could not be recovered. Start with trace flag 902, fix what the log names, then remove the flag.

NET START MSSQLSERVER /T902

1. Read the newest instance error log first. Error 912 quotes the upgrade script that failed and the inner error number, state and severity, and the messages just before it are the real cause.
2. Start with the upgrade scripts skipped. Either add -T902 under Startup Parameters in SQL Server Configuration Manager, or use the NET START form above, or run sqlservr.exe -s <instance> -T902 from the Binn folder.
3. Fix what the log named. Microsoft’s documented causes for the common 574 case are conflicting user options, orphaned database users, and jobs owned by logins that no longer exist.
4. Remove -T902 from the startup parameters and restart. The scripts run again and should complete.
5. Confirm with SELECT SERVERPROPERTY('ProductVersion'), SERVERPROPERTY('ProductUpdateLevel'); and check the log shows the upgrade finishing.

Trace flag 902 starts new binaries against system objects that have not been upgraded. Back up master and msdb before using it, keep applications off, and remove it as soon as the blocker is cleared. Microsoft’s instruction is to remove it once the issue is resolved, not to run on it.

If the instance starts clean with no trace flag, you are done. If not, the next section explains what runs after a patch and why it stops.

Why it happens

A cumulative update replaces program files and nothing else. It cannot change the contents of your system databases while the service is stopped, so the first time the newer binaries start, the engine runs the T-SQL upgrade scripts that ship with the update. Those scripts live in the MSSQL\Install folder under the instance directory, which is why the script name in the error message looks like a filename: it is one.

The engine treats the outcome as all or nothing, because half-upgraded system objects are worse than none. Error 912’s published text says so plainly: the database will be taken offline, and if the failure was in master it will prevent the entire instance from starting. It also tells you to examine the previous error log entries, take corrective action, and restart so the scripts run to completion. Error 3417 sits alongside it and reports the failure to recover master. Setup, meanwhile, reports “Wait on Database Engine recovery handle failed” and tells you nothing useful.

Trace flag 902 skips script upgrade mode so the instance starts anyway. That gives you a connection to fix the blocker. It does not run the scripts, so the instance is in an unsupported half-patched state for as long as the flag is set.

Error 574 is the most common companion, and its cause is more specific than it looks. Microsoft’s account is that the upgrade scripts run inside a transaction, and where system objects or permissions have been modified a script can fail and leave an orphaned open transaction behind. A later script then calls sp_configure, which is a CONFIG statement, and a CONFIG statement cannot be used inside a user transaction. So 574 is a symptom of an earlier failure, not the first thing that went wrong.

Full reference

Three documented ways to set trace flag 902

Whichever route you use, remove it the same way once the blocker is cleared. A -T902 left in the startup parameters means the upgrade scripts never run and the instance stays half patched indefinitely.

Reading the failure

Finding the two orphan cases Microsoft names

SELECT dp.type_desc, dp.SID, dp.name AS user_name
FROM sys.database_principals AS dp
LEFT JOIN sys.server_principals AS sp ON dp.SID = sp.SID
WHERE sp.SID IS NULL AND authentication_type_desc = 'INSTANCE';

SELECT sj.name AS Job_Name, sl.name AS Job_Owner
FROM msdb.dbo.sysjobs_view AS sj
LEFT JOIN master.dbo.syslogins AS sl ON sj.owner_sid = sl.sid
WHERE sl.name <> 'sa'
ORDER BY sj.name;

Commands worth having open

Other inner errors Microsoft documents for this failure

Microsoft maintains a set of articles for specific upgrade-script failures, each keyed on the inner error rather than on 912. Among them are 574 for the CONFIG statement case, 945 where SSISDB is part of an availability group, 1712 for online index operations on a lower edition, 2714 for an object that already exists, 4860 for a missing file, 5133 where the temporary database could not be created, 15151 and 15173 for principal problems, and 17182 where TLS 1.0 has been disabled. If the inner error in your log is one of those, search for it directly rather than reading general 912 advice.

What not to do

• Do not uninstall the update. Removing it will not undo scripts that already ran, and it leaves you unpatched with the original problem intact.
• Do not leave -T902 set and carry on. The instance is running new binaries against un-upgraded system objects, which is not a supported state.
• Do not restore master from a different server to ‘fix’ ownership. Correct the owner with ALTER AUTHORIZATION instead.
• Do not skip the backups. You are about to work on master and msdb, so back them up before you change anything.

Every code this article covers

Confirm the fix worked

1. The service starts with no trace flag in the startup parameters and stays running.
2. The error log for that clean start shows the script upgrade completing, followed by the ready for connections entry, and no 912 or 3417.
3. SERVERPROPERTY('ProductVersion') matches the build you installed and ProductUpdateLevel shows the update.
4. SELECT name, state_desc FROM sys.databases; shows every system database ONLINE.
5. SQL Server Agent starts and a test job runs to completion.

Questions people ask about this