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

by

SQL Server 2025 Troubleshooting Guide: Error 2537 — “Table error: object ID %d”

Why This Error Happens

Error 2537 is raised by DBCC CHECKDB/CHECKTABLE when it detects a mismatch between the record size stored in a page header and the actual calculated row size for a table object. This typically results from physical-level database corruption caused by faulty storage hardware, an unexpected power loss or improper shutdown, or a bug in an underlying disk I/O or filter driver. It can also surface after restoring a backup that was already corrupt at the source, or when antivirus/backup software locks or alters .mdf/.ldf files while SQL Server is writing to them.

Step-by-Step Resolution Guide

Step 1: Confirm the Scope of Corruption

  • Open SQL Server Management Studio (SSMS) or sqlcmd and run DBCC CHECKDB('YourDatabaseName') WITH NO_INFOMSGS, ALL_ERRORMSGS;
  • Note the exact object ID referenced in the error and cross-reference it using SELECT OBJECT_NAME(object_id) FROM sys.objects WHERE object_id = <ID>;
  • Check the SQL Server Error Log (default path: C:\Program Files\Microsoft SQL Server\MSSQL17.MSSQLSERVER\MSSQL\Log\ERRORLOG) for correlating I/O warnings or Event ID 823/824.

Step 2: Rule Out Hardware and Driver Issues

  • Open Windows Server 2025 Event Viewer (eventvwr.msc) and inspect the System log under Windows Logs for Disk, NTFS, or Storport errors.
  • Run chkdsk C: /f /r (replace C: with the drive hosting your SQL data files) during a scheduled maintenance window, as this requires a reboot.
  • Temporarily disable third-party antivirus real-time scanning on the *.mdf, *.ndf, and *.ldf paths, or add SQL Server directories to the exclusion list via Windows Security settings.

Step 3: Restore From a Clean Backup (Preferred Fix)

  • Identify your last known-good full backup using RESTORE HEADERONLY FROM DISK = 'D:\Backups\YourDB.bak';
  • Restore to a new database name first to validate integrity: RESTORE DATABASE YourDB_Test FROM DISK = 'D:\Backups\YourDB.bak' WITH MOVE 'YourDB_Data' TO 'D:\SQLData\YourDB_Test.mdf', MOVE 'YourDB_Log' TO 'D:\SQLData\YourDB_Test.ldf';
  • Run DBCC CHECKDB('YourDB_Test') against the restored copy to confirm it is corruption-free before promoting it to production.

Step 4: Run Repair as a Last Resort

  • If no clean backup exists, take the database into single-user mode: ALTER DATABASE YourDatabaseName SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
  • Execute DBCC CHECKDB('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS, ALL_ERRORMSGS; — note this may delete corrupted rows to resolve structural errors.
  • Return the database to multi-user mode: ALTER DATABASE YourDatabaseName SET MULTI_USER;

Alternative or Verification Steps

  • After remediation, re-run DBCC CHECKDB('YourDatabaseName') WITH NO_INFOMSGS, ALL_ERRORMSGS; and confirm it returns zero allocation or consistency errors.
  • If corruption recurs after repair, treat it as a hardware-level symptom — run a full vendor-specific disk diagnostic (e.g., Storage Health in Windows Admin Center) and migrate database files to verified healthy storage.