C++\CLI applicatin crash on load

Question

I have a C++ app that loads lot of C++ DLL and few selected C++\\CLI ones. On one of the machines (Windows Server 2003 SP2) on start-up I was getting error message

Answer 1

I see you loading winsta.dll - an issue on the MSDN forums (and common with a server application I'm developing) shows that Terminal Services on XP/2003 causes a loading error for C++/CLI mixed-mode DLLs (at least for CLR2) on TS sessions. A workaround would be to use VNC/similar.

Answer 2

I had a similar issue today on a Windows 2003 SP2 server .. and the solution I found was to delay load the problematic dll.

As given in

https://connect.microsoft.com/VisualStudio/feedback/details/586715/unmanaged-exe-linked-to-a-mixed-mode-dll-crashes-at-startup-on-some-xp-machines

My main app was in Delphi 2010 and I used the delayed keyword in delphi as given in

http://www.drbob42.com/examines/examinC1.htm

It works like a charm now ..

Answer 3

I ran into a similar problem with a C++/CLI application crashing during start-up and it was also pretty obscure, it took me some debugging and googling to find out that the culprit was the WinMM DLL (Windows Multimedia library) that was doing some "unsafe" stuff in it's entry point function (namelly calling "FreeLibrary" multiple times - something that I think is explicitly marked as unsafe in the documentation). I did find some KB article or post in the Microsoft Website about this and the solution was - as in your case - to dynamically load the DLL (that has the same effect as the /DELAYLOAD switch) instead of linking statically to it.

In your case I see that you also load the WinMM library. Is it loaded directly by your application or indireclty via your CustomCpp_CLI module? Would be interesting to know if you have the same problem but in any case it seems that the general rule is that it's not safe to statically link to some "misbehaving" DLLs in a C++/CLI project.

Answer 4

I've run into this exact same problem and tried several different strategies that I ultimately had to discard due to issues with the codebase I'm working in. The /delayload strategy wasn't an option for me.

However I stumbled upon this posting on Microsoft Connect that provides a workaround that works fairly well for me.

Basically the unmanaged C++ executable needs to link to the lib file for the mixed mode C++ dll before linking to the lib files for any unmanaged C++ dlls.

I specified this option by:

1. Go into the Properties dialog for the executable project.
2. Select Linker-> input tab.
3. Add the mixed mode lib file to the beginning of the Additional Dependencies field.

For my situation this has been the best solution. It lets me take advantage of my mixed mode dll without having to do a ton of work or causing a huge QA burden.

Another potential solution that works, but wasn't useful for the code base that I'm working with is to make the unmanaged C++ executable a mixed mode executable.

To do this without making the entire exe a CLR exe...

1. Add a new cpp file to the project.

2. Right click on that cpp file.

3. Select Properties.

4. Select the general tab

5. Set the Common Language Runtime Support flag to /clr.

The cpp file can be empty, it doesn't need a class defined. It just needs to be there to make the executable mixed mode so that it correctly links everything.

Hopefully one of these solutions helps someone out in the future so they don't have to spend a ton of time figuring out this problem.