Weird issue with BDE when compiled with madExcept

delphi package - automated exception handling

Weird issue with BDE when compiled with madExcept

Postby StephaneGrobety » Thu Feb 14, 2019 2:51 pm

We have a really weird issue with madExcept:

For various reasons, we're still using the BDE in part of our application, including one that is fully based on paradox/BDE. I tested them initially and found no issue with madexcept.

Today, I got a weird case, however: when a specific dll is compiled with madExcept (specifically, when madExceptPatch.exe is run on the result of the compilation and when the madExcept compiler define is defined during the compilation), AND when another program runs with a BDE that is set in a different path (explanation later), then the library will fail with a BDE error $2109 (Cannot load IDAPI32 .DLL)

That problem is NOT general: I can't seem to reproduce it on my machine but on my boss's machine, it fails every time.

The weird part is that we we disable the madexcept path call and disable the madexcept parameter (even if the mad* units are left in the projet's uses clause), then all works as expected.

We're kind of guessing the issue is that upon loading the dll, madExcept does something (perhapse with the search path) that causes the BDE to fail.

Explanation about the thing with several programs and the BDE:
That old cranky beats of BDE will fail to load if, for whatever reason, two executable attempt to load it from two different locations at the same time, even if these versions are strictly identical.

In our main application, we are distributing the dlls with the application itself (same folder) and control the configuration by code but in another application, we rely on an instance of the BDE to be installed (globally) on the machine.

In order to make this works, our main app will check the registry to see if there is a common install and switch to that folder before initializing the BDE if found: that way, the "common" installation is used if present. If not present, it will load the version from the application's folder instead.

The problematic dll is a bit peculiar in the sense that it is used as a callback from another C++ dll and has a single purpose: provide access to the BDE. As such, it will attempt to reload the bde when first used and that is that initial load that fails. Our other packages and dlls don't do that and rely on the main instance loaded inside the executable.

So, that is the issue as well as I could describe it. After spending 3 hours debugging it and 3 more hours with procmon trying to find anything that could be a problem, I came back blank. I will try to load it into IDA and see if I can understand what's going on but that is going to be a bear in the disassembler (plus, I can't really reproduce on my machine so even harder).

So my question is: what could madExcept do that the BDE dislike (in one special case at least)?
Posts: 19
Joined: Tue Jul 17, 2018 9:21 am

Re: Weird issue with BDE when compiled with madExcept

Postby madshi » Fri Feb 15, 2019 4:00 pm

I've never really used the BDE, so my knowledge about it is very very limited or even non-existent. So you're probably in a better position to guess what's going on than I am.

If I were able to reproduce the problem, I would try to analyze it by uncommenting parts of the madExcept initialization code. Must be something done in there which causes the problem. So by trial and error you may be able to locate which code is causing this issue. That's the only thing coming to my mind, really.

Of course it's also possible to simply disable madExcept for this specific DLL. Not nice, but possible. Of course only you can say how much time you can spend on analyzing this problem to make it worth it.
Site Admin
Posts: 10303
Joined: Sun Mar 21, 2004 5:25 pm

Return to madExcept

Who is online

Users browsing this forum: Google [Bot] and 18 guests