Our software is structured as a number of dll's each of which is instantiated with a LoadLibrary inside of a host application. A seperate instance of the host application is spawned for each dll to be loaded.
All are compiled as 32bit Delphi code using Berlin.
The dll's each have madexcept enabled with a unique bugreport filename and the host process also has madexcept enabled but uses the same bugreport name for all instances.
The dll's and the host process reside in the same folder.
I have verified using MadTraceProcess that all processes are present in the list of processes to be traced so I am sure the MadExcept features are enabled.
Firstly is this a valid configuration when using MadExcept, or should we locate each dll and a copy of the hostprocess in seperate sub folders to avoid potential conflicts writing to a shared bugreport file ?
One of the Dll's does use a COMWrapper to instantiate a vendor API written in .Net however the wrapper does have exception handling and is set to capture all first chance exceptions and route them through a common OnError event for logging purposes. Additionally the Windows Event viewer indicates that the Runtime Error occurred in the hostprocess excutable.
Under what circumstances would the above Runtime error avoid being captured by MadExcept and routed to the bug report file ?
Do you have madExcept *fully* active in your DLL projects? Specifically, do you have "link in madExcept code" checked? Furthermore, are you using runtime packages in either the DLLs on in your EXE or in both?
If your DLLs have their own copy of the Delphi RTL linked in, they need their own copy of madExcept, too. madTraceProcess will list any process which has at least 1 instance of madExcept active in them. However, a process being listed in madTraceProcess does not yet prove that both the EXE and your DLL file have madExcept active. It might be the only one of them has it active.
If madExcept is fully active, you're not supposed to ever see Runtime error 216, unless maybe the process is in such a bad state that madExcept can't do its work, anymore. But that's really rare.