Outlook 2003 won't unload from memory with my COM add-in...

[Oliver Giesen]

Hi all!

I have written a COM-Addin for Outlook utilizing the Redemption Objects
library. Basically everything is fine but when I load the add-in into
Outlook 2003 the outlook.exe never unloads from memory, even though by
placing debug output messages I could tell that my addin gets properly
unloaded and destroyed and all references it holds are released. In
some situations the hanging outlook.exe process eventually causes an
ugly error message upon exiting Windows (the "could not be closed"
thingy). Outlook 2000 and XP do not exhibit this behaviour.

I have already discovered the following FAQ concerning a similar issue
with Redemption:
http://www.dimastr.com/redemption/faq.htm#5

but I have already added Cleanup calls everywhere I make use of the
Redemption objects. Furthermore, the problem even appears if I do not
use any of them at all, e.g. if I just open and close Outlook without
activating any of my add-in's functionality. So, I'm pretty sure it
doesn't have anything to do with Redemption. There also are no dangling
IMAPISession references created by my own code.

By now I have pretty much no idea where else to look.

What else could be causing this?

P.S.: The add-in is written using Borland Delphi 7.

Cheers,

Oliver

 

[Ken Slovak - [MVP - Outlook]]

In general 2 things cause what you are seeing. Not releasing all your
Outlook derived objects or not handling all errors that might have occurred.
Is your On_Disconnection event firing?

 

[Oliver Giesen]

In general 2 things cause what you are seeing. Not releasing all your
Outlook derived objects or not handling all errors that might have
occurred. Is your On_Disconnection event firing?

Yes, the OnDisconnection event of the add-in is firing and so is the
Quit event of the Application object.

What exactly do you mean by "Outlook derived objects" be? References
obtained via OOM? E.g. Application.Session or Application.Inspectors,
etc. ? I will double-check again, but I'm pretty sure they should all
be released.
Are there any specialized debugging tools out there to track this kind
of thing?

Cheers,

Oliver

 

[Dmitry Streblechenko]

Try to comment out most of your code and start uncommenting it until the
problem comes back.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

 

[Ken Slovak - [MVP - Outlook]]

Yes, objects that are in the Outlook object model. Aside from what Dmitry
mentioned the other thing you could do is to set a breakpoint in your code
to stop on an error and see if you are seeing any errors in your teardown
code or On_Disconnection event handler.

 

[Oliver Giesen]

Yes, objects that are in the Outlook object model. Aside from what
Dmitry mentioned the other thing you could do is to set a breakpoint
in your code to stop on an error and see if you are seeing any errors
in your teardown code or On_Disconnection event handler.

I've already got exception handlers all over the place. There are no
unhandled exceptions anywhere in my code.

Breakpoint-debugging is unfortunately not really feasible at the moment
for several reasons, one being that I don't have OL2003 on my
development machine. I'm testing inside a VMWare session.

As for the commenting stuff out approach, I'm still in the middle of
it. I got to the point where the error no longer occurred and am now
carefully reenabling stuff bit by bit.

Anyway, thanks for all the tips so far. I'll let you know when I find
anything.

Cheers,

Oliver

 

[Oliver Giesen]

In general 2 things cause what you are seeing. Not releasing all your
Outlook derived objects or not handling all errors that might have
occurred.

Just to let you know: It was something entirely else.

There was an umatched call to CoInitialize in a part of my code which I
haven't touched for more than three years and which got linked into
this project rather by accident than anything else. Actually there
_was_ a CoUninitialize call to match but it was quite inexpertly placed
in a place that would never be reached until the DLL would be unloaded
(Delphi finalization section). Obviously Outlook 2003 was waiting for
the CoUninitialize and thus wouldn't unload the DLL...
<sighsomethingaboutoldghoststhatcomebacktohauntyou/>

Anyway, thanks for all the hints.

Cheers,

Oliver