Managed / Unmanaged code fails to start on some machines
===

I'm assuming that the reader is familiar with mixed managed/unmanaged code systems and why they are necessary. This question will not deal with that but rather the mechanics of building such a system with Visual Studio 2008 compiler and linker controls.

The Background
--------------

First, get rid of the chaff. My investigation distils to the following:

+ Initial C++ project is MFC based
+ MFC in a Shared dll
+ No clr
+ C++ Exceptions /EHa
+ Multi-threaded debug /MD

This all builds and runs correctly on all of our developer workstations under Visual Studio 2008.

We now include a third party C# .NET3.5 SP1 library to the project. This library is built using a native C++ bridge for the interop. The original C++ project references the import file for this new library as part of its Linker Input. All pretty standard stuff and well referenced on the forums.

The third party library is built as follows:

 - Common Language Runtime support /clr
 - C++ Exceptions /EHa
 - Multi-threaded debug /MD

The Problem
-----------
On eight of our developer workstations, the Debug (and Release) builds all build and launch correctly. Only one of our developer workstations gets the following error at launch:

>Windows has triggered a breakpoint in blah.exe.  
>This may be due to a corruption in the heap, which indicates a bug in blah.exe, or any of the DLLs it has loaded.

This happens all before application launch and is proving difficult to track down. I've used/tried/eliminated the following:

- An incorrectly configured Workstation. In saying that, no two workstations are exactly the same. Yes, they all have the same tools and operating systems (Windows-7) but beyond that they will have been configured slightly differently.
- Depedency Walker
- Process analysis tools (ProcMon)
- Static library builds not in line with each other leading to mismatched heaps. The compiler switch /MD is aligned for both codebases. In saying that, the heap of the CLR will always differ from that of native code.

The Solution
------------
All problems disappear if I now simply switch on the */clr* for the C++ build. Why? I would suspect that both code spaces will now use the same heap. Surely different run time environments is what mixed mode is all about? This is not a preferred solution.

Any ideas?



Appendix
--------
C++ Project compiler options (Debug build):

> /Od /D "WIN32" /D "_WINDOWS" /D "_DEBUG"
> /D "_VC80_UPGRADE=0x0710" /D "_AFXDLL" /D "_MBCS" /FD /EHa /MDd
> /Yu"stdafx.h" /Fp"Debug\blah.pch" /Fo"Debug\\"
> /Fd"Debug\vc90.pdb" /W3 /WX /nologo /c /Zi /clr /TP /wd4793 /wd4996
> /errorReport:prompt

C++ Project linker options (Debug build):

> /OUT:"..\Debug\blah.exe" /INCREMENTAL /NOLOGO /MANIFEST
> /MANIFESTFILE:"Debug\blah.exe.intermediate.manifest"
> /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG
> /ASSEMBLYDEBUG /PDB:"blah.pdb" /SUBSYSTEM:WINDOWS /LARGEADDRESSAWARE
> /DYNAMICBASE:NO /FIXED:No /MACHINE:X86 /ERRORREPORT:PROMPT
> iphlpapi.lib UxTheme.lib ../Libraries/Bridge.lib

C# .NET library compiler options (Debug build):

> /Od /D "WIN32" /D "_DEBUG" /D "_WINDLL" /D "_UNICODE" /D "UNICODE" /FD
> /EHa /MDd /Yu"stdafx.h" /Fp"Debug\Bridge.pch" /Fo"Debug\\"
> /Fd"Debug\vc90.pdb" /W3 /nologo /c /Zi /clr /TP /errorReport:prompt
> /FU "c:\Windows\Microsoft.NET\Framework\v2.0.50727\System.dll" /FU
> "c:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Data.dll" /FU
> "c:\Windows\Microsoft.NET\Framework\v2.0.50727\System.XML.dll" /FU
> "Library.dll"

C# .NET library linker options (Debug build):

> /OUT:"Bridge.dll" /INCREMENTAL /NOLOGO /DLL /MANIFEST
> /MANIFESTFILE:"Debug\Bridge.dll.intermediate.manifest"
> /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG
> /ASSEMBLYDEBUG /PDB:"Bridge.pdb" /DYNAMICBASE /FIXED:No /NXCOMPAT
> /MACHINE:X86 /ERRORREPORT:PROMPT



