Memory leaks are very common, hard to notice, and eventually, lead to devastating consequences. The main tool to detect and fix memory leaks is a Memory Profiler. In fact, I believe the most common usage of memory profilers in .NET is exactly for the purpose of fixing memory leaks. In this article, you'll see exactly how to use memory profilers to find the leaky objects, why they are still referenced, and how to solve the problem.

Memory leaks and GC Pressure cause pretty inconvenient effects like out-of-memory crashes, performance problems, and high memory consumption. Our primary tools when dealing with those issues are memory profilers. They are one of the most important category of tools in .NET troubleshooting, and in this article, you'll see how to use them and extract the most information from them.

What happens if you’re working on something that lasts much more than one sprint? Maybe 3 sprints or 10. Are you going to work on a separate branch, ending with a huge merge? Are you going to run automated tests on that branch? This matter is not that simple, as I recently experienced.

Is C# slower than C++? That's a pretty big question. As a junior developer, I was sure that the answer is "Yes, definitely". Now that I'm more experienced, I know that this question is not obvious and even quite complicated.

When it comes to debugging software, tools are extremely important. Get the right tool and you extract the right information. Get the right information and you can find the root cause of the issue. Find the root cause and you've solved the bug.

There are many ways to communicate between a C# client and a C# server. Some are robust, others not so much. Some are very fast, others aren't. It's important to know the different options so you can decide what's best for you.

You’re sending an HTTP request to your ASP.NET server, and out of the blue, it returns a 500 error. Now what? The error code doesn’t say too much by itself. Did a database request fail? Was there an exception? In this article we'll see how to get the most information on the error.

It's not so rare to see weird things happen in 3rd party library code. Call some method and you've got a strange exception. Or an incorrect behavior or even a process crash. It sure would be nice to debug some of these issues. In this article we're going to do just that - You'll see how to debug 3rd party library code in Visual Studio.

You might have heard about OzCode before. It's an extension for Visual Studio. Like ReSharper, but with very different functionality. The single purpose of OzCode is to help you debug code and find the root cause of problems. In this blog post, I'm going to tell you about some amazing features in OzCode from my perspective and why you should try it out.