How to trace _AddRef / _Release calls for OLE Automation objects

Question

(Delphi XE2 update 4)

I'm trying to get a big Microsoft Word OLE automation unit I inherited (based on the early binding TWordApplication and interfaces from the WordXP/Word2010 units) to close WINWORD.EXE when all references have been released.

So far, it looks like I did catch a couple of reference leaks: most references are properties or local variables.

Some usage scenario's however still keep WINWORD.EXE open.

A few of the fixes indicate I should favour local variables in stead of chains from

procedure TOffice_10_XP_WordInterface.AddDocument;
var
  WordApplicationDocuments: Documents;
begin
  WordApplication_Documents.Add(EmptyParam, EmptyParam, EmptyParam, EmptyParam);
end;

to

procedure TOffice_10_XP_WordInterface.AddDocument;
var
  WordApplicationDocuments: Documents;
begin
  WordApplicationDocuments := WordApplication_Documents;
  WordApplicationDocuments.Add(EmptyParam, EmptyParam, EmptyParam, EmptyParam);
end;

based on a WordApplication_Documents property that calls this function:

function TOffice_10_XP_WordInterface.GetWordApplication_Documents: Documents;
begin
  Result := WordApplicationReference.Documents;
  if not Assigned(Result) then
    raise EAccessViolation.Create('Documents');
end;

The properties are there to make the EAccessViolation messages more readable than the $C0000005 errors you get in the debugger.

I'm wondering about generic (since I'll probably need this for other automation projects as well) ways to monitor _AddRef and _Release calls.

I did take a look at these links:

Understanding and correcting interface reference leaks in Delphi's Vcl.OleCtrls.pas (it does not apply as I don't use the TOleControl based interface)
How to Find a Missing _Release (that's what I use until now)
Should the compiler hint/warn when passing object instances directly as const interface parameters? (does not apply: no const parameters that take these interfaces)
Unused interface reference is not destroyed (fixed in Delphi XE update 1 and above)
WinWord.exe won't quit after calling Word.Documents.Add - Word .NET Interop
Is COM broken in XE2, and how might I work around it? (fixed in Delphi XE2 update 2)

Going to be a little tricky. The COM server is out of proc and so the code you want to instrument is in a different process. — David Heffernan, May 25 '13 at 14:44
I was hoping there was a smart way to break on the local proxy. — Jeroen Wiert Pluimers, May 25 '13 at 15:19
You can do that but it's only part of the story. References will be taken in the other process. — David Heffernan, May 25 '13 at 16:11
Anyway, there must be COM debugging tools. Does WinDbg understand COM? I'd expect any such tools to be MS centric. If you use map2dbg you can get WinDbg to understand your symbols. — David Heffernan, May 25 '13 at 16:36

Jeroen Wiert Pluimers · Answer 1 · 2013-05-28T07:29:01.887

A tedious way that gets you going is this:

Put breakpoints of all _AddRef and _Release calls in the Delphi System unit that are not inside TInterfacedObject specific methods.

Now eliminate (using conditional expressions) all the interfaces that are not part of Delphi (EAX contains the vTable pointer for each interface).

Start debugging your application with a simple run/exit without doing much actual functionality:
Before tracing in each call, make a note of the EAX value.
If you end up in any of these methods: NopRelease, NopAddref, TInterfacedObject._AddRef, TInterfacedObject._Release, MemRelease, MemAddRef then add the EAX value to a conditional breakpoint instruction for all of the breakpoints like below.

Example conditional breakpoint expression for my application:

(EAX <> $401E58) and (EAX <> $54AD14) and (EAX <> $4A7C88) ...

This method has a lot of drawbacks, but it gets you going.

Drawbacks:

There are limitations on the length of the conditional breakpoint expression. Which means that if you continue to add and (EXA <> $xxxx) portions, the debugger will ignore those without indicating a warning.
You loose the setting if you exit Delphi without saving your desktop
It takes a lot of time to setup

@DavidHeffernan `EAX` has the interface reference in each method. Basically you want to eliminate all interface references that are not COM references. — Jeroen Wiert Pluimers, Jun 07 '13 at 09:59

How to trace _AddRef / _Release calls for OLE Automation objects

1 Answers1