SQL SERVER – Error 33222, Level 16 – Audit ‘MyAudit’ Failed to Start

I first hit Error 33222 years ago on SQL Server 2016. I reproduced the whole thing again on SQL Server 2025 to write this, and it behaves identically. The interesting part is not the fix, which is one line. It is that CREATE SERVER AUDIT told me everything was fine when it was not.

What I Ran

Two statements. Make an audit that writes to a folder, then switch it on.

USE master;
GO
CREATE SERVER AUDIT MyAudit
TO FILE (FILEPATH = 'C:\SQLAuditLab\NoAccess');
GO
ALTER SERVER AUDIT MyAudit WITH (STATE = ON);
GO

The first statement succeeded. The second one did this:

Msg 33222, Level 16, State 1
Audit 'MyAudit' failed to start . For more information, see the SQL Server
error log. You can also query sys.dm_os_ring_buffers where ring_buffer_type
= 'RING_BUFFER_XE_LOG'.

Note the stray space before the full stop. It has been there for years. I find it oddly comforting. More usefully, this is one of the few SQL Server errors that tells you where to go next. Most leave you guessing.

The Part That Deserves the Blame

Look again at the order of events. CREATE SERVER AUDIT succeeded. The audit exists. It is stored. It looks correct in every catalogue view. SQL Server never tried to write to that folder.

It did check something. I pointed a second audit at a folder that does not exist at all, and it refused immediately:

CREATE SERVER AUDIT MyAudit2
TO FILE (FILEPATH = 'C:\SQLAuditLab\DoesNotExist');

Msg 33072, Level 16, State 1
The audit log file path is invalid.

So at create time SQL Server checks that the folder is there. It does not check that it can write into it. That gap is the whole problem. The statement that was wrong succeeded. The statement that reported the failure was innocent.

This matters more than it sounds. Build audits in one deployment script and start them in another, and the failure lands a long way from its cause. Same if a pipeline creates them on Friday and somebody enables them on Monday.

Where the Real Reason Is

The ERRORLOG carries the whole story, and it is worth reading all four lines rather than only the first one you see.

Audit: Server Audit: 65536, Initialized and Assigned State: NOT_STARTED
Audit: Server Audit: 65536, State changed from: NOT_STARTED to: TARGET_CREATION_FAILED
SQL Server Audit failed to create the audit file
  'C:\SQLAuditLab\NoAccess\MyAudit_3D6AF836-...-8D411F99011B_0_134345684665320000.sqlaudit'.
  Make sure that the disk is not full and that the SQL Server service account
  has the required permissions to create and write to the file.
SQL Server Audit failed to create an audit file related to the audit 'MyAudit'
  in the directory 'C:\SQLAuditLab\NoAccess'.

TARGET_CREATION_FAILED is the phrase to look for. The target is the file, and creating it failed.

The Ring Buffer, Since the Error Recommends It

The message points you at RING_BUFFER_XE_LOG. Fair enough. The shape of those records is not obvious though, and most versions of this query shred XML paths that return nothing. This one works:

SELECT TOP 5
       CAST(record AS xml).value('(Record/XE_LogRecord/@message)[1]', 'varchar(300)') AS message
FROM   sys.dm_os_ring_buffers
WHERE  ring_buffer_type = 'RING_BUFFER_XE_LOG'
ORDER BY timestamp DESC;

Target 'asynchronous_security_audit_file_target' creation failed and did not
call SetLastError().
file: file create or open failed (last error: 5)

Last error 5 is the Windows code for access denied. That is the answer, in one number, and it confirms what the ERRORLOG suggested. If you ever see last error 3 instead, that is path not found, and 112 is a full disk.

A Simpler Place to Look

The error message never mentions this one, and it should. There is a dynamic management view whose whole job is the state of your audits:

SELECT audit_id, name, status_desc, audit_file_path
FROM   sys.dm_server_audit_status;

audit_id  name     status_desc             audit_file_path
65536     MyAudit  TARGET_CREATION_FAILED  NULL

One row, the answer in plain words, no XML. This is where I go first now. It also belongs in your morning round. An audit that stopped overnight shows up here and nowhere else you would look.

Compare that with the catalogue view, which happily reports the audit as existing and says nothing about it being broken:

SELECT name, is_state_enabled, on_failure_desc
FROM   sys.server_audits;

The Fix

Give the SQL Server service account permission to write to that folder. First find out which account that is, because guessing is how people grant rights to the wrong one:

SELECT servicename, service_account, status_desc
FROM   sys.dm_server_services;

Mine came back as NT Service\MSSQL$SQLDEV. That per-service name is the default on a modern install. It is not a domain account, so do not go looking for it in Active Directory.

Then grant it full control on the folder. Right click, Properties, Security, Edit, Add works fine. From the command line it is one line:

icacls "C:\SQLAuditLab\NoAccess" /grant "NT Service\MSSQL$SQLDEV:(OI)(CI)F"

One warning from my own afternoon. Run that in PowerShell with double quotes and PowerShell reads the dollar sign as a variable. It eats your instance name. You get a mapping error that looks like the account does not exist. Use single quotes around the whole thing.

Then switch the audit on again. No need to drop it or recreate it, and I changed nothing about the audit itself:

ALTER SERVER AUDIT MyAudit WITH (STATE = ON);

SELECT audit_id, name, status_desc, audit_file_path
FROM   sys.dm_server_audit_status;

65536  MyAudit  STARTED  C:\SQLAuditLab\NoAccess\MyAudit_3D6AF836-...sqlaudit

STARTED, and the file path is now filled in rather than NULL. That column being NULL is itself a tell.

Before You Set This Up for Real

Three things I would think about, having watched this fail.

Put audit files in their own folder, on a drive that is not holding your data files. An audit that fills a disk is a worse problem than one that never started.

Look hard at ON_FAILURE before you choose it. The default is CONTINUE, so SQL Server carries on serving if the audit cannot write. SHUTDOWN and FAIL_OPERATION exist for when the audit matters more than availability. They do exactly what their names say. I did not test SHUTDOWN, for reasons that are probably obvious, and neither should you on anything you care about.

Set MAX_ROLLOVER_FILES and MAX_SIZE deliberately rather than taking the defaults. Unlimited is a choice, not an absence of one.

And add sys.dm_server_audit_status to whatever you already check each morning. An audit only protects you while it is running, and nothing will tell you it stopped.

33222 is not the audit refusing to start, it is Windows refusing to hand over a file.

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