How to track _AddRef / _Release calls for OLE Automation objects

(Delphi XE2 4 update)

I am trying to get a large Microsoft Word OLE automation module that I have inherited (based on early binding of TWordApplication and interfaces from WordXP / Word2010 ) to close WINWORD.EXE when all the links have been released.

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

However, some use cases keep WINWORD.EXE open.

Some of the fixes indicate that I should use local variables instead 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 the 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; 

Properties to make EAccessViolation messages more readable than the $ C0000005 errors you receive in the debugger.

I am interested in learning about the general (since I will probably need this for other automation projects as well), methods for monitoring _AddRef and _Release .

I looked through these links:

  • Understanding and fixing interface leaks in Delphi Vcl.OleCtrls.pas (it does not apply, since I do not use interface -based TOleControl )
  • How to find the missing _Release (what I use so far)
  • Should the compiler indicate / warn when passing object instances directly as const interface parameters? (not applicable: there are no constant parameters that these interfaces accept)
  • Unused interface link is not destroyed (fixed in Delphi XE update 1 and higher)
  • WinWord.exe will not exit after calling Word.Documents.Add - Word.NET Interop
  • Is COM broken in XE2 and how can I get around it? (fixed in Delphi XE2 update 2)
+2
delphi delphi-xe2 ole
source share
1 answer

A rather tedious way:

Place breakpoints for all _AddRef and _Release in the Delphi System module that are not part of the TInterfacedObject special methods.

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

  • Start debugging your application with a simple start / exit without significant functionality:
  • Before tracing in each call, pay attention to the value of EAX .
  • If you are done with any of these methods: NopRelease , NopAddref , TInterfacedObject._AddRef , TInterfacedObject._Release , MemRelease , MemAddRef , then add the EAX value to the conditional breakpoint instruction for all breakpoints, as shown below.

Example conditional expression of a breakpoint for my application:

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

This method has many disadvantages, but it turns you on.

Disadvantages:

  • There are restrictions on the length of the conditional expression of a breakpoint. This means that if you continue to add and (EXA <> $xxxx) parts, the debugger will ignore those that did not indicate a warning.
  • You lose the setting if you exit Delphi without saving your desktop
  • It takes a long time to set up
0
source share

All Articles