SQL SERVER – Fix – Error 15240, Severity: 16, State: 2 – Cannot write into file

I patched a test machine and SQL Server refused to come back up. The ERRORLOG blamed Error 15240, cannot write into file. I fixed it at the time by removing a doubled backslash from a startup parameter. I tested that again on SQL Server 2025 while writing this, and the doubled backslash on its own turns out to be harmless. So this post is also a correction.

What the ERRORLOG Said

The service stopped during the upgrade scripts that run the first time SQL Server starts after a patch. These are the lines that matter:

Exporting ##MS_AgentSigningCertificate## to D:\MSSQL\Data\\MS_AgentSigningCertificate.cer
Could not export certificate, trying again with random name.
Error: 15240, Severity: 16, State: 2.
Cannot write into file 'D:\MSSQL\Data\\MS_AgentSigningCertificate663E...cer'.
Verify that you have write permissions, that the file path is valid, and that the
file does not already exist.
Error: 912, Severity: 21, State: 2.
Script level upgrade for database 'master' failed because upgrade step
'msdb110_upgrade.sql' encountered error 15240, state 2, severity 16.
Error: 3417, Severity: 21, State: 3.
Cannot recover the master database. SQL Server is unable to run.

Read it from the bottom. Error 3417 looks like the end of the world, because it says master cannot be recovered. It is not the cause. It is the last domino. The upgrade script failed, error 912 took master offline because of it, and 3417 is what that looks like.

The cause is 15240, near the top. The upgrade step tries to write a certificate file into the folder that holds master.mdf, and it could not.

One Message, Three Causes

The message offers three possibilities in one sentence: permissions, an invalid path, or a file that already exists. I tested them on SQL Server 2025 by writing a certificate to disk with BACKUP CERTIFICATE, which uses the same file write.

BACKUP CERTIFICATE BlogLabCert TO FILE = 'C:\...\MSSQL\Log\lab1.cer';

1. a normal path              ok
2. the same file again        Msg 15240, State 15: Cannot write into file ...
3. a doubled backslash        ok
4. a folder that is missing   Msg 15240, State 15: Cannot write into file ...

Two things jump out.

A file that already exists and a folder that does not exist give the identical error, with the identical state. The message cannot tell you which one you have. You have to go and look.

And the doubled backslash wrote the file perfectly well. Windows treats two backslashes in the middle of a path as one. That is the bit I got wrong years ago.

So What Did My Old Fix Actually Do?

The startup parameters on that machine read -d D:\MSSQL\Data\\master.mdf. I removed one backslash, started the service, and it worked. I concluded the backslash was the problem.

Look at the log again, because it holds a clue I walked past. The first attempt used the plain name, MS_AgentSigningCertificate.cer, and failed. SQL Server then tried again with a random name made of a GUID. That one failed too.

A random name cannot already exist. So the second failure rules out a leftover file. The doubled backslash is ruled out by today’s test. What is left is the one cause that explains both failures: the service account could not write into that folder.

I cannot prove that now, years later, on a virtual machine that no longer exists, and I cannot tell you what else changed that day. What I can say is that the backslash on its own does not cause this error, and a permission problem fits every line of the log. It is a very common trap. You change one thing, the problem goes away, and the change gets the credit.

What to Check, in Order

Find the folder first. It is the folder in the -d startup parameter, the one that holds master.mdf. You can read the parameters from inside SQL Server when it is running:

SELECT value_name, value_data
FROM   sys.dm_server_registry
WHERE  value_name LIKE 'SQLArg%';

When it will not start, the same values are in SQL Server Configuration Manager, on the Startup Parameters tab of the service.

Then check that the SQL Server service account can write to that folder. Configuration Manager shows which account it is. This is the cause I would bet on. If somebody tightened the permissions on the data drive, the service can still open the databases it already has but cannot create a new file, and this is exactly how that shows up.

Then read your own log for the retry line. If the retry with a random name succeeded, your problem was a leftover file with the plain name, and moving MS_AgentSigningCertificate.cer out of the folder fixes it. If the retry failed too, it is permissions.

Tidy the doubled backslash while you are there, because it is untidy, not because it will fix anything.

Why It Only Happens After a Patch

SQL Server runs its upgrade scripts once, at the first start after a cumulative update or a service pack. That is the only time it tries to export this certificate. So a folder permission that has been wrong for a year does no harm, right up until the night you patch, and then the server does not come back.

That timing is worth planning for. Before you patch, check that the service account can write to the data folder. It takes a minute, and you do it while the server is still up.

Error 15240 is not a broken master database, it is one small file that could not be written.

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