Error 845 Time-out occurred while waiting for buffer latch type 4 during DBCC CHECK

---

The Symptom

A customer reported that running DBCC CHECKTABLE on several different tables kept failing with the exact same error:

Msg 845, Sev 17: Time-out occurred while waiting for buffer latch type 4 for page (1:27527325), database ID 10.
Msg 1823, Sev 17: A database snapshot cannot be created because it failed to start.
Msg 7928, Sev 17: The database snapshot for online checks could not be created.

And when I’m saying “exact same error”, I mean it in the absolute literal sense – the EXACT same error, including the exact same page resource ID inside the parenthesis… Which was very strange since this error was happening for different tables, and yet the PageID in the parenthesis was the same for all of them.

This was puzzling:

• Different tables being checked
• Same exact page (1:27527325)
• Same database ID
• Latch type 4 (SH latch)

The question must be asked: How could unrelated tables fail on the same page with a latch timeout? And aren’t latches supposed to be, like, super-quick?

---

The Investigation

Normally, error 845 indicates that SQL Server experienced contention issues related to buffer latches. Specifically, latch type 4 is a SH (Shared) latch that SQL Server uses while reading pages into memory. The timeout suggests severe contention or a stalled I/O operation.

Possible Causes:

• Heavy I/O contention or slow disk subsystem.
• Page corruption or hardware issues.
• Excessive concurrent operations causing latch contention.

I first identified that the reported page (1:27527325) belonged to a certain table. Let’s call it dbo.tbl_Accounts. Strangely enough, this wasn’t even one of the tables that was being checked.

Running DBCC CHECKTABLE on that table got the session stuck on a PAGELATCH_EX wait on the exact same page ID as in the other errors. Cancelling it was the only way to free the session, and in the meantime, it had already started blocking other processes. (sorry, end users!)

I tried duplicating the table:

SELECT *
INTO tbl_Accounts_NEW
FROM tbl_Accounts WITH (NOLOCK);

Surprisingly, this succeeded without errors. Had this been a corruption issue, I probably would have gotten an error here.
But running DBCC CHECKTABLE on the new table still triggered the same page latch wait on (1:27527325).

Next, just to make sure, I ran the command using WITH TABLOCK:

DBCC CHECKTABLE('tbl_Accounts_NEW') WITH TABLOCK;

It finished successfully in less than a second.

Interesting. Now I started feeling a little bolder. I ran the same command with WITH TABLOCK on the original table and – it also completed instantly.

Why? Because WITH TABLOCK forces offline checks and skips the creation of the database snapshot that DBCC CHECKTABLE normally uses for online verification.

---

Root Cause

This wasn’t a case of physical corruption. It was a case of severe latch contention on that specific page in memory.

In SQL Server, DBCC CHECKTABLE and DBCC CHECKDB run against a database snapshot by default. The snapshot creation process needs to read every allocated page, including (1:27527325).

For some unknown reason, that page was stuck in a latch wait, snapshot creation got stalled and eventually timed out.
And because all DBCC commands shared the same snapshot creation step, unrelated tables failed on the same page.

---

The Fix

The only way to resolve this was to restart or fail-over the SQL Server database.

This would flush the buffer pool and should clear the stuck latch. I know, it’s an extreme measure, but that was the only solution in this case.

After the restart, DBCC CHECKTABLE and DBCC CHECKDB ran successfully without using WITH TABLOCK, and no latch timeouts occurred.

---

Lessons Learned

1. A single stuck page in memory can block all online consistency checks, even for unrelated tables.
2. WITH TABLOCK is your friend for bypassing snapshot creation during troubleshooting.
3. If possible, a failover can be a quick way to clear latch contention without waiting for a maintenance window. But a restart to the SQL Server service will also help.
4. Always run a follow-up integrity check after the issue clears to confirm there’s no underlying corruption.
5. Keep an eye on I/O metrics. Latch contention this severe can be an early sign of storage latency or subsystem issues.

---

Final Thoughts

This case was a perfect reminder that not all DBCC failures mean corruption. Running DBCC CHECK commands online (without TABLOCK) are not without impact. They require latch locks at a minimum. And, as it turns out, it’s possible for a latch lock to be “stuck” in memory and the only way to clear it is by restart or failover.