C#, coding, development, threading, visual studio

Resolving A Dead Lock Is Your Number 1 Priority.

If your app deadlocks during development you might not want the added distraction. Surely you’ve got some feature which you need to get finished off in a hurry that your boss is pressurising you for. Maybe the screen deadlocking is something your colleague is working on, so you can just let them know and get back to the job at hand.


You now know there’s a deadlock. Some deadlocks manifest readily. But others are a rare breed that only happen under rare circumstances, and perhaps even rarer on your CPU compared to those that you will deploy to. If you ignore this deadlock, it’s on your head.

The reality is: you just got lucky. Your team got lucky. You can resolve this problem here and now, without it escaping into the wild.

Stop what you are doing, forget what your boss wants you to do, or whatever task you think you need to do, and investigate the deadlock and knock the problem on the head.

Often I have heard developers say something like, “yeah, it deadlocks there sometimes”. Or worse, “yeah that’s the so-and-so’s code”. But they don’t stop to investigate. They just assume it’s someone-else’s responsibility

It can take time to resolve a deadlock. Sometimes they are pretty easy, but sometimes they can be complex beasts which take time to understand. Threaded code is more often tricky than not, and problems can be oh-so-subtle. But don’t shun it. Be a hero. Solve it.

Whenever I get a deadlock I immediately cease what I am doing. I pause Visual Studio (being my typical dev tool of choice) and put everything to one side. I won’t close the debug session until I am done. Is it half-five and I’ve got to pick the kids up? No problem. Visual Studio occasionally crashes during debug sessions but I have never had a problem when it is left paused. I’ll just leave it overnight, and come back to it with a fresh head in the morning.

I get the Call Stack up, get the Threads window open and sit there – sometimes just staring for long periods – and try and work through what’s happening. Often in large systems I’ll be working through vast swathes of code I’ve never seen before. There might be multiple context switches, some red-herrings, some code that is down-right ugly. Compiled libraries that you have to break open Refelector/dotPeek or browse Git source to understand. It can be hard, and it can take time: I’ve sat there for hours at a time trying to get things straight in my head, scratching notes on paper, perhaps even firing up another instance of Visual Studio to run through scenarios.

Maybe I’ll take a break, get a drink, some fresh air; but I won’t leave that debug session until I understand what’s causing the deadlock and how I’m going to go about fixing it.