Giovanni Dicanio wrote:
Hello. I have problems with an applications consisting of mixed
native and managed code writted in C++/CLI in Visual Studio 2005.
The application runs fine in "Debug mode", however when I compile
the application in "Release" mode I run into the following
exception:
When you compile in release mode, are you sure that all the DLLs (I
assume these are C++ or C++/CLI DLLs) you link with are built in
release mode, and that you use the same version of the CRT (e.g.
multithreaded DLL)?
Hello. All the modules that are linked with the application are built
in release mode.
This is a list of all the units that are linked together, including
the settings for MFC, CLR and standard library.
3DWorkBench.exe (C++/CLI) MFC in shared DLL CLR=Yes CRT=MT DLL
AcqusitionLib.lib (C++) Standard Windows lib. CLR=No CRT=MT DLL
GCPS.lib (C++) MFC in shared DLL CLR=No CRT=MT DLL
GcpsConfigLib (C++/CLI) Standard Windows lib. CLR=Yes CRT=MT DLL
GcpsDotNetApi.dll (C++/CLI) MFC in shared DLL CLR=Yes CRT=MT DLL
LibHvUtil.lib (C++) Standard Windows lib. CLR=No CRT=MT DLL
MSDN.Configuration.dll (VB) Visual Basic .NET class library
ScalablePictureBox.dll (C#) Visual C# .NET class library
Dependency walker says that GcpsDotNetApi.dll is dependent on the
following libraries:
c:\windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\MSVCR80.DLL
c:\windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\MSVCP80.DLL
c:\windows\winsxs\x86_microsoft.vc80.mfc_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_3bf8fa05\MFC80.DLL
c:\windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\MSVCM80.DLL
c:\windows\system32\KERNEL32.DLL
c:\windows\system32\USER32.DLL
c:\windows\system32\OLEAUT32.DLL
c:\windows\system32\GDI32.DLL
c:\windows\system32\MSCOREE.DLL
Any other ideas for what could be causing my error? It would be very
helpful if there is anything that I can do to debug what is causing
the "access violation during native initialization" of the
GcpsDotNetApi.dll file.
pretty low quality. With a debugger attached, you'll trap the first-chance
exception, at the point where the AV actually occurs.