Firstly, I'd like to congratulate the authors on a great book!  I ordered this a week or so ago and, as mentioned in the book, it provides some very useful hints and tips.  I've been developing C/C++ code on windows platforms for over 10 years and, although I've used windbg before, I'd always found it a little intimidating.  This book has given me know how and confidence to get a bit more to grips with the available tools.

Anyhoo... I've question for you or anyone who might be able to assist...

I'm trying to find a resource leak inside an ATL COM dll I've written.  The intention is for this dll to run inside COM+ so we can use object pooling. 

I've been using umdh and leakdiag for this purpose.

As mentioned in the book these tools work by created a snapshot of memory or handles at a predefined point.  You then create another snapshot at some other point and you can then address the handles that are still open or heap allocations still in use.
My problem is when to take the snapshots given that I am dealing with a dll; these tools are so effective that they show up leaks in MS/external code that I have no control over and I'm not interested in.

So here's what I've been attempting to do…
Create a defered breakpoint when the c runtime initialises in my dll, just before it initialises any static objects.
Create another defered breakpoint just after the c runtime terminates and uninitialises the static objects (MyDll!doexit+0xe2 and MyDll!_cinit).

These breakpoints all work and I can see from windbg that my objects are uninitialised after the second breakpoint.  So this seems the ideal place to trap the second snapshot.

However, my problem is now this:
When I try and invoke any of the leak tools (leakdiag or umdh) after I've hit the second breakpoint the process is terminating so the leak tools can't inject into the process and create the second snapshot.

What I need is to somehow force the dll in question to unload while keeping the process alive so that the leak tools can create the elusive second snapshot.
I've a VB test harness from which I've been trying to do this, loading the COM server inprocess directly (without surrogating in COM+) and I've tried forcing COM to unload libraries (CoFreeUnusedLibraries/CoFreeAllLibraries) but VB still doesn't unload the dll until I end the process for some reason!

I'm not too verse in COM+ configuration so I was wondering if there is a way to configure a COM+ application to unload the hosted inproc COM servers while still keeping dllhost.exe alive?  I've messed around with object pools of 0 to 100 but it doesn't seem to unload my dll (I've some internal monitoring of object counts and this doesn't drop below 1).  Is there anything else I can configure on the COM+ application to enable this sort of behaviour?  Could it be that I just haven't waited long enough and there is some magic lifetime number COM+ keeps servers alive for?

Is there any other way to look for memory leaks, are there any extensions in windbg that don't require the process to be executing?

Any help appreciated.

Regards,

Martyn