How to read a SQL Server deadlock graph
A deadlock graph (captured via Extended Events or trace flag 1222) is XML, and it's dense — but it always has the same three parts:
1. <victim-list>
Which process(es) SQL Server killed to break the deadlock.
2. <process-list>
One <process> entry per session involved, each showing:
- The exact query it was running (inputbuf or executionStack)
- What it already held a lock on
- What it was waiting for
- Its isolationlevel, login, and host
3. <resource-list>
The actual objects/index keys being fought over, and which process owned vs. waited on each one.
How to actually use this to fix the deadlock
- Find the two competing queries in process-list — this is almost always the useful part.
- Match each query to a resource in resource-list — one process holds resource A and wants B, the other holds B and wants A. That crossed pattern is the deadlock.
- Check whether both queries touch the same tables in a different order — this is the #1 real-world root cause and the fix is usually as simple as standardizing access order.
- Check the indexes each query used (or didn't) — a missing index often forces a wider lock than necessary, making deadlocks far more likely under concurrency.
Reading the raw XML by hand works, but it's slow and easy to misread which side is which.
Paste your full deadlock XML here and get the victim, the two competing queries, the exact resource conflict, and a fix — all translated to plain English in seconds.
Try Deadlock Analyzer free →