---
title: "SQL Server Deadlock XML Viewer"
description: "Free SQL Server deadlock XML viewer: open an .xdl or Extended Events deadlock report in your browser on Mac, Windows or Linux. Nothing is uploaded."
url: "https://jamsql.com/tools/deadlock-viewer/"
html_url: "https://jamsql.com/tools/deadlock-viewer/"
generated: "2026-09-20T00:14:45.528Z"
---

# SQL Server Deadlock XML Viewer

Open an `.xdl` file or paste a SQL Server deadlock report and see the victim, the processes, the locked resources and the owner/waiter edges as a graph with the execution stacks and input buffers next to it. Works on Mac, Windows and Linux. The XML is parsed in your browser; nothing is uploaded.

Report file  Load sample Clear .xdl or .xml, up to 10 MiB. Binary .xel files are not readable here.

Or paste the deadlock XML

Owner (holds the lock) Request (waits for the lock) Victim's request

Raw XML of the selected incident

## Inspect deadlocks from your SQL Server connection in Jam

The desktop Deadlock Analyzer opens the same files with the same parser, and reads retained `xml_deadlock_report` events from a connected server's `system_health` session so you do not have to export them by hand.

[Get Jam SQL Studio — free](/#download) [Setup and permissions](/docs/deadlock-analyzer/)

Pick a file, paste a report or click **Load sample**. The graph, the incident list for multi-incident reports and the details pane appear here.

## What a SQL Server deadlock graph shows

When two or more sessions each hold a lock the other needs, none of them can finish. SQL Server's lock monitor detects the cycle, rolls back one session (the **victim**, error 1205) and writes a deadlock report: an XML document with a `<victim-list>`, a `<process-list>` (one `<process>` per session or parallel worker, with its execution stack and input buffer) and a `<resource-list>` (one element per lock — `keylock`, `pagelock`, `objectlock` and others — each listing its `<owner>` and `<waiter>` processes with lock modes). SSMS saves this as an `.xdl` file.

The viewer draws that report as a two-column graph: processes on the left, resources on the right. A solid edge from a resource to a process means the process *owns* the lock in the given mode; a dashed edge from a process to a resource means the process *requests* it. The victim carries a red badge and its request edge is red. Graph identities are the report's process ids (for example `process24ab8c8`), not SPIDs, because parallel workers of one query share a SPID and differ only by ECID.

## Example: two processes, two key locks

Two processes each own a key lock the other one requests; SPID 62 is the victimSPID 62suspended · lock U · usp\_ReserveStockVictimSPID 71suspended · lock X · usp\_ShipOrderSalesDb.dbo.OrdersKey lock (PK\_Orders) · mode XSalesDb.dbo.InventoryKey lock (PK\_Inventory) · mode UOwner: URequest: UOwner: XRequest: X
*The built-in sample (click **Load sample** above). SPID 62 runs `usp_ReserveStock`: it owns a U lock on a key of `SalesDb.dbo.Inventory` and requests a U lock on a key of `SalesDb.dbo.Orders`. SPID 71 runs `usp_ShipOrder`: it owns the X lock on that `Orders` key and requests an X lock on the `Inventory` key. Each waits for the other, so SQL Server rolls back SPID 62 — the process that had written less transaction log (`logused="312"` against `1164`). The two procedures touch the same tables in opposite order; making the access order consistent is the usual fix. The sample is synthetic: object names, hosts and logins are invented.*

## Supported formats and limits

-   **Wrappers:** a bare `<deadlock>` (the `.xdl` SSMS saves), a `<deadlock-list>` with several incidents (trace flag 1222 style), a single Extended Events `<event name="xml_deadlock_report">`, and `<RingBufferTarget>` / `<events>` exports with many events. Multi-incident reports get an incident list with the event timestamp, the victim and the process/resource counts.
-   **Encodings:** UTF-8 with or without a byte-order mark, UTF-16 LE and UTF-16 BE (detected from the BOM or the leading `<` code unit).
-   **Size:** 10 MiB per file or paste, at most 64 nesting levels, 250,000 XML elements and 500 incidents. Larger input is rejected with a message; nothing is silently cut.
-   **Not supported:** `.xel` is the binary Extended Events file format, not XML — export the events as XML/XDL first, or read them from the server with the desktop app. Documents that declare a DTD or entities (`<!DOCTYPE>`, `<!ENTITY>`) are rejected before parsing; external resources are never fetched.

## Everything stays in your browser

The page loads one script that contains the same parser the Jam SQL Studio desktop app uses. Your file or paste is read by that script, parsed in memory and rendered as text and SVG. It is not sent to any server, not placed in the URL, and not written to `localStorage` or `sessionStorage`. Analytics record only that a parse succeeded and an incident-count bucket — never the XML, SQL text or file name. **Clear** drops the report from memory.

## Limitations

-   The graph proves what SQL Server wrote: who owned and who requested which lock in which mode when the deadlock monitor ran. It does not prove why the statements ran in that order or that any change is safe.
-   Resource kinds that are not lock resources — `exchangeEvent` (parallelism), `threadpool` and unrecognised elements — are drawn with a dashed border and a **Partial** badge. Their owner/waiter entries and attributes are shown verbatim; no blocking relationship is derived from them.
-   Missing optional fields (no victim, a resource without an `id`, an owner that is not in the process list) are listed as warnings in the overview, not filled in with guesses.
-   The browser viewer reads files and pasted text only. Collecting incidents from a live server is done by the desktop app.

## Inspect deadlocks from your SQL Server connection in Jam

Jam SQL Studio's Deadlock Analyzer opens `.xdl` and XML reports on macOS, Windows and Linux with this same parser, and reads the retained `xml_deadlock_report` events from a connected server's `system_health` session without creating or altering any Extended Events session. Azure SQL Database has no `system_health`; there, import the reports from your own session.

[Get Jam SQL Studio — free](/#download) [Setup and permissions](/docs/deadlock-analyzer/)

## Frequently asked questions

### Can I open an XDL file on Mac?

Yes. An .xdl file is plain XML, so this page opens it in any current browser on macOS, Windows or Linux: pick the file or paste its contents. SQL Server Management Studio is Windows-only, but the report itself is not. For files from your own server, the Jam SQL Studio desktop app opens .xdl and .xml reports on all three operating systems.

### Does this upload my deadlock XML?

No. The file or pasted text is parsed by JavaScript running in your browser and kept in memory only. It is not sent to a server, not put in the URL, and not written to local or session storage. Analytics record that a parse succeeded and an incident-count bucket, never the XML, SQL text or file name. Clear drops the report from memory.

### What is the victim in a deadlock graph?

The victim is the process SQL Server chose to roll back so the other participants could continue. It is recorded in the report's victim-list and marked with a red Victim badge in the graph. By default SQL Server picks the process that is cheapest to roll back (least transaction log used) unless a session raised its DEADLOCK\_PRIORITY.

### Can this fix the deadlock automatically?

No. The viewer shows what the report proves: which process held or requested which lock, in what mode, and which process was chosen as the victim. It does not generate corrective SQL or claim a root cause. Use the execution stacks and input buffers to find the statements, then decide on access order, transaction scope, index or isolation-level changes yourself.

### How do I get deadlock reports from my server?

SQL Server and Azure SQL Managed Instance record every deadlock as an xml\_deadlock\_report event in the built-in system\_health Extended Events session; export the events as XML or .xdl (for example from SSMS's Extended Events viewer) and open them here. Azure SQL Database has no system\_health session, so you need your own Extended Events session that captures xml\_deadlock\_report. Jam SQL Studio's desktop Deadlock Analyzer opens the same files and can read the retained system\_health events directly from a connected server.

## More free SQL tools

[

### SQL Formatter

Format T-SQL, PostgreSQL, MySQL, PL/SQL, and SQLite queries.

](/tools/sql-formatter/)[

### SQL IN Clause Generator

Turn a pasted list into a quoted, escaped, deduplicated IN (...) list.

](/tools/sql-in-clause-generator/)[

### Connection String Converter

Parse and convert ADO.NET, JDBC, URL, and libpq connection strings.

](/tools/connection-string-converter/)