SQL Server Database Corruption after Unexpected VM Shutdown

Virtual Machines may unexpectedly crash or stop responding due to various reasons, like misconfigured VM settings, hardware component issues, software failure, etc. After a sudden VMware or Azure VM shutdown, you may face consistency issues in the SQL database. This occurs because the virtualization layer often uses host-level write-back caching.

According to a Microsoft document on Virtual machine and disk performance, when this setting is enabled, it intercepts data writes, holds them in volatile host RAM, and prematurely tells the VM that the data is safely saved on the physical disk. When a sudden crash happens, the data in volatile RAM is deleted, violating SQL Server’s strict Write-Ahead Logging (WAL) protocol and causing mismatched or torn data pages.

If the SQL database is corrupted due to write-back caching, you may fail to access the tables or encounter errors when trying to open them. In this blog, we will learn methods to resolve SQL Server database corruption after unexpected VM shutdown.

How VMware/Hyper-V Shutdown can Corrupt SQL Server Database?

Some of the major causes of corruption in a SQL database after VM crash include:

• Deleted Transaction Log Records due to Hypervisor Write-Caching: Hypervisors cache data in RAM but report it as saved. If the VM crashes unexpectedly, the RAM instantly loses power. Because the hypervisor acknowledges the data as safe on disk but postpones the actual write to primary storage, it can cause page mismatches and result in database corruption.

• Torn Pages due to VM Failure in the Middle of Write Operation: SQL Server writes data in pages of 8KB in size, but disks write in smaller 512-byte or 4KB sectors. If the VM crashes while writing an 8KB page, only some sectors are saved, causing a partial page write (torn page). This can result in the error 824 and force the database into suspect mode.
• Virtual Disk/Driver Issues: If the VM shuts down unexpectedly, it impacts the virtual disk controllers and hypervisor paths, causing the error 825. According to the Microsoft guide, the error 825 is a read-retry warning that indicates an issue with the disk controller or drivers.
• Broken WAL Protocols due to Mismatched Disk Logs: SQL Server writes changes to the transaction log file (.ldf) before updating the .mdf file as per the Write-Ahead Logging (WAL) protocol. The hypervisor intercepts these log writes, saves them quickly into a volatile RAM cache, and reports to SQL Server that the data is safely secured on the disk. During a sudden VM shutdown, that cached log data is permanently lost from the volatile RAM, but the modified data pages remain written to the disk. When you reboot the system, SQL Server finds a mismatch and fails to read the broken log sequence, triggering the error 9004.

Common SQL Server Errors after Unexpected VM Shutdown

The table below explains some common SQL Server errors/issues that occur after an abrupt VM power-off:

Troubleshooting SQL Database Corruption after VM Shutdown

The core functionality of SQL Server is the same in a virtual setup. If your SQL database gets corrupted or inaccessible, you can follow these steps for database recovery:

Step 1 — Check the SQL Server Error Log and Windows Event Log

To confirm that an unexpected VM shutdown caused corruption in the database, you can check the SQL Server Error Log and Windows Event Log. The Windows System Log records all events related to the operating system’s operations, including startup and shutdown processes, abrupt hypervisor disconnects, system errors, and hardware issues. You can open Event Viewer on your Windows and look for Event IDs associated with unexpected crashes or power loss, such as Event ID 41 (Kernel-power), Event ID 6008, or Event ID 129.

You can also check the SQL Error Log for corruption-related errors, like 823, 824, or 9004. It will also help you to find out what and why these errors occur. To check the Error Log, open SSMS and then follow these steps:

• Go to the Management section under Object Explorer.

• Next, click SQL Server Logs > View > SQL Server Log.

Step 2 — Check the Database State

Next, check the current status of your database. SQL Server alters the database state depending on the severity of corruption. If the database is marked as RECOVERY_PENDING, this means SQL Server is completely blocked from accessing or opening the database file (.mdf or .ldf). This state often occurs due to missing files after the crash. To resolve this issue and recover the database from this state, read our guide on: How to Fix Recovery Pending State in SQL Server Database [2026].

If the database is marked as SUSPECT, this means SQL Server successfully opened the database files but failed to complete the crash recovery. This happens due to torn pages and corrupted transaction log files after the VM crash. To resolve this issue and recover the database online with no data loss, refer to this guide: How to Recover MS SQL Database from Suspect Mode.

Step 3 — Run DBCC CHECKDB to Assess the Damage 

You can run the DBCC CHECKDB command to check the specific tables, pages, and indexes that got corrupted after the VM crash. This command checks the structural allocation and logical integrity of the database. In case of failure of any of the checks, it shows consistency errors and  recommends the required fix according to the level of corruption. Here’s the command:

DBCC CHECKDB ( [anney]);

If you want to prevent the output from displaying the informational messages, then you can add the NO_INFOMSGS and ALL_ERRORMSGS arguments in the command (see the example below).

DBCC CHECKDB ('anney') WITH NO_INFOMSGS, ALL_ERRORMSGS;

Step 4 — Restore from Backup

Before using the repair command suggested by DBCC CHECKDB, it is recommended to try restoring the database from backup. To restore the SQL Server backup, use the RESTORE command as given below:

USE master;

GO

RESTORE DATABASE [anney]

FROM DISK = 'C:\Backups\anney_backup.bak'

WITH REPLACE, RECOVERY;

GO

You can also restore backup using SSMS, PowerShell, and Visual Studio Code. To learn more, read our blog on: How to Restore Database in SQL Server from .Bak File Step By Step.

Step 5 — Repair the Database

If the backup file is not available or is corrupted, then you can use the repair option recommended by the DBCC CHECKDB command to fix the SQL database. Depending on the severity of the corruption, you can use the following options with command:

• REPAIR_FAST: To rebuild the database quickly. It only maintains syntax for backward compatibility.
• REPAIR_REBUILD: It can help resolve minor corruption in the database. It does not resolve complex corruption issues in the database.
• REPAIR_ALLOW_DATA_LOSS: It fixes a severely corrupted database by deleting the damaged data pages. It reallocates the rows or pages, which can lead the database to a logically inconsistent state. As it causes data loss, use it as a last resort.

To learn how to use these commands, read our comprehensive guide on How to repair SQL database using DBCC CHECKDB command.

When Native SQL Repair Methods Fail – Use a Professional SQL Repair Tool

Although the DBCC CHECKDB command can resolve corruption issues in database, it is not powerful enough to deal with complex corruption issues and can also result in data loss. If the SQL database is severely corrupted, then you can use Stellar Repair for MS SQL. This powerful SQL repair tool can recover all the elements, including keys, pages, indexes, and stored procedures, from the corrupt database (MDF/NDF) file with 100% precision. It saves the repaired file in a new database file and multiple other formats.

Here’s how to use Stellar Repair for MS SQL to repair corrupt database:

Step 1: First, isolate the corrupt SQL database file. For this, open SQL Server Management Studio (SSMS) in the Windows VM, right-click on the corrupt database, click Tasks, and select Take Offline. Alternatively, open Command Prompt with administrator rights in the Windows VM and run net stop MSSQL$InstanceName command to stop the service. Next, create a copy of the database as a backup.

Step 2: Download, launch, and install Stellar Repair for MS SQL on the VM.

Step 3: Click the Browse option to select the corrupt database and click Repair.

Step 4: Select Standard Scan or Recommended Scan. Click OK.

Step 5: In the Select Database Version dialog box, choose the appropriate option to match the version of the corrupt SQL database (MDF). Click OK.

Step 6: The tool starts repairing the MDF file. Once the repair process is complete, it displays all the repaired objects.

Step 7: Click Save option to save the repaired MS SQL database file. 

To learn more about this tool, watch this video.

Note: If you’ve a small database (MDF) file of 500 MB size, then you can use Stellar Online SQL Repair service to repair it for free, without installing any software.

How to Prevent Corruption during VM Shutdown?

Here are some best practices to prevent data loss when the hypervisor shuts down:

Implement VSS-Aware Backups

According to Microsoft documentation, Volume Shadow Copy Service acts as a coordinator between the hypervisor, the guest Windows operating system, and the running application to flush data safely to the disk before power-off. It helps prevent database corruption by ensuring application-consistent VM backups. Make sure the Volume Shadow Copy Service (VSS) integration feature is enabled.

Use PAGE_VERIFY CHECKSUM Option

Enable the PAGE_VERIFY CHECKSUM option to isolate disk corruption immediately after a VM crash. SQL Server calculates a unique value when writing an 8KB data page to disk and verifies it upon reading. If an abrupt VM shutdown damages a page, the SQL engine detects it immediately and stops the operation. This helps in preventing corrupt data from spreading.

Use UPS for Safe Shutdown

Sudden power loss can cause database corruption. You can use an Uninterruptible Power Supply (UPS) for a graceful virtual machine shutdown. This gives the server enough time to safely complete the current transactions..

Schedule Regular Transaction Log Backups

Take transaction log backups of your database every 10-15 minutes. This helps to minimize data loss by allowing you perform a point-in-time recovery up to the moment right before the VM failure occurred.

Conclusion

An unexpected VM crash can lead to corruption in the SQL database. In this blog, we have discussed the troubleshooting solutions to repair and restore a corrupt MS SQL database after a virtual machine shutdown. If the recent backup is available and is readable, then you can restore the database from the backup. If the backup file is corrupted, you can use the DBCC CHECKDB command to repair the database. The quickest and best method is to use Stellar Repair for MS SQL to repair the database within minimal time. It supports repairing database files created in SQL Server 2025 and lower versions with ease.

FAQs: