Hi all,
I would like to report an issue which is likely to be caused by Symantec Endpoint Protection 12.1, namely UMEngx86.dll. It seems that SEP is somehow messing up the Windows kernel so that C++/CLI interop functionality implemented in the Visual Studio 2013 linker is not working anymore.
I have implemented a bridge in order to call into managed CLR code from native C++ code via C++/CLI wrapper classes. The process is described here (http://blogs.microsoft.co.il/sasha/2008/02/16/net-to-c-bridge/) in detail. The idea is that a truly native C++ library (without CLR) is linked against a C++/CLI library which forwards calls to C# code. Thereby, stubs are injected by the linker into the C++/CLI build which load the CLR before executing the managed code. In detail, the native bridge code references the IL bridge via a forward declaration in the header file, while in the source file of the native bridge, the actual IL bridge header file gets included via “#pragma managed”. The C++/CLI based IL bridge references a C# class via the gcroot<> template and performs the actual marshaling between managed and unmanaged objects.
While this approach looks a bit adventurous, it used to work perfectly with Visual Studio 2013 (Update 1) until some weeks ago, when the bridge suddenly stopped working when building for a 32-bit target. ( The x64 target still works!) Instead, the executable crashes at startup, before the main method is reached, with an exception (0xc0000005) within ntdll.dll caused by an attempt to write to a protected memory location. I suspect this is due to an update to SEP introducing the faulty version of the UMEngx86.dll. The stack trace is as follows, as provided by IDA Pro:
Address Function
------- --------
76FB019A _LdrpSnapThunk@36+101
76FC0E66 _LdrpSnapIAT@12+8D
76FC16D1 _LdrpHandleOneOldFormatImportDescriptor@12+93
76FC171E _LdrpHandleOldFormatImportDescriptors@12+1E
76FC1619 _LdrpProcessStaticImports@8+D5F
76FC6ACD _LdrpInitializeProcess@8-8F4
76FC5712 __LdrpInitialize@8+98F5
76FBBEB4 ntdll_LdrInitializeThunk+B
It’s impossible to debug the EXE with the VS debugger since the application crashes before the debugger gets attached, no matter if the debugger is set to Native or Mixed Mode.
Notably, UMEngx86.dll gets not loaded when running the 64-bit build, which still works perfectly. Also, people in this forum experienced related issues:
This crash can be reproduced by building and running a tiny sample solution with less than 100 LOC (see attachment).
Any help will be greatly appreciated!
Best regards,
Andy