Edit

Share via

Troubleshoot common SQL Server Cumulative Update installation issues

  • Article

This article provides general steps to troubleshoot issues that you might experience when you apply a Cumulative Update (CU) or Service Pack (SP) to your Microsoft SQL Server instance. It also provides information on how to resolve the following error messages or conditions:

  • Wait on Database Engine recovery handle failed message and errors 912 and 3417 when you run upgrade scripts.
  • Setup errors that occur because of missing MSI or MSP (update) files in the Windows Installer cache.
  • The Database Engine system data directory in the registry is not valid or the User Log directory in the registry is not valid messages.
  • Network path was not found and other error messages that you receive if Remote Registry Service or admin shares are disabled on an Always On Failover Cluster instance (FCI) or Always On Availability Groups.

Cumulative update and service pack installation information

This section provides information about CU and SP installations.

  • For Microsoft SQL Server 2016 and earlier versions:

    • Before you install a CU, make sure that your SQL Server instance is at the right SP level for that CU. For example, you can't apply CU17 for SQL 2016 SP2 before you apply SP2 for the SQL Server 2016 instance.
    • You can always apply the latest CU for a given SP baseline without having to apply previous CUs for that service pack. For example, to apply CU17 for SQL Server 2016 SP2 instance, you can skip applying previous updates to CU14, CU15, and CU16, if they aren't installed, and apply CU17 directly.

  • For Microsoft SQL Server 2017 and later versions, you can always apply the latest CU that's available. (No service packs exist for SQL Server 2017 and later versions.)

  • Before you apply a CU or SP, make sure that the instance that you're updating is correctly installed. The SQL Server program files and data files can't be installed on:

    • A removable disk drive.
    • A file system that uses compression.
    • A directory in which system files are located.
    • Shared drives on a failover cluster instance.

  • If you add a database engine feature after you apply a CU or an SP to an instance, you should update the new feature to the same level as the program instance before you apply any new CUs or SPs.

General troubleshooting methodology

Isolate the error by following these steps:

  1. Select Details from the setup process's Failure screen.
  2. In the %programfiles%\Microsoft SQL Server\nnn\Setup Bootstrap\Log folder, check Summary.txt under the Product features discovered section to determine whether any of the listed features report a failure. If they do, you can focus on resolving problems that affect that feature.
  3. Go to the subfolder that's named yyyyMMdd_HHmmss (for example 20220618_174947) that corresponds to the reported failure time that you are focusing on. The goal is to examine the feature-specific files, ERRORLOG files, and Details.txt file, if necessary.
  4. Go to the \MSSQLSERVER subfolder, and locate the log files that are specific to the feature that failed. For example, sql_engine_core_inst_Cpu64_1.log. For upgrade script failures, check the SQLServer_ERRORLOG_date_time.txt files that correspond to the time of the upgrade failure.
  5. Open the Details.txt log file, and search on the keyword "Failed." Not every failure is considered critical.

For more information, see View and Read SQL Server Setup Log Files.

In the next few sections, check for a scenario that corresponds to your situation, and then follow the associated troubleshooting steps. If there's no matching scenario, look for more pointers in the log files.

Errors 912 and 3417 and "Wait on Database Engine recovery handle failed"

T-SQL upgrade scripts are shipped together with every SQL Server cumulative update. They're run after the SQL Server binaries are replaced with the latest versions. If these T-SQL scripts don't run for some reason, the Setup program reports a "Wait on Database Engine recovery handle failed" error. Setup records errors 912 and 3417 in the latest SQL Server error log. Errors 912 and 3417 are associated with database script upgrade failures and failure to recover the master database, respectively. The messages that precede error 912 usually provide information about the root cause of the failure that occurred when the upgrade scripts were run.

There could be a variety of errors raised together with 912 and 3417. For more information about a summary of common scenarios and related solutions, see Troubleshoot upgrade script failures when applying an update.

Setup errors caused by missing installer files in Windows cache

Applications such as SQL Server that use Windows Installer technology for the setup process will store critical files in the Windows Installer cache. The default installer cache location is C:\Windows\Installer. These files are required for uninstalling and updating applications. They're unique to that computer. Updates to applications that depend on these files won't work if they're accidentally deleted or otherwise compromised. To resolve this condition, use one of the following methods that are described in Restore the missing Windows Installer cache files:

Setup fails because of incorrect data or log location in registry

When you install a CU or SP, if the default data and log folders are invalid, you may receive errors that resemble the following messages:

"The User Data directory in the registry is not valid. Verify DefaultData key under the instance hive points to a valid directory."

"The User Log directory in the registry is not valid. Verify DefaultLog key under the instance hive points to a valid directory."

"Error installing SQL Server Database Engine Services Instance Features. The Database Engine system data directory in the registry is not valid."

To fix this issue, follow these steps:

  1. Connect to the SQL Server instance by using SQL Server Management Studio (SSMS).
  2. Right-click the SQL Server instance in the Object Explorer and select Properties > Database Settings.
  3. Under Database Default locations, make sure that the folders in Data and Log are correct.
  4. In the SQL Server Configuration Manager, select SQL Server Services, double-click the affected SQL Server Service, select the Advanced tab, and make sure the value of Data Path is correct. The value is grayed out and can't be modified. However, if you want to correct it, follow Method 2 in Error that Data or Log directory in the registry is not valid when installing SQL Server Cumulative Update or a Service Pack to modify the SQLDataRoot registry entry.
  5. Retry the CU or SP installation.

Misconfigured Windows Server Failover Clustering (WSFC) nodes

For smooth functioning and maintenance of a SQL Server Failover Cluster Instance (FCI), follow the best practices described in Before Installing Failover Clustering and Failover Cluster Instance administration & maintenance. If you experience errors when you apply a CU or an SP, check the following conditions:

  • Make sure that the Remote Registry service is active and running on all nodes of the WSFC cluster.
  • If the service account for SQL Server isn't an administrator in your Windows cluster, make sure that administrative shares (C$ and so on) are enabled on all of the nodes. For more information, see Overview of problems that may occur when administrative shares are missing. If these shares aren't configured correctly, you might notice one or more of the following symptoms when you try to install a CU or SP:
    • The update takes a long time to run or doesn't respond. Setup logs don't reveal any progress.
    • Setup logs contain messages such as the following:

      The network path was not found. System.UnauthorizedAccessException: Attempted to perform an unauthorized operation.

Additional information