LINQ is one of my favorite features in C#. It just makes the code look nicer. Instead of tedious foreach loops, we got a neat functional syntax that’s easy to write and understand. Well, at least if we’re using the method syntax flavor of LINQ. LINQ is also terrible to debug. We have no way of knowing what goes on inside that query. We can see the input, we can see the output, but that’s about it.

For almost a year now, I’ve been writing a book about debugging and problem-solving in .NET. I’m pretty upset at whoever said writing a book is just like writing a series of blog posts. That was way more work than I signed up for. But it’s over now and my book Practical Debugging for .NET Developers is available . This book is all about solving bugs. I daresay say that the ability to solve difficult problems is what differentiates great engineers from good engineers.

This tutorial is part of a series: Part 1 – Getting started with Visual Studio Debugging Part 2 – Visual Studio Debugging Tool Windows In the previous tutorial, we saw some of the basics of debugging in Visual Studio. This included Breakpoints, Navigation through code, and Investigating variables with the DataTip and QuickWatch. In this tutorial we will go over all the windows Visual Studio has for debugging.

Don't know about you, but I'm obsessed about performance. I've gathered a list of 10 best practices on dealing with performance problems, starting with when you need to deal with them at all.

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.

Let's consider a simple programming challenge: Summing all items of a large array. Now it stands to reason that this can be easily optimized by using parallelism...

Some of the biggest performance problems in almost any .NET application boil down to string operations. They are both very common and by nature pretty expensive. In fact, looking at an average .NET Dump you’ll find that most of the memory is usually taken by strings (I heard about 70%). As you probably know, strings are immutable. So whenever you concatenate strings, a new string object is allocated, populated with content, and eventually garbage collected.

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.