Why is this exception not being caught across DLLs?

Question

I have a DLL which throws an exception like so:

throw POMException(err, drvErr, errmsg);

The calling code is in a separate program, and has a try, catch block like so:

try
{
    // function in separate DLL
}
catch (TXNPDO_Exception& e)
{
    SR_PERFLOG_MSG(SR_PERFMASK_SELECT, "ERROR selectInStages");
    TXNDBO_THROW(e);
}

Where TXNPDO_Exception is defined in an included file:

#define TXNPDO_Exception POMException

When running this in a debugger, it states that the POMException was unhandled. I even added a catch(...) clause and it still isn't handled.

I suspect that this has something to do with the Visual C++ compilation parameters, since the DLL library in question is a legacy library that is compiled separate to the program calling it. I am using Visual Studio 2003.

The DLL cpp files are compiled with the following (relevant) flags: /X /GR /Ob1 /Zi /GX /Od /MDd /LD. Other exceptions within the calling program are handled correctly.

Can anyone provide reasons why this exception isn't being propagated to the calling program?

Edit:

The DLL library was previously compiled with possible build environment and code changes that are not available to me. The previously compiled library propagates exceptions correctly.

I am compiling the client program using the same compiler, using mostly the same switches: -Od -W3 -Z7 -MDd -GX -GR -Zm800 (no /X or /Ob1 and /Z7 instead of /Zi).

I should also point out that this "used" to work. As in we have an existing set of binaries that propagate the exceptions correctly. What I don't have is the same makefile used to create those binaries. It is also possible that the source code isn't exactly the same, so I can't discount a code problem. — tvStatic, Dec 01 '11 at 22:31
@tvStatic It probably used to *work* when the client and the .dll were compiled by the same compiler. — FailedDev, Dec 01 '11 at 22:44

FailedDev · Answer 1 · 2011-12-01T22:42:18.377

3

I would assume that throwing exceptions across .dll boundaries could only be possible, when the various .dll and program executable are compiled against the same C++ runtime, thus sharing the same heap. I could be wrong, but this is my best guess.

Edit:

I guess I wasn't wrong.

edited Dec 01 '11 at 22:42

answered Dec 01 '11 at 22:28

FailedDev

26,680
9
53
73

I can say that the client and DLL were compiled by the same compiler. As for the same C++ runtime. Both are compiled using `/MDd`. Doesn't this indicate the C++ runtime library? – tvStatic Dec 01 '11 at 22:51
@tvStatic: The same versions of the library? With the same settings? – Mooing Duck Dec 01 '11 at 22:55
@tvStatic Well in your question you do mention separate compilation, and that is "used" to work. This leads me to believe that the runtime is different. Also /MDd alone doesn't help. Maybe some patch was applied to the compiler and the client or the .dll was compiled after it? – FailedDev Dec 01 '11 at 22:58
I've edited the question to clarify. I am compiling both code bases now with the same compiler and using (to my knowledge) similar parameters. – tvStatic Dec 01 '11 at 23:13
@tvStatic Do you also compile the .dll? – FailedDev Dec 01 '11 at 23:14
Yes. I suspect that my knowledge of static/dynamic libraries may be causing confusion at both ends. I have a project which, when built outputs some DLLs and lib files. My client project presumably links against the lib files but uses the DLLs at run time. – tvStatic Dec 01 '11 at 23:21

score 2 · Accepted Answer · answered Dec 02 '11 at 05:40

I have finally figured out what the problem is, and in this particular case, it is nothing to do with throwing exceptions between DLLs.

The problem is occurring due to an exception handler hook being installed further up the call stack. I diagnosed this by adding try, catch(...) blocks to every level in the library until I found the point at which the exception wasn't propagated. When I commented out the exception handler hook registration code, the exception was successfully propagated.

I now have to figure out the workings of exception handler hooks, which is outside the scope of this question. Thanks to everyone who shared their answers.

Why is this exception not being caught across DLLs?

2 Answers2

Linked