Skip to main content

SqlException - Transaction (Process ID XX) was deadlocked on lock | communication buffer resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

I’m currently migrating data between 2 systems. Therefore I build a small migration tool (using the great TPL Dataflow library).

While everything worked fine during development, I noticed that the migration failed on production with the following exception:

'Microsoft.Data.SqlClient.SqlException' in System.Private.CoreLib.dll ("Transaction (Process ID 153) was deadlocked on lock | communication buffer resources with another process and has been chosen as the deadlock victim. Rerun the transaction.")

Before I showed you how I fixed the problem, let me first give you some hints on how to investigate this issue.

Investigating a deadlock

The first thing I did was opening up my SQL Server Management Studio and checking the ‘Resource locking statistics by object’ report (check this link if you don’t know where to find this report):

In the report above I could see that both the doc.Document and doc.DocumentInfo tables were recently locked. That made sense as it are these 2 tables that are involved in the migration process. I could even drill down a little deeper and see the connectionstring user involved.


This report already confirms that the lock was caused by our own application and that no other application was involved.

But now we still need to know what exactly was causing the deadlock. Therefore you can take the following steps:

  • In SQL Server Management Studio, go to
    • Management –> Extended Events –> system_health
  • Right click on the package0.event_file and choose View Target Data from the context menu:


  • Now you get a long list of events. Search for an xml_deadlock_report event and click on it:

  • When you switch to the Deadlock view you get a nice visualization on the exact cause of the deadlock:

Fixing the deadlock

In this case the deadlock was caused because I was doing update statements to the same table in parallel.

Inside the update statement I was using a foreign key value (DocumentId) that was not indexed and resulted in a page lock.

UPDATE DOC.DocumentInfo SET DocumentKey = @DocumentKey WHERE DocumentId=@Id

I fixed it by changing the UPDATE query to use the primary key instead:

UPDATE DOC.DocumentInfo SET DocumentKey = @DocumentKey WHERE DocumentInfoId=@Id

More information

Dataflow (Task Parallel Library) - .NET | Microsoft Learn

Snapshot Isolation in SQL Server - ADO.NET | Microsoft Learn

SQL Server Timeouts–Find possible (dead)locks (bartwullems.blogspot.com)

Popular posts from this blog

Azure DevOps/ GitHub emoji

I’m really bad at remembering emoji’s. So here is cheat sheet with all emoji’s that can be used in tools that support the github emoji markdown markup: All credits go to rcaviers who created this list.

Kubernetes–Limit your environmental impact

Reducing the carbon footprint and CO2 emission of our (cloud) workloads, is a responsibility of all of us. If you are running a Kubernetes cluster, have a look at Kube-Green . kube-green is a simple Kubernetes operator that automatically shuts down (some of) your pods when you don't need them. A single pod produces about 11 Kg CO2eq per year( here the calculation). Reason enough to give it a try! Installing kube-green in your cluster The easiest way to install the operator in your cluster is through kubectl. We first need to install a cert-manager: kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.5/cert-manager.yaml Remark: Wait a minute before you continue as it can take some time before the cert-manager is up & running inside your cluster. Now we can install the kube-green operator: kubectl apply -f https://github.com/kube-green/kube-green/releases/latest/download/kube-green.yaml Now in the namespace where we want t...

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...