leaking mutexes, with no mutex in code

hello, i'm running into a very weird problem and maybe someone with a lot of windows experience can chime in.

an application i'm testing with shows it's leaking handles (according to performance monitor). i ran sysinternals handle on the service, and mutants are consistently going up at a rate of 1 every 5 or 6 seconds.

the weird part is, there is not a single reference to a mutex in the code.

the machine is running windows 2000, and the handle leak doesn't appear on another test box running XP...

any ideas? thanks.

>> there is not a single reference to a mutex in the code
It's not just your code running within your process. Use process explorer to see what DLL's are loaded. You may be able to see which module is leaking as well.

gg

thanks for the quick reply!

i opened up process explorer, and indeed there are many DLLs loaded. my application is statically compiled, and the only DLLs loaded are all from microsoft.

You could use the debugger to narrow down in what part of the code the handle count increases.

gg

thanks again!

i'm new to all of these "low-level" debugging...and only recently discovered the sysinternals suite. do you have any links/articles that i could read? i'm guessing you're referring to cdb.exe?

What debugger you should/could use depends on what compiler you use. Visual Studio has a built-in debugger that is pretty useful.

However, trying do debug code that isn't yours (e.g. MS code) can be very hard - the best effort is probably a "divide and conquer" - find a few likely candidates of functions outside of your application that could possibly cause this problem, and try to exercise those in a smaller test-app. Then strip down your code to a bare minimum.

Once you know that, you may of course not be able to do anything about it, as you don't have the source-code for the DLL anyways...

Another option is to start your applicatin as usual, then start WinDBG (Freely available as download from MS), and set a breakpoint in the suitable "create mutex" or such function, and look at the call-stack.

--
Mats