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



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
    ... 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. ... I have a function in a dll that throws an exception of type class CEx. ... Throw an object of the class from the exported function, ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: (Re)throwing from a catch block across dll boundaries
    ... I have a function in a dll that throws an exception of type class CEx. ... If the called function does not catch and rethrow, ... Throw an object of the class from the exported function, ...
    (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)
  • Re: (Re)throwing from a catch block across dll boundaries
    ... I have a function in a dll that throws an exception of type class CEx. ... If the called function does not catch and rethrow, ... Throw an object of the class from the exported function, ...
    (microsoft.public.windowsce.embedded.vc)

Loading