Fix STATUS_FILE_IDENTITY_NOT_PERSISTENT (0XC0190036) in SQL Server
This error means SQL Server can't verify a file's identity after a restart. The fix is usually a database consistency check or a file path update.
You're stuck with this error, and it's annoying
You're trying to start SQL Server or access a database, and instead you get STATUS_FILE_IDENTITY_NOT_PERSISTENT (0XC0190036). I've seen this on Windows Server 2019 and SQL Server 2017, usually after an unexpected shutdown, a drive letter change, or a SAN migration. The database won't come online, and logs show the error. Here's the fix.
First, check the file paths
Run this query in master (if SQL Server starts at all):
SELECT name, physical_name, state_desc FROM sys.master_files WHERE database_id = DB_ID('YourDatabaseName');If the path shows a drive or folder that doesn't exist anymore—like E:\Data\ but the drive is now F:\—that's your problem. Update it with:
ALTER DATABASE YourDatabaseName MODIFY FILE (NAME = 'logical_filename', FILENAME = 'F:\Data\YourDatabase.mdf');Then restart SQL Server. Had a client last month whose SAN admin swapped drive letters during maintenance. Took me 10 minutes to fix this way.
If paths look right, run DBCC CHECKDB
The error can also mean the file's internal identity metadata (like file GUID or LSN chain) is corrupted or inconsistent. This happens after a crash during a write operation. Fire up SQL Server in single-user mode and run:
ALTER DATABASE YourDatabaseName SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DBCC CHECKDB('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS);
ALTER DATABASE YourDatabaseName SET MULTI_USER;Warning: REPAIR_ALLOW_DATA_LOSS can delete rows. Only use this if you have a backup or the data isn't critical. I'd always try DBCC CHECKDB with REPAIR_REBUILD first (it's safer), but the 0XC0190036 error usually needs the data loss option because the file identity itself is toast.
Why this fix works
SQL Server tracks each file's unique identifier in the sys.master_files and the file header. When you restart, it compares the stored identity to what's on disk. If they don't match—wrong drive, corrupted header, or a file that was copied without the identity metadata—you get 0XC0190036. DBCC CHECKDB rewrites the header metadata, forcing the identity to match. Updating the path does the same via metadata repair.
Less common variations
- Database restored from a backup to the wrong location: If you restored a backup but the files landed in the default data directory instead of the custom path, the identity won't match. Use
RESTORE FILELISTONLYandRESTORE ... WITH MOVEto correct it. - File-level corruption from disk errors: Run
CHKDSK /Ron the drive. If the disk has bad sectors, fix those first, then run DBCC CHECKDB again. - Snapshot or replica issues in Always On: For Availability Groups, the secondary replica might show this after a failover if the file paths differ. Standardize file paths across replicas to avoid it.
Prevention for next time
Don't rely on manual file moves. Use ALTER DATABASE ... MODIFY FILE for any path change. Always test failovers with identical drive letters. And take a full backup before any SAN or storage change—I learned this the hard way when a client lost a weekend because of a forgotten drive remap.
Bottom line: 0XC0190036 is SQL Server's way of saying "I can't trust this file's history." Fix the path, fix the header, and you're back in business. Don't waste time with service restarts or Windows updates—they won't help.
Was this solution helpful?