Managed C++ Mixed Assembly fails on XP (VS2005SP1)

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Olivier Matrot - 09 May 2007 09:01 GMT

Hello,

I'm working with a Managed C++ Mixed assembly that works fine on Vista, both
in debug and release mode.
Howerver this assembly fails on XPSP2 in release mode. Works fine in debug
mode. This assemby is a DLL that is loaded from a win32 service. It is
written with Visual Studio 2005 SP1.

I wrote a small test program that is run in debug mode.
With the DLL in release mode, here is the exception :
An exception of type 'System.Runtime.InteropServices.COMException' occurred
in mscorlib.dll but was not handled in user code

Additional information: Descripteur non valide (Exception from HRESULT:
0x80070006 (E_HANDLE))

The debugger stops in msilexit.cpp int the following function :
extern "C" void __clrcall _app_exit_callback(void)

{

/*

* Note that this function is called during appdomain unload.

* Thus there should be only one thread calling this function per

* appdomain. Thus this function does not need to be under lock.

*

* Note: verify that when domainUnload event is generated, there

* are no threads executing in this appdomain. If this is not the

* case then we will need to have lock around this function.

*/

_CPVFV * onexitbegin_app_domain = (_CPVFV *)
_decode_pointer(__onexitbegin_app_domain);

_CPVFV * onexitend_app_domain = (_CPVFV *)
_decode_pointer(__onexitend_app_domain);

if ((onexitbegin_app_domain != (_CPVFV *)-1) && (onexitbegin_app_domain !=
NULL) && (onexitend_app_domain != NULL)) {

__try

{

while (--onexitend_app_domain >= onexitbegin_app_domain) {

if (*onexitend_app_domain != _encoded_null()) {

(*(_CPVFV)_decode_pointer(*onexitend_app_domain))();

}

}

}

__finally

{

System::Runtime::InteropServices::Marshal::FreeHGlobal(

System::IntPtr((void *)onexitbegin_app_domain));

}

}

}

Specifically the code fails within the call to FreeHGlobal.

Thanks for your Help.

Reply to this Message

Olivier Matrot - 09 May 2007 14:24 GMT

More informations:
The DLL is dynamically loaded with LoadLibrary.
The exception is generated when calling an exported function. I have reduced
the code of this function to just return (do nothing), and it never return
but fails. It seems that it is a .NET Framework loading issue.

Here is the output of the VS2005 debugger :

'testoledb.exe': Loaded 'C:\Program Files\RTE\RTE FAX\FAX
Server\OLEDB\rtefcddbxp.dll', Symbols loaded.

'testoledb.exe': Loaded 'C:\WINDOWS\system32\mscoree.dll', No symbols
loaded.

'testoledb.exe': Loaded 'C:\WINDOWS\system32\version.dll', No symbols
loaded.

'testoledb.exe': Loaded
'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\msvcr80.dll',
Symbols loaded.

'testoledb.exe': Loaded
'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.MFC_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_3bf8fa05\mfc80.dll',
Symbols loaded.

'testoledb.exe': Loaded
'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\msvcm80.dll',
Symbols loaded.

'testoledb.exe': Loaded
'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.MFCLOC_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_91481303\mfc80FRA.dll',
Binary was not built with debug information.

'testoledb.exe': Loaded
'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll', No symbols
loaded.

'testoledb.exe': Loaded
'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Culture.dll', No symbols
loaded.

'testoledb.exe': Unloaded
'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Culture.dll'

'testoledb.exe': Loaded
'C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\mscorlib\dfe5673f59b9b9439038f27549b30383\mscorlib.ni.dll',
No symbols loaded.

'testoledb.exe': Loaded
'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorjit.dll', No symbols
loaded.

'testoledb.exe': Loaded 'C:\WINDOWS\system32\rsaenh.dll', No symbols loaded.

First-chance exception at 0x7c97cc82 in testoledb.exe: 0xC0000005: Access
violation reading location 0x1e4b3411.

First-chance exception at 0x78138be3 (msvcr80.dll) in testoledb.exe:
0xC0000005: Access violation writing location 0x1e4b3412.

First-chance exception at 0x7c97df51 in testoledb.exe: 0xC0000005: Access
violation reading location 0x1e4b340a.

First-chance exception at 0x7c812a5b in testoledb.exe: Microsoft C++
exception: EEMessageException at memory location 0x0012d21c..

First-chance exception at 0x7c812a5b in testoledb.exe: 0xE0434F4D:
0xe0434f4d.

First-chance exception at 0x7c812a5b in testoledb.exe: 0xE0434F4D:
0xe0434f4d.

First-chance exception at 0x7c812a5b in testoledb.exe: 0xE0434F4D:
0xe0434f4d.

First-chance exception at 0x7c812a5b in testoledb.exe: Microsoft C++
exception: [rethrow] at memory location 0x00000000..

> Hello,
>
[quoted text clipped - 77 lines]
>
> Thanks for your Help.

Reply to this Message

Olivier Matrot - 09 May 2007 15:39 GMT

Another information :
The code fails in msstartup.cpp function void Initialize().

> More informations:
> The DLL is dynamically loaded with LoadLibrary.
[quoted text clipped - 157 lines]
>>
>> Thanks for your Help.

Reply to this Message

Olivier Matrot - 14 May 2007 13:41 GMT

In release mode, but linked with de debug version of the MFC redistribuable,
everything is fine.
May be there is a bug in the release version of the DLL.

> Another information :
> The code fails in msstartup.cpp function void Initialize().
[quoted text clipped - 160 lines]
>>>
>>> Thanks for your Help.

Reply to this Message

Olivier Matrot - 22 May 2007 08:25 GMT

Found the solution this morning after spending one day investigating this
weird behavior :
I missed to tell yet that my project was initially created in Visual Studio
.NET (and converted in VS2005). So, I started a similar project from scratch
in VS2005 and was not able to reproduce the problem !

I compared each project settings to finally find out that a "/NOENTRY"
linker advanced option is present in the failing project !?! I removed this
option and rebuilt the project. It failed with a linking error "_DllMain@12
already defined in msvcrt.lib". With the /VERBOSE option, I have compared
the libraries used in both project.

It turns out that the MFC libraries must be linked before the CRT libraries
!!! This explains that unmanaged code calling managed code fails. So simply
ignore and include "mfcs80.lib" in the linker input options.

> In release mode, but linked with de debug version of the MFC
> redistribuable, everything is fine.
[quoted text clipped - 164 lines]
>>>>
>>>> Thanks for your Help.

Reply to this Message

Managed C++ Mixed Assembly fails on XP (VS2005SP1)

Free Magazines