Hunting .NET memory leaks with Windbg

Recently a client called me about an issue where one of their production servers would run out of memory, every other week. The application in question was a .NET Framework 4.5 Windows service, that runs in an Azure VM, and ever so often it would become unstable and start causing trouble. I have previously helped this client set up an ELK stack, so it was quick for me to go into Kibana, look at metricbeat data, and see that their server indeed slowly was eating up memory over time. And every time the application was restarted, the memory would return to normal, and slowly creep upwards again. As you can clearly see, the application uses gradually more and more memory over time. Every time the line drops, was a restart of the server, where it went back to normal operation at about 150 MB. When they initially called me, they had just restarted the application, so I had no real practical way of finding out what caused the memory right there and then, but I logged on to the server and created a memory dump for the recently restarted application, so I would have a baseline for how it looks during normal operation. Creating a memory dump file The best way to figure out what is causing a memory leak, is to analyse the memory of the running application. To do that, we need to make a “memory dump”, and thankfully on Windows this is straight forward. Open Task Manager. Go to the Processes(older) or...