Fixing "SQL VSS Writer Is Missing" in Veeam Backup

A Veeam Backup & Replication job was completing with warnings instead of success. Every backup of a production SQL Server VM (107 databases) was falling back to crash-consistent mode instead of application-aware processing. The Veeam session log showed one line:

SQL VSS Writer is missing: databases will be backed up in crash-consistent state
and transaction log processing will be skipped.

This was a server we inherited from a former MSP. Six hours and several red herrings later, the root cause turned out to be a single trailing space in a database name.

The quick fix

If you’re here from a search engine, start here. The most commonly overlooked cause of SqlServerWriter failing to register is a database name with a trailing or leading space.

SELECT '#' + name + '#' AS marked_name
FROM sys.databases
WHERE name LIKE ' %' OR name LIKE '% '

sqlcmd -S ".\YOURINSTANCE" -Q "ALTER DATABASE [CONTOSO_SALES ] MODIFY NAME = [CONTOSO_SALES]"
sqlcmd -S ".\YOURINSTANCE" -Q "ALTER DATABASE [NORTHWIND_ANALYTICS ] MODIFY NAME = [NORTHWIND_ANALYTICS]"

Stop-Service SQLWriter -Force
Start-Sleep -Seconds 3
Start-Service SQLWriter
Start-Sleep -Seconds 15
vssadmin list writers | findstr /i "sql"

Writer name: 'SqlServerWriter'

Why this matters

Crash-consistent backups are the equivalent of pulling the power cord. The databases recover, but you lose in-flight transactions and can’t do point-in-time recovery.

Application-aware backups use VSS to quiesce SQL databases before the snapshot, giving you a clean backup with full transaction log support.

Without application-aware processing, transaction logs are never truncated, and log files grow indefinitely until the disk fills up.

How Veeam’s SQL detection works

Understanding the mechanism matters for troubleshooting. During a backup with application-aware processing enabled, Veeam uses two separate code paths:

Path 1: VSS writer enumeration. Veeam deploys its guest agent (VeeamGuestHelper.exe, VeeamVssSupport.dll) inside the VM via the admin share. The agent enumerates all registered VSS writers and looks for SqlServerWriter by its Writer ID ({a65faa63-5ea8-4ebc-9dbd-a0c4db26912a}). If found, Veeam sets hasSql = True and proceeds with application-aware processing. If not found, it falls back to crash-consistent mode.

Path 2: Direct OLE DB connection. Independently of VSS, Veeam connects directly to SQL Server via OLE DB (msoledbsql provider) to collect backup metadata and perform log truncation. This connection can work even when the VSS writer is broken.

This distinction explains a confusing scenario: your backup log might show “SQL log truncation: Ok” while simultaneously warning about crash-consistent mode. The OLE DB path is fine. The VSS path is broken.

Why a trailing space breaks everything

When the SQLWriter service starts, it enumerates every database and registers their files with VSS via IVssCreateWriterMetadata::AddFilesToFileGroup. A database named CONTOSO_SALES (with a trailing space) produces a physical file path like D:\...\CONTOSO_SALES .mdf with a space before the extension. VSS treats this as a collision with the normalized path, and AddFilesToFileGroup fails with 0x80042308 (VSS_E_OBJECT_ALREADY_EXISTS).

The critical part: this exception crashes the entire writer registration. One bad database name out of 107 takes down application-aware backups for all of them. SqlServerWriter never calls Subscribe(), never registers with VSS, and silently sits idle even though the Windows service shows “Running.”

The troubleshooting journey

What follows is the condensed version of the 6-hour investigation. If you’re only here for the fix, you can skip to Diagnostic commands.

vssadmin list writers

Volume Shadow Copy Service error: Failed resolving account YOURDOMAIN\Administrator
with status 1376. Check connection to domain controller and VssAccessControl registry key.

Remove-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\VSS\VssAccessControl" `
    -Name "YOURDOMAIN\Administrator"

Stop-Service SQLWriter
sc.exe config SQLWriter obj= "LocalSystem" type= own
Start-Service SQLWriter

; C:\Program Files\Microsoft SQL Server\90\Shared\SqlWriterConfig.ini
[Logging]
EnableTracing=TRUE
TraceLevel=VERBOSE
TraceFile=c:\Program Files\Microsoft SQL Server\90\Shared\SqlWriterLogger.txt
TraceFileSizeMb=10
ForceFlush=FALSE

[16:53:51] Adding database ADVENTURE_WORKS on instance SQL01\YOURINSTANCE to the metadata.
[16:53:51] Adding file D:\...\ADVENTURE_WORKS.mdf to metadata for database ADVENTURE_WORKS
[16:53:51] Adding file L:\...\ADVENTURE_WORKS_1.ldf to metadata for database ADVENTURE_WORKS
[16:53:51] Adding database CONTOSO_SALES  on instance SQL01\YOURINSTANCE to the metadata.
[16:53:51] Adding file D:\...\CONTOSO_SALES .mdf to metadata for database CONTOSO_SALES
[16:53:51] CSqlWriter::AddComponentAndFiles: IVssCreateWriterMetadata::AddFilesToFileGroup failed.  hr = 0x80042308
[16:53:51] HRESULT EXCEPTION CAUGHT: hr: 0x80042308

SELECT '#' + name + '#' FROM sys.databases WHERE name LIKE ' %' OR name LIKE '% '

Diagnostic commands

A quick reference for troubleshooting SqlServerWriter issues. The trace log tab is the most valuable diagnostic if you’re running SP3 or later.

# List all VSS writers, check if SqlServerWriter is present
vssadmin list writers

# Quick check for just the SQL writer
vssadmin list writers | findstr /i "sql"

# Service configuration (binary path, service account)
sc.exe qc SQLWriter

# Service status
Get-Service SQLWriter | Select Name, Status, StartType

# Check if sqlwriter.exe has any connections (zero = idle/broken)
$pid_sw = (Get-Process sqlwriter).Id
netstat -ano | findstr "$pid_sw"

# Check loaded modules (should include sqlwvss.dll, VSSAPI.DLL)
Get-Process sqlwriter | Select-Object -ExpandProperty Modules | Select ModuleName

# Enable verbose tracing
$ini = "C:\Program Files\Microsoft SQL Server\90\Shared\SqlWriterConfig.ini"
(Get-Content $ini) -replace 'TraceLevel=DEFAULT','TraceLevel=VERBOSE' | Set-Content $ini
(Get-Content $ini) -replace 'TraceFileSizeMb=1','TraceFileSizeMb=10' | Set-Content $ini

# Restart SQLWriter and trigger a writer enumeration
Stop-Service SQLWriter -Force
Start-Sleep 3
Start-Service SQLWriter
Start-Sleep 5
vssadmin list writers > $null 2>&1
Start-Sleep 10

# Read the last 50 lines of the trace log
Get-Content "C:\Program Files\Microsoft SQL Server\90\Shared\SqlWriterLogger.txt" -Tail 50

-- Databases with leading or trailing spaces (most common cause)
SELECT '#' + name + '#' AS marked_name
FROM sys.databases
WHERE name LIKE ' %' OR name LIKE '% '

-- Duplicate logical file names (another potential cause of 0x80042308)
SELECT name, COUNT(*) AS cnt
FROM sys.master_files
GROUP BY name
HAVING COUNT(*) > 1

# Check VssAccessControl for stale account entries
reg query "HKLM\System\CurrentControlSet\Services\VSS\VssAccessControl"

# Check SQLWriter and VSS event logs
Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='SQLWRITER'} -MaxEvents 20 |
    Format-List TimeCreated, Id, LevelDisplayName, Message

Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='VSS'} -MaxEvents 20 |
    Format-List TimeCreated, Id, LevelDisplayName, Message

Lessons learned

1. A single trailing space can break all backups. One database out of 107 had a trailing space in its name. That one name crashed VSS writer registration for every database on the instance. Always check for leading/trailing spaces in database names.

2. sqlwriter.exe can run without registering. The SQLWriter Windows service can be “Running” while doing absolutely nothing. It loads, stays alive, but never calls Subscribe() to register with VSS. Always verify with vssadmin list writers, not just service status.

3. Pre-SP3 sqlwriter has almost no diagnostics. Before SQL Server 2016 SP3, sqlwriter.exe produced almost no diagnostic output. No log file, and often no event log entries. It would silently fail. SP3 added SqlWriterConfig.ini and SqlWriterLogger.txt, which are invaluable. If you’re stuck troubleshooting, upgrade to SP3 just for the diagnostics.

4. Veeam has two separate SQL detection paths. VSS writer enumeration (for the application-aware flag) is separate from the direct OLE DB connection (for log truncation). One can work while the other is broken. A backup showing “SQL log truncation: Ok” but warning about crash-consistent mode means the VSS path is broken, not SQL connectivity.

5. VssAccessControl stale entries are sneaky. The registry key at HKLM\System\CurrentControlSet\Services\VSS\VssAccessControl can contain references to accounts that no longer exist. This causes VSS Warning 8230 on every operation. Clean up entries for deleted or renamed accounts.

6. Event log silence does not mean success. sqlwriter.exe (pre-SP3) can fail to initialize without logging any errors to the Windows Event Log. The only evidence is the absence of the writer in vssadmin list writers and zero network connections. No errors does not mean it’s working.

7. netstat shows the truth. When sqlwriter.exe is running but not registering, check for connections: Get-NetTCPConnection -OwningProcess (Get-Process sqlwriter).Id. Zero connections means the writer is not even trying to connect to SQL Server.

Prevention

• Audit database names periodically. Enforce a naming policy that prohibits leading/trailing spaces. Run this check on a schedule:

  SELECT name FROM sys.databases
  WHERE name LIKE ' %' OR name LIKE '% ' OR name LIKE '%  %'

• Verify VSS after any SQL Server upgrade or patching. Run vssadmin list writers and confirm SqlServerWriter is present. Check that the next Veeam backup completes without VSS warnings.
• When taking over from another MSP, check shared component versions against instance versions, and audit database names for anomalies during the initial assessment.
• Upgrade to SP3 (or apply the latest cumulative update) for the SqlWriterLogger.txt diagnostic logging. It is invaluable for troubleshooting writer registration failures.
• Monitor Veeam job status, not just failures. A job completing with “Warning” due to crash-consistent fallback can go unnoticed for months while transaction logs silently grow.

Related reading

If you’re building out monitoring to catch issues like this before they go unnoticed for months:

External resources

• Veeam: Application-Aware Processing on how Veeam interacts with VSS writers during backup
• Microsoft: Volume Shadow Copy Service for the full VSS architecture and writer lifecycle
• Microsoft: SQL Server 2016 SP3 Release Notes including the SqlWriterLogger diagnostic logging addition
• Veeam Best Practices: Microsoft SQL Server covering backup modes, log truncation, and application-aware configuration