SQL SERVER – Script Upgrade Failure – RsFxFt.Dll::RsFxMgmtInitialize failed: Error 0x80070002

A client’s SQL Server would not come online after a patch and a failover. The ERRORLOG showed a script upgrade failure, full of a DLL name nobody recognised. It turned out to be FILESTREAM, a feature they were not even using. I tested the setting behind it on SQL Server 2025, and found how the problem can sit quietly on a healthy server for months before a patch trips it.

The ERRORLOG

RsFxFt.Dll::RsFxMgmtInitialize failed: Error 0x80070002 (-2147024894)
Failed to initialize the CFsaShareFilter interface
Failed to initialize CFsaShareFilter: Error 0x80070002 (-2147024894)
Error: 5597, Severity: 16, State: 1.
FILESTREAM feature could not be initialized. The Windows Administrator must
enable FILESTREAM on the instance using Configuration Manager before enabling
through sp_configure.
Error: 912, Severity: 21, State: 2.
Script level upgrade for database 'master' failed because upgrade step
'msdb110_upgrade.sql' encountered error 5597, state 1, severity 16.
Error: 3417, Severity: 21, State: 3.
Cannot recover the master database. SQL Server is unable to run.

RsFx is the FILESTREAM file system filter driver. 0x80070002 is the Windows code for “file not found”. So the filter driver was not there, or not loaded, when SQL Server went looking for it.

Then read the rest the usual way, from the bottom up. Error 3417 says master cannot be recovered, and that sounds terrible. It is the last domino, not the cause. The upgrade script hit error 5597, error 912 took master offline because of it, and 3417 is what that looks like. The real message is 5597, and it says exactly what is wrong.

FILESTREAM Has Two Switches

This is the part that trips people. FILESTREAM is switched on in two separate places, and both have to agree. There are two ways to end up with the message in that log. I could test one of them here.

The Windows level is set in SQL Server Configuration Manager, on the FILESTREAM tab of the service. That installs and enables the filter driver. The SQL Server level is set with sp_configure. You can read both from a query:

SELECT SERVERPROPERTY('FilestreamConfiguredLevel') AS windows_level,
       SERVERPROPERTY('FilestreamEffectiveLevel')  AS effective_level;

SELECT name, value, value_in_use
FROM   sys.configurations
WHERE  name = 'filestream access level';

On my instance both are 0. FILESTREAM is off everywhere, which is what most servers should look like.

What Happens When They Disagree

I switched it on at the SQL Server level only, with the Windows level still off. This is the exact mismatch error 5597 describes.

EXEC sp_configure 'filestream access level', 2;
RECONFIGURE;

Configuration option 'filestream access level' changed from 0 to 2.
FILESTREAM feature could not be initialized. The operating system Administrator
must enable FILESTREAM on the instance using Configuration Manager.

That is the same complaint as error 5597, but here it arrived as a warning, not an error. My TRY block did not catch anything. The statement succeeded. And look at what it left behind:

name                      value   value_in_use
filestream access level   2       0

The stored value is 2. The value actually in use is 0. On a running server nothing breaks. The setting just sits there, saying one thing and doing another.

Then you patch. The upgrade script runs at the first start after the patch, it trips over the same mismatch, and this time it is an error. The script fails, master goes offline, and the server does not come back. I set mine back to 0 straight away. I was not going to test the patch part on my working machine.

The Other Route, Which Fits My Client

My client fixed it by turning FILESTREAM off in Configuration Manager. That only changes anything if the Windows level was on. So their machine believed FILESTREAM was enabled, and the driver it needed was not there. That is exactly what 0x80070002, file not found, says.

I never found out how the driver went missing. They were not using FILESTREAM, and the log does not say. Two things I would check first. On a cluster, the Configuration Manager setting belongs to each Windows machine, not to the instance, so a node that never had FILESTREAM set up properly can be waiting for the first failover. And a patch that did not finish can leave a driver half installed.

That is how the setting works, not a story about their server. I do not have a cluster here to repeat it on.

The Fix

You have two ways out, and it depends on whether you actually use FILESTREAM.

If you do not use it, turn it off at the Windows level on the node in Configuration Manager and start the service. That is what my client did, and SQL Server came up. Then, once it is running, set the SQL Server level to 0 as well, so the two agree for good:

EXEC sp_configure 'filestream access level', 0;
RECONFIGURE;

If you do use it, enable it in Configuration Manager on this node, at the same level as the others, and start the service. On a cluster, do it on every node, not just the one that failed.

The Check to Run Before Every Patch

The whole problem is a configuration value that does not match what is in use. SQL Server will list every one of those for you:

SELECT name, value, value_in_use
FROM   sys.configurations
WHERE  value <> value_in_use;

I ran it after putting FILESTREAM back, expecting nothing. It returned one row:

name                     value   value_in_use
min server memory (MB)   0       16

That one is normal. Leave min server memory at 0 and SQL Server quietly uses a small floor of its own. So do not panic at it. Everything else this query returns deserves a look before you patch. It is a setting someone changed and never finished, and a patch is exactly when unfinished business comes due.

This failure is not a broken master database, it is FILESTREAM switched on somewhere its driver cannot be found.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.