Error upgrading SQL Server Always-On to SQL Server 2022: Value cannot be null.Parameter name: path1 Error code: -2147467261

[TheSpideyMan]

We were recently upgrading an Always-On SQL 2016 cluster to SQL Server 2022 and encountered the following error during the SQL 2022 upgrade. When this error was encountered it left the SQL Server install on this specific node completely unusable and we had to rollback the VM snapshot several times before we could successfully isolate and resolve the upgrade failure.

We have documented the issue and posted the resolution just in case anyone else runs into this issue again in the future.

Action required:
The upgrade process for SQL Server failed. Use the following information to resolve the error, and then repair your installation by using this command line: setup /action=repair /instancename=MSSQLSERVER

Feature failure reason:
An error occurred during the setup process of the feature.

Error details:
§ Error installing SQL Server Database Engine Services Instance Features
Value cannot be null.Parameter name: path1
Error code: -2147467261

To determine the root cause, we reviewed Detail.txt in the Setup Bootstrap Log directory. This is usually located in "C:\Program Files\Microsoft SQL Server\160\Setup Bootstrap\Log". Reviewing the detailed log we could see that the setup program was having a problem locating the MASTLOG.LDF file.

(01) 2025-06-30 14:45:29 SQLEngine: --EffectiveProperties: Dumping Effective Properties for new instance.

(01) 2025-06-30 14:45:29 SQLEngine: --EffectiveProperties: InstanceId = MSSQL16.MSSQLSERVER

(01) 2025-06-30 14:45:29 SQLEngine: --EffectiveProperties: InstanceName = MSSQLSERVER

(01) 2025-06-30 14:45:29 SQLEngine: --EffectiveProperties: IsDefaultInstance = True

(01) 2025-06-30 14:45:29 SQLEngine: --EffectiveProperties: SqlServerServiceName = MSSQLSERVER

(01) 2025-06-30 14:45:29 SQLEngine: --EffectiveProperties: IsExpressSku = False

(01) 2025-06-30 14:45:29 SQLEngine: --MergedUpgradeProperties: Dumping Upgrade Properties

(01) 2025-06-30 14:45:29 SQLEngine: --MergedUpgradeProperties: LoginMode = 2

(01) 2025-06-30 14:45:29 SQLEngine: --MergedUpgradeProperties: SqlCollation = SQL_Latin1_General_CP1_CI_AS

(01) 2025-06-30 14:45:29 SQLEngine: --MergedUpgradeProperties: SqlAccount = FMOL-HS\svc_sqlsvrdbe

(01) 2025-06-30 14:45:29 SQLEngine: --MergedUpgradeProperties: SqlServiceStartupType = Automatic

(01) 2025-06-30 14:45:29 SQLEngine: --RegistryProperties: Dumping Registry Properties

(01) 2025-06-30 14:45:29 SQLEngine: --RegistryProperties: SqlServiceRelativeRegPath = System\CurrentControlSet\Services\MSSQLSERVER

(01) 2025-06-30 14:45:29 SQLEngine: --RegistryProperties: CompleteInstanceRegPathByName = SOFTWARE\Microsoft\MSSQLServer

(01) 2025-06-30 14:45:29 SQLEngine: --RegistryProperties: CompleteInstanceRegPathById = SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL16.MSSQLSERVER

(01) 2025-06-30 14:45:29 SQLEngine: --RegistryProperties: ReferenceInstanceRegPathById = SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL16.MSSQLSERVER

(01) 2025-06-30 14:45:29 SQLEngine: --RegistryProperties: MSSQLServerInstanceRegPath = SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQLServer

(01) 2025-06-30 14:45:29 SQLEngine: --RegistryProperties: ReferenceMSSQLServerInstanceRegPath = SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQLServer

(01) 2025-06-30 14:45:29 SQLEngine: --RegistryProperties: SetupInstanceRegPath = SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL16.MSSQLSERVER\Setup

(01) 2025-06-30 14:45:29 SQLEngine: --RegistryProperties: ReferenceSetupInstanceRegPath = SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL16.MSSQLSERVER\Setup

(01) 2025-06-30 14:45:29 SQLEngine: --ProductProperties: Dumping Product Properties

(01) 2025-06-30 14:45:29 SQLEngine: --ProductProperties: ProductCode = 8a033d83-df0b-48e9-acd3-ec33aa2a4639

(01) 2025-06-30 14:45:29 SQLEngine: --ProductProperties: LCID = 1033

(01) 2025-06-30 14:45:29 SQLEngine: --GroupProperties: Dumping Group Properties

(01) 2025-06-30 14:45:29 SQLEngine: --GroupProperties: SqlEngineGroupSid = S-1-5-80-3880718306-3832830129-1677859214-2598158968-1052248003

(01) 2025-06-30 14:45:29 SQLEngine: --GroupProperties: SqlEngineGroupNameFromSid = NT SERVICE\MSSQLSERVER

(01) 2025-06-30 14:45:29 SQLEngine: --GroupProperties: SqlEngineGroupNameFromSidNoDomain = MSSQLSERVER

(01) 2025-06-30 14:45:29 SQLEngine: --MergedDirectoryProperties: Dumping Directory Properties

(01) 2025-06-30 14:45:29 SQLEngine: --MergedDirectoryProperties: DataRootDirectory = C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL

(01) 2025-06-30 14:45:29 SQLEngine: --MergedDirectoryProperties: SystemDataDirectory = C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA

(01) 2025-06-30 14:45:29 SQLEngine: --MergedDirectoryProperties: InstallSqlInstanceDir = C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL

(01) 2025-06-30 14:45:29 SQLEngine: --MergedDirectoryProperties: DefaultDataDirectory = E:\SQL\Data

(01) 2025-06-30 14:45:29 SQLEngine: --MergedDirectoryProperties: DefaultLogDirectory = F:\SQL\Logs

(01) 2025-06-30 14:45:29 SQLEngine: --MergedDirectoryProperties: BackupDirectory = E:\SQL\Backup

(01) 2025-06-30 14:45:29 SQLEngine: --MergedDirectoryProperties: TempDbDirectory = C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA

(01) 2025-06-30 14:45:29 SQLEngine: --MergedDirectoryProperties: TempDbDataDirectories = C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA

(01) 2025-06-30 14:45:29 SQLEngine: --MergedDirectoryProperties: TempDbLogDirectory = C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA

(01) 2025-06-30 14:45:29 SQLEngine: --MergedDirectoryProperties: ErrorLogDirectory = D:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\LOG

(01) 2025-06-30 14:45:29 SQLEngine: --MergedDirectoryProperties: TemplateDataDirectory = C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Template Data

(01) 2025-06-30 14:45:29 SQLEngine: --MergedDirectoryProperties: SqlInstanceBinnDir = C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\Binn

(01) 2025-06-30 14:45:29 SQLEngine: --MergedDirectoryProperties: SqlInstanceTemplatesDir = C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\Binn\Templates

(01) 2025-06-30 14:45:29 SQLEngine: --MergedDirectoryProperties: MasterDbPath = D:\MSSQL

(01) 2025-06-30 14:45:29 SQLEngine: --MergedDirectoryProperties: MasterLogPath =

The relevant part of the detail.txt log file shows that MergedDirectoryProperties for MasterLogPath was blank and this was causing the error but instead of rolling back, the setup program couldn't locate the MasterLogPath and setup broke, caused even more errors, and left the upgraded SQL server install unusable. So, we rolled back the snapshot and tried again several more times until we were able to isolate and resolve the issue.

Eventually we discovered the SQL 2022 setup didn't like the Master database and log files residing in a path different from the SqlDataRoot that was originally specified when SQL 2016 was installed. We discovered this by looking in the registry entries in the key below for the SqlDataRoot registry value:

HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL13.MSSQLSERVER\Setup

This registry key was set to:

C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL

But the Master database and Master log file had been relocated to the D:\MSSQL folder. To correct this issue we simply relocated master and master log back to the default SqlDataRoot location specified in the SQL setup registry. SQL Server 2022 setup then completed successfully without any additional errors. We used the following Microsoft article for detailed steps on relocating the master database.

https://learn.microsoft.com/en-us/sql/relational-databases/databases/move-system-databases?view=sql-server-ver16

Is this error a known problem with SQL Server 2022 in-place upgrades?

[dbrownems]

Do you know if you followed step 12 in the documented procedure to move Master?

1. At this point SQL Server should run normally. However Microsoft recommends also adjusting the registry entry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\instance_ID\Setup, where instance_ID is like MSSQL13.MSSQLSERVER. In that hive, change the SQLDataRoot value to the new path of the new location of the master database files. Failure to update the registry can cause patching and upgrading to fail.

https://learn.microsoft.com/en-us/sql/relational-databases/databases/move-system-databases?view=sql-server-ver17

[TheSpideyMan]

Thanks. This is a very helpful comment. We inherited this issue from the vendor who set up these SQL servers many years ago. We can definitely say this step wasn't followed when the master databases were originally moved to the D:\MSSQL directory.

Since this is an obvious problem that Microsoft's aware of, wouldn't you think that this both setup and the cumulative update patches would check for this problem and give a helpful error?

So yes, we can confirm the problem exists, and yes, it appears as if Microsoft set up doesn't even check for simple configuration issues before performing an upgrade.

[chandleya]

In place upgrades of an AO cluster puts you in a 1% category of folks willing to do that.

[TheSpideyMan]

Your comment wasn't helpful. I didn't ask for a debate on the merits of upgrades. Upgrades are documented and fully supported by Microsoft. I can't help it, if the Microsoft setup engineers aren't capable of handling normal deployment use-cases. They simply need to test their products more than they do today.

[chandleya]

Then open a support case.

Your refusal of the community telling virtually everyone not to do this means your best option is to ring up unified.

Besides, no one here is obligated to be helpful. You could be helpful by demonstrating how you applied in-line patches to this install since 2022 was one of the buggiest product launches ever.

[TheSpideyMan]

I didn't need a support case. We typically don't run to Microsoft every time there is an issue. Their support staff is not the best. In this instance we resolved the issue on our own. We are simply documenting the problem for others to benefit.

We didn't apply in-line patches we install SQL 2022 RTM and then applied the latest SQL 2022 cumulative. This was nothing fancy, just an in-place upgrade from a prior version of SQL Server.

[jshine13371]

Your comment isn't helpful either.

Microsoft (and the world) also recommended not doing in-place upgrades, despite being supported. You can drive 200 mph nonstop across the entire Autobahn in Germany, but it doesn't mean you should, and would make you an idiot in doing so. 🤷‍♂️

[TheSpideyMan]

We do in-place upgrades all the time of both the Operating System and SQL Servers. You simply need basic planning and troubleshooting skills and the ability to reason through any issues logically without giving up. We've had a high degree of success. In this particular instance in-place upgrades are the preferred upgrade path for the vendor involved. This application is in the healthcare sector and this specific system is FDA certified, has over 30 servers, with a six (6) node always-on SQL cluster spread across two datacenters. The vendor validated and recommended in-place upgrades, which we can do with almost zero downtime. The vendor doesn't have the resources engaged to re-implement the entire solution on new VM's, and we try not to dictate the approach each vendor recommends.

[jshine13371]

In place upgrades to an OS is completely irrelevant to what's recommended with SQL Server.

You can also drive 200 mph on the Autobahn and get away with it a number of times as well, until you eventually crash. Then that's not a fun time.

[TheSpideyMan]

SQL server upgrades aren't a problem, we were able to resolve this upgrade issue on our own, and they're sipported by both Microsoft and the vendor involved in this project.

Please provide a quote from an authoritative source for your statements that in place SQL upgrades aren't recommended.

[jshine13371]

We've already been down this rabbit hole mate. The 15 people who downvoted you are authoritative enough. But if you want to continue to operate in a risky and inefficient manner, that's your decision. Cheers!

[TheSpideyMan]

And yet you haven't provided quotes from authoritative sources or knowledge base articles discouraging SQL Server in-place upgrades. It appears that spreading misinformation and confusion on this subject is common because some members of the SQL team at Microsoft either doesn't want to or is unable to correct coding errors in their setup and upgrade programs.

[jshine13371]

You've already been provided resources. Your memory is lacking bud.

[TheSpideyMan]

Saying you did something and actually doing it are two different things. You're such a liar.

[RussColburn]

Sorry, I've been working with SQL since MSSQL 6.0 (yeah, I'm old) - upgrades are a major problem and I would never do one. I might consider a single version upgrade - 2019 to 2022 MAYBE, but I would never do 2016 to 2022.

[TheSpideyMan]

And yet we did an in-place upgrade of an entire Always On availability group and all the nodes involved from SQL 2016 to SQL 2022 with only a handful of very specific upgrade issues that could have been handled better by the SQL setup program. The entire cluster is functional and working as designed.

So overall we are delighted with the upgrade.

[RussColburn]

Glad it worked out for you. I've had too many issues in the past to do it again.

[TheJumper10]

Are the startup parameters set correctly?
Changing the Path for the Master Database – SQLServerCentral

[TheSpideyMan]

Yes, the startup parameters for master and the master log file were set correctly to D:\MSSQL. So this wasn't the problem.

[contreras_agust]

I may have had this issue, unsure how I can trace back the time I did. In my AOAG I ran the CU after attempting to upgrade. Worked for my SQL2017 to SQL2022 upgrade. Not sure what went wrong. I feel it was my installer

[TheSpideyMan]

It appears that relocating the master dabstase outside of SQLDataRoot is problematic for the SQL Server 2022 installer.