1. Not all the objects which were created and used by the application have been deleted before the Engine object deinitialization. Some objects can be incorrectly handled, causing a memory leak. However, after Engine deinitialization all FineReader Engine objects will be deleted in any case, so the memory leak can occur in the client part of the code, i.e. if you create your own wrappers for the FineReader Engine objects and fail to release them before the deinitialization.
2. The garbage collector did not release the adapters yet and the reference counter is not null.

If the application is developed by using programming languages without garbage collection (for example, C++), it is necessary to either use smart pointer classes (see the standard samples in C++ (COM) from the distribution kit) or release objects that were created by creation methods when they are no longer needed. Not released objects are specified in "Leaked objects list" section in the log file. 

If all objects have been deleted, the exception may be caused by the garbage collector operation. If the application is developed in Visual Basic .NET, all objects with the Nothing value are not deleted, they are only marked for deletion. The exact moment when the garbage collector deletes the object is not known. Therefore, it is needed to call the following methods before the deinitialization of the Engine object so that the garbage collector deletes the object:

GC.Collect()
GC.WaitForPendingFinalizers()

Even if the garbage collector is explicitly called (GC.Collect), it does not always mean that the objects are deleted immediately. When working in environments with garbage collectors, you can disregard this message.

In platforms with a GC (C#, .NET, Java) it is a diagnostic message. It can be seen at the moment of FineReader Engine deinitialization - the adapters of the internal objects were already released (for example, by the FRDocument.Close call) and then the adapters can still be present in the memory, i.e. the garbage collector did not release them yet. Then after the deinitialization, it is possible to see that the reference counter is not null (not all the objects are deleted), but it is impossible to check which object it is, as the internal objects are already released. A GC result not always happen immediately. Internal objects should be released after the deinitialization of the FineReader Engine, so there will not be any memory leak.

Consider using the TotalObjectsCount property of the Engine object, which returns the number of unreleased objects and can help you track down the memory leak.

In case these recommendations will not help, please send us the sample project using which such behavior can be reproduced.