Debugging with UMDH.EXE

A quick word of warning though – to really get the most out of this tool, you need to be comfortable with some pieces of debugging – in particular understanding what a stack is (we’ll go over a little bit of this in the next post).  I know that we’ve talked a little bit about […]

A quick word of warning though – to really get the most out of this tool, you need to be comfortable with some pieces of debugging – in particular understanding what a stack is (we’ll go over a little bit of this in the next post).  I know that we’ve talked a little bit about applications leaking memory and heap allocations in previous posts.  Most administrators are fairly comfortable using tools such as Performance Monitor to do some relatively straightforward identification of memory leaks.  However, where many administrators start running into problems is when they suspect a memory leak – but the culprit is an application that is developed in-house.  Enter UMDH.EXE – a tool that is included with the Debugging Tools for Windows.  Before we dig into using the tool though, let’s quickly go over a couple of quick caveats about Memory Leaks.

A perceived memory leak may not actually be a memory leak.  No, we’re not trying to confuse you, or start an existential debate!  The fact of the matter is that there are applications that may be perceived to be leaking that are actually consuming memory by design.  Assuming that you actually do have a leak, capturing Performance Monitor Data may help you identify what is leaking, but generally does not provide more information beyond that.  The key piece of data in definitively identifying the memory leak within an application is the thread stack.  The thread stack is a list of functions.  Trying to capture the exact thread stack that is leaking is difficult because threads execute so fast that knowing exactly when to dump the process is not an easy task.

Full Article