Michael J. Swart

March 15, 2018

“Failed to initialize deadlock control, Key cannot be null” When Viewing Deadlock Graphs

Filed under: SQLServerPedia Syndication — Michael J. Swart @ 10:02 am

I recently got this error in Management Studio when trying to view a deadlock graph that was collected with an extended events session:

Failed to initialize deadlock control.
    Key cannot be null.
    Parameter name: key

I found this error in a session that included the xml_deadlock_report event. I chose to “View Target Data” and then clicked the deadlock tab:

So I couldn’t view the deadlock graph, but the xml for the deadlock was still accessible. I copy-pasted the deadlock graph information into an xdl file, I opened it in management studio and I still got the same error.

No luck in Management Studio, but SentryOne’s Plan Explorer had no trouble displaying the deadlock graph visually. In fact it kind of helped me figure out what’s going on:

I noticed a number of things:

  • The resource list is full of “exchangeEvent” elements (which has to do with parallelism) and not the usual key locks I’m used to seeing.
  • The “processes” are all the same process, just different threads (The spids on all processes are the same but the ecids are different)
  • Most importantly, there is no victim here! And our application that issued the query didn’t receive an error from the database.

My guess is that the deadlock monitor detects this kind of deadlock cycle, but knows how to resolve it without choosing a victim and then issues a deadlock report any way.

The reason that the management studio can’t display the deadlock is because it assumes that there is at least one victim in a deadlock graph.

The original deadlock graph starts like this:

 <victim-list />
  <process id="process3ad41344e8" taskpriority="0" logused="10000" ...

And when I edit it and pick an arbitrary victim like this:

	<victimProcess id="process3ad41344e8" />
  <process id="process3ad41344e8" taskpriority="0" logused="10000" ...

then Management Studio is happy again:

This Kind of Deadlock Is Ignorable

Take this with a grain of salt, but personally, I ignore these kinds of deadlock because there is no victim and my applications are unaffected.
I think there are two issues here.

  1. Management Studio can’t handle deadlock graphs with zero victims. But that’s just a UI problem.
  2. This “interquery parallelism” kind of deadlock is resolved internally somehow (yay!) but an xml_deadlock_report event is still raised (boo!)

Update Turns out this is a bit of a known issue. There’s a request you can vote on to add extra info to the xml_deadlock_report that would allow us to filter these non-deadlocks out: Add columns has_victims and is_intra_query_deadlock to the event xml_deadlock_report


  1. Real DBAs only read the XML 😛

    Comment by Alex Friedman — March 15, 2018 @ 11:30 am

  2. In some cases, intraquery exchange deadlocks can result in severe performance degradation. Joe Obbish blogged about the effects of exchange deadlocks in parallel merge joins.

    Typically if intraquery deadlock is resulting in significant “lost time” during a query execution, the “system health” Extended Events session will show many deadlocks for the same session separated by 100 ms. Sometimes hours worth of them 🙂

    SQL Server 2016 SP1 CU6 and 2017 RTM CU2 contained a fix for intraquery exchange deadlocks in parallel merge joins.

    Comment by @sqL_handLe — March 15, 2018 @ 4:42 pm

  3. […] Michael J. Swart shows a scenario where the deadlock graph fails to open in SQL Server Management St…: […]

    Pingback by Victimless Deadlocks And SSMS – Curated SQL — March 16, 2018 @ 8:00 am

  4. Also, a recent CU for SQL Server 2017 provides more information for these intra-query parallelism deadlocks:

    Comment by Michael J. Swart — March 21, 2018 @ 10:43 am

  5. Ah, whaddya know… I ran into this today when blogging about… That thing.

    Great Post, Michael 🙂

    Comment by Erik Darling — March 21, 2018 @ 3:43 pm

  6. Just ran into this today – thanks Michael!

    Comment by Andy Galbraith — December 10, 2018 @ 1:19 pm

RSS feed for comments on this post. TrackBack URL

Leave a comment

Powered by WordPress