Re: (Re)throwing from a catch block across dll boundaries

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

This unexpected behavior is caused by a limitation of the runtime included in VisualStudio. In order to have C++ exceptions work reliably across modules you'd have to use only one copy of the CRT (so linking _all_ the modules with the DLL version of the CRT as you have noticed).

As I mentioned earlier, it's highly recommended to use a C or COM based interface between modules.

--
Thank you,
Leonard Mosescu, Microsoft Windows CE Compiler Team

This posting is provided "AS IS" with no warranties, and confers no rights.


"Leonard Mosescu [MS]" <lemo@xxxxxxxxxxxxxxxxxxxx> wrote in message news:46A68738-FB7C-4091-8756-6A6A3ADB9B68@xxxxxxxxxxxxxxxx
Thank you for the sample project, I'm able to reproduce the issue you're describing (at least with WM5).
I'll look into it and get back to your once I find the root cause.

--
Thank you,
Leonard Mosescu, Microsoft Windows CE Compiler Team

This posting is provided "AS IS" with no warranties, and confers no rights.


"hansjoergp" <hansjoerg.petschko@xxxxxxxxxx> wrote in message news:B0CED18E-721D-46C9-BE24-B91EF4F1C82C@xxxxxxxxxxxxxxxx
Hi Leonard,

yes, WM6 is one of the target OSs (see below).

I linked explicitly to libcmt.lib and libcmtd.lib but had no success, the
application was still crashing.

Using the wizard in the IDE I have created the simplest possible test
solution and tested it on several platforms, here are the results
(The tests were done on two different computers that were set up by
different persons):

WIN32 : no
crash
Windows Mobile 5.0 Pocket PC SDK ARMV4I: crash
Windows Mobile 6 Professional SDK ARMV4I: crash
STANDARDSDK_500 ARMV4I: crash
STANDARDSDK_500 x86: no crash

This means that all ARM versions crashed while the x86 versions worked well,
regardless of the OS.
I have attached a detailed step by step description of how I created the
solution (incl. the command lines) and also the complete solution in a zip
file.

Regards

Hansjoerg Petschko


"Leonard Mosescu [MS]" <lemo@xxxxxxxxxxxxxxxxxxxx> schrieb im Newsbeitrag
news:52273E4C-E8D1-41AB-9237-6518DD62AC4D@xxxxxxxxxxxxxxxx
I see from the paths used below that you're using the WM6 SDK, is that the
OS you're targeting?

Can you please try to link with the /nodefaultlib and libcmt.lib? (that's
the static lib which provides the implementation for__CxxFrameHandler3).
Also please include the command lines used by the IDE to build your code.

--
Thank you,
Leonard Mosescu, Microsoft Windows CE Compiler Team

This posting is provided "AS IS" with no warranties, and confers no
rights.


"hansjoergp" <hansjoerg.petschko@xxxxxxxxxx> wrote in message
news:69231FC6-799A-4248-A52D-8A7ACEDD012E@xxxxxxxxxxxxxxxx
Hi Leonard,

I'll start with the results of my tests: I can reproduce the issue on my
system, and it seems to be a question of what C runtime library is
linked.

Here are the details:

It took my a while until I was able to build from the command line:

1) path %PATH%;C:\Program Files\Microsoft Visual Studio
9.0\VC\ce\bin\x86_arm;C:\Program Files\Microsoft Visual Studio
9.0\Common7\IDE;
2) set INCLUDE=C:\Program Files\Windows Mobile 6
SDK\PocketPC\Include\Armv4i
3) set LIB=C:\Program Files\Windows Mobile 6
SDK\PocketPC\Lib\Armv4i;C:\Program Files\Microsoft Visual Studio
9.0\VC\ce\lib\armv4i
4) when I used the command line parameters you have provided for the dll
I
got an unresolved external error: __CxxFrameHandler3 (see below for the
solution of this)
5) for the executable there was also an issue: "unresolved external
mainCRTStartup". I replaced the switch with -entry:mainACRTStartup, then
I
was able to build

For the issue from 4) I found two solutions:

a) I added another input library: msvcrtd.lib. The build succeeded,
afterwards I had to deploy the msvr90d.dll to the device. The application
worked and did not crash.

cl -Zi -LD -EHsc dll.cpp -link -nodefaultlib corelibc.lib coredll.lib
msvcrtd.lib -subsystem:windowsce -entry:_DllMainCRTStartup -verbose
cl -Zi -EHsc test.cpp dll.lib -link -nodefaultlib corelibc.lib
coredll.lib
msvcrtd.lib -subsystem:windowsce -entry:mainACRTStartup -verbose

b) I replaced the /NODEFAULTLIB with /NODEFAULTLIB:oldnames.lib. The
build
succeeded as well, but the application crashed in the same way I had
described at the beginning of this thread

cl -Zi -LD -EHsc dll.cpp -link -nodefaultlib:oldnames.lib corelibc.lib
coredll.lib -subsystem:windowsce -entry:_DllMainCRTStartup -verbose
cl -Zi -EHsc test.cpp dll.lib -link -nodefaultlib:oldnames.lib
corelibc.lib
coredll.lib -subsystem:windowsce -entry:mainACRTStartup -verbose

The verbose output of the builds can be found in the attached files.


I also tried these solutions with my own test application (completely
from
within VS) and found the same results: when I linked both the Dll and the
executable to the static version of the C runtime library, the
application
crashed, while there was no problem when I linked both to the dll
version. I
should also mention that the version that crashed is based on the
original
settings of the solution after I created it with the wizard in VS.

Do you have 'special default settings' (whatever this could mean) on your
machine that made the build succeed and the application run without
problems?
Though I could change all my projects accordingly I would be glad to have
both options (static and dll).

Many thanks

Hansjoerg




"Leonard Mosescu [MS]" <lemo@xxxxxxxxxxxxxxxxxxxx> schrieb im Newsbeitrag
news:EBF6BB30-4F0F-404E-9ED4-C026BBE3C31E@xxxxxxxxxxxxxxxx
I can't reproduce the issue, see the attached fiels (dll.cpp will compile
to
dll.dll, test.cpp to test.exe, test.h is common). Please try this sample
and
let me know if you're still seeing the issues. The full command lines I
used, for reference, are:

1. cl -Zi -LD -EHsc dll.cpp -link -nodefaultlib corelibc.lib
coredll.lib -subsystem:windowsce -entry:_DllMainCRTStartup
2. cl -Zi -EHsc test.cpp dll.lib -link -nodefaultlib corelibc.lib
coredll.lib -subsystem:windowsce -entry:mainCRTStartup

If you can reproduce the problems, even if you have to change the
attached
files please let me know.

Also, exposing C++ interfaces across module boundaries is not a good
idea
in
general, I'd suggest exposing a C or COM based interface from your DLL.

Thank you,
Leonard.

"hansjoergp" <hansjoergp@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:9AEDFC81-4104-4997-8BCD-755016F98610@xxxxxxxxxxxxxxxx
Hello there,

I am using VS 2008, SP1 in order to create applications for WM 5.0 +.
The
applications are written in C++, no MFC is used.
I have a function in a dll that throws an exception of type class CEx.
It
catches a reference to this exception, does some cleanup work and then
rethrows the exception. When calling this function from a different dll
or
the main executable the application will crash, saying that the
exception
is
unhandled although the function call is properly enclosed in a
try/catch
block.
Some additional points:
* If the called function does not catch and rethrow, the behaviour is
as
expected (i.e. the application remains stable)
* If the thrown exception has a simple type like int, the behaviour is
as
excpected
* If I move the called function into the calling dll or exe, the
behaviour
is as expected
* If new is used to allocate the exception object and pointers to the
exception are caught, the application crashes as well
* If I explicitly rethrow the reference to the exception in the
throwing
function then it works well, however a second call and throw makes the
application 'hang' and the debugger says that it cannot stop the
debugging
session in the emulator

Steps to reproduce (platform: WM 5.0 or 6.0):
1) Create a WIN32 smart device console application
2) Create a WIN32 smart device dll, checking 'export symbols'. This
will
create an exported class and an exported function in the dll
3) Add the member int m_nCode to the created class and change the
constructor so that the code can be passed and set on construction
4) Throw an object of the class from the exported function, enclosing
the
throw in a try/catch block. catch a reference to the exception (but
without a
variable name) and do a rethrow
5) include the dll's header file into the application file
6) from _tmain call the exported function, enclosed in a try/catch
block
7) make the application dependent on the dll
8) build and run in the emulator
9) the application crashes

Can anybody confirm this? What could be the reason?
The test solution can be supplied if necessary.
Many thanks



.

Relevant Pages

  • Re: (Re)throwing from a catch block across dll boundaries
    ... I'll start with the results of my tests: I can reproduce the issue on my system, and it seems to be a question of what C runtime library is linked. ... I also tried these solutions with my own test application and found the same results: when I linked both the Dll and the executable to the static version of the C runtime library, the application crashed, while there was no problem when I linked both to the dll version. ... I have a function in a dll that throws an exception of type class CEx. ... the application crashes as well ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: (Re)throwing from a catch block across dll boundaries
    ... Thank you for the sample project, I'm able to reproduce the issue you're describing. ... within VS) and found the same results: when I linked both the Dll and the ... I have a function in a dll that throws an exception of type class CEx. ... the application crashes as well ...
    (microsoft.public.windowsce.embedded.vc)
  • Global Assembly Cache Issue
    ... I have a dll that I use in several projects, that I placed in the Global ... you can see in the Exception below). ... If I change the Copy Local property of the reference to True, ... Attempting download of new URL ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: (Re)throwing from a catch block across dll boundaries
    ... If you encounter the problems described in this thread, check your compiler settings and change Code Generation/Runtime Library to 'Multi- threaded Debug DLL ' and 'Multi- threaded DLL '. ... I have a function in a dll that throws an exception of type class CEx. ... the application crashes as well ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: (Re)throwing from a catch block across dll boundaries
    ... when I used the command line parameters you have provided for the dll I ... I have a function in a dll that throws an exception of type class CEx. ... the application crashes as well ... Throw an object of the class from the exported function, ...
    (microsoft.public.windowsce.embedded.vc)