How to fix Error 810 on Windows Server 2025 / Windows 11

by

Troubleshooting Guide: SQL Server Error 810

Why This Error Happens

Error 810 occurs when SQL Server’s I/O subsystem receives an unexpected error code from the operating system while attempting to read from or write to a database file at a specific byte offset. While this error is designed to surface primarily in Azure SQL Database environments, its appearance on an on-premises Windows Server 2025 or Windows 11 instance typically indicates underlying storage corruption, a failing disk, filesystem-level inconsistencies, or interference from antivirus/backup software locking the file mid-operation. In most cases, this points to a breakdown in the reliability of the storage layer rather than a SQL Server configuration issue.

Step-by-Step Resolution Guide

Step 1: Run DBCC CHECKDB Immediately

  • Open SQL Server Management Studio (SSMS) and connect to the affected instance.
  • Execute DBCC CHECKDB ('YourDatabaseName') WITH NO_INFOMSGS, ALL_ERRORMSGS; to identify the scope of corruption.
  • Review the output for allocation errors, consistency errors, or specific page IDs flagged as damaged.
  • Document the exact file path and offset mentioned in the original Error 810 message for cross-referencing.

Step 2: Check Windows Event Viewer and Disk Health

  • Navigate to Event Viewer > Windows Logs > System and filter for Event ID 7, 11, or 51 (disk-related warnings).
  • Run chkdsk C: /f /r (or the appropriate drive letter hosting your .mdf/.ldf files) from an elevated Command Prompt; a reboot may be required if the volume is in use.
  • For SAN or virtualized storage, verify with your storage administrator that no underlying LUN or RAID array failures are occurring.
  • Check wevtutil qe System /q:"*[System[Provider[@Name='disk']]]" /f:text for low-level hardware fault logs.

Step 3: Exclude SQL Server Files from Antivirus and Backup Agents

  • Open your antivirus console (Windows Defender or third-party) and add exclusions for .mdf, .ndf, .ldf, and the full path of C:\Program Files\Microsoft SQL Server\MSSQL17.MSSQLSERVER\MSSQL\DATA\.
  • Disable any third-party backup agent “open file” scanning features temporarily to rule out file-lock conflicts.
  • Restart the SQL Server service via services.msc or net stop MSSQLSERVER && net start MSSQLSERVER to clear any stale file handles.

Step 4: Restore from a Known-Good Backup if Corruption Persists

  • If DBCC CHECKDB reports unrepairable corruption, locate your most recent verified full backup.
  • Use RESTORE DATABASE YourDatabaseName FROM DISK = 'E:\Backups\YourDatabase_Full.bak' WITH REPLACE, RECOVERY; to restore to a clean state.
  • Apply any subsequent differential or transaction log backups in sequence to minimize data loss.

Alternative or Verification Steps

  • After remediation, re-run DBCC CHECKDB ('YourDatabaseName') WITH NO_INFOMSGS; and confirm zero allocation or consistency errors are returned.
  • If errors recur on the same physical offset, treat it as a hardware fault — move the database files to a different physical disk or storage volume using ALTER DATABASE ... MODIFY FILE and monitor for recurrence.