Michael J. Swart

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:

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

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

<deadlock>
 <victim-list>
	<victimProcess id="process3ad41344e8" />
 </victim-list>
 <process-list>
  <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