This tutorial is part of a series: Part 1 – Getting started with Visual Studio Debugging Part 2 – Visual Studio Debugging Tool Windows Unfortunately, writing code goes hand in hand with creating bugs. We all cause bugs, it’s one of the inevitable facts of life. This process of solving those bugs is called Debugging. Debugging comes in many forms: Stepping through the code with a debugger, investigating logs, unit testing, profiling, and analyzing dumps.
How many times did you use a desktop application to end up with a frozen unresponsive window? This article is about what we are to do when our .NET application freezes. We're going to explore tools and debugging techniques to see where the program is stuck and to find the core cause of the issue.
In this article, we'll see what exactly are dump files, why they are so helpful and how to use them correctly. You will see all the ways to create Dump files, to properly match them with symbols and source files and finally how to debug them to solve the problem.
Welcome to the 3rd and final part of the Deadlocks-in-Depth series. In this part, I’ll show you 2 additional techniques to debug deadlocks: Working with Tracepoints and using the notorious WinDbg to automatically detect deadlocks.
We'll see two more deadlock types: The notorious UI-Message-Queue Deadlock and the Sync-Context Deadlock (both names coined by me just now). In addition, I'll show you a new debugging technique for deadlocks and multi-threaded scenarios.
For me, multi-threading programming is one of the most fun things I do as a developer. It’s fun because it’s hard and challenging. And I get a particular sense satisfaction when solving deadlocks. So today I’m writing on one of my favorite subjects.
Fixing bugs is a huge part of a developer’s job, but not many think or read about the actual process of solving a bug. We sort of go at it intuitively, trusting our own self-developed process. Some of us tend to think of bug solving as the 2nd class citizen in programming. Not our real job, which is writing code, crafting new features and discovering new technologies. It’s just something we do in between real programming, right?
I think I spend more time debugging code than writing code, designing software architecture, trying to reproduce bugs and even going to meetings! Debugging is the biggest time consumer we have as developers. As time goes by, I keep learning new tricks that make my debugging more effective. I’ve gathered in this post 7 debugging techniques that I learned relatively late into my career and I consider advanced (though sometimes something advanced for some is trivial for others).
In my previous company, we experienced a reoccurring nightmare. It went something like this: New critical bug arrived from QA: Program suddenly crashed. Reproduces 1 / 10 times. Reproduce steps – unclear. The development team, after realizing they are unable to reproduce the bug on their development machine would claim the bug doesn’t reproduce, moving the ticket back to QA. In return, the QA team reproduced the bug, moving the ticket back to dev.