Memory leaks...
I was all set to write up a great post on memory leaks, how to track them down etc.. blah blah blah.. but then I found this little gem https://support.microsoft.com/kb/268343
Heck I didnt even know we did KB's with video - just shows how much I know.
Anyway, this article and video does a great job of explaining how to use the stack trace report and the UMDH tool itself.
We use this a lot here and wanted to share the love a bit.
Just to add a few more items that are helpful in tracking mem leaks.
1. Always get a perfmon log . Are you sure it is a memory leak? Are there other items which follow it? LIke threads? Or handles? -- perfmon is a nifty tool for confirming things like this.
2. Do NOT restart the process you are tracking - I had one fellow give me a bunch of umdh logs and each one had a different PID - like this:
// UMDH: version 6.0.5072.0: Logtime 2005-11-02 10:13 - Machine=BadMachine - PID=968
//// OS version 5.2 Service Pack 1
// Umdh OS version 6.0
// Debug privilege has been enabled.
// Connecting to process 968 ...
// Process 968 opened (handle=2000) ...
// Debug options set: 00000007
// Debug library initialized ...
// Module enumeration completed.
// Reading target process trace database ...
// Database size 01000000
// Trace database read.
// Stack trace data base @ 01010000
// # traces in the data base 31039Then
// UMDH: version 6.0.5072.0: Logtime 2005-11-02 10:13 - Machine=BadMachine - PID=845
// UMDH: version 6.0.5072.0: Logtime 2005-11-02 10:13 - Machine=BadMachine - PID=912
Don't do this :) - kinda hard to track a leak when you keep restarting the app..
3. If you can, get a userdump of the process as well when you are ready to stop collecting UMDH logs and ready to analyze. Why? The raw stack data is in there and there are times when it is useful to have.
spat