How to correctly free/finalize an ActiveX DLL in Delphi?

We are using a class called ODNCServer here - at initialization, an TAutoObjectFactory object is created:

initialization
  pAutoObjectFactory := TAutoObjectFactory.Create(ComServer, TODNCServer, Class_ODNCServer, ciSingleInstance, tmApartment);

Now FastMM is complaining about a memory leak because this object isn't freed anywhere. If I add a finalization statement like this

finalization
  if assigned(pAutoObjectFactory) then
    TAutoObjectFactory(pAutoObjectFac开发者_如何转开发tory).Free;

then the object is freed, but after the FastMM dialog about the memory leak pops up, so actually, the OS seems to be unloading the DLL, not the program. Instances of ODNCServer are created like this

fODNCServer := TODNCServer.Create(nil);
//register into ROT
OleCheck(
 RegisterActiveObject(
   fODNCServer.DefaultInterface,            // instance
   CLASS_ODNCServer,    // class ID
   ACTIVEOBJECT_STRONG,       //strong registration flag
   fODNCServerGlobalHandle //registration handle result
 ));

and freed like this:

if ((assigned(fODNCServer)) and (fODNCServerGlobalHandle <> -1)) then
begin
  Reserved := nil;
  OleCheck(RevokeActiveObject(fODNCServerGlobalHandle,Reserved));
  fDTRODNCServerGlobalHandle := -1;
end;
FreeAndNil(fODNCServer);

So, does anybody know what I have to change to get rid of that memory leak? By the way, I also tried using FastMM's RegisterExpectedMemoryLeaks to register and ignore the leak, but this doesn't seem to work. Additionally, even if, it would just be a workaround and I'd like to know the right way to do this.

Don't worry about it. It's not a "leak" in the strict sense. Yes you are creating an object that is never free'd, but the keyword is "an". Singular.

Your application/DLL will not "leak" memory in the sense that it will create numerous instances of these objects,continually increase it's memory use. Furthermore the memory used by that single factory object (and others like it) will be cleaned up when the process terminates anyway.

If you showed the code you are using to call RegisterExpectedMemoryLeak() it might be possible to determine why it is not working your specific case.