I believe the msvcr120_clr0400.dll seen in the stacktrace comes out of the .NET CLR directly. My sample application setup is simply create a C# Console Application in VS2015, add the reference to the Apache.Geode.dll and that's it. Is there anything else I need to do to make it target the proper CLR runtime (project by default targets .NET 4.5.2)? The Apache.Geode.dll already shows msvcp140.dll and vcruntime140.dll in dependency walker, so I think the DLL itself is OK. I feel like I'm missing something simple because I don't understand why the msvcr120_clr0400.dll would be used for a VS2015 project (granted I'm very new to C# dev).
Jeff On Wed, Sep 12, 2018 at 1:59 AM Jacob Barrett <[email protected]> wrote: > The stack trace implies your application is linked with the VS2013 C > runtimes. This will not work when mixed with the library linked against the > VS2015 C runtimes. Make sure all your code is compiling with VS2015. > > -Jake > > > On Sep 11, 2018, at 8:52 PM, Jeff Y <[email protected]> wrote: > > Agreed, Windows 7 is quite old now and I can understand why there is no > intention to test on it. I have a particular use case where there will be > Windows 7 clients for at least awhile, unfortunately. The latest native > Gemfire DLL seems to work fine so I was hopeful, but obviously that's a > different code base. I do have it compiled on Win 7 with VS2015, so at > least that's a start. > > Unfortunately it looks like it might be difficult to get a full dump. > Whenever I try to dump out of Visual Studio or through Procdump using my > small sample app I get a very similar looking "Invalid access to memory > location" and the dump fails (as seen below). I've also included the stack > trace at the time of the exception, but not sure how useful that will be. > > Procdump output: > ----------------------- > [23:46:39] Dump 1 initiated: C:\Users\TestVM\Documents\Visual Studio > 2015\Projec > > ts\ConsoleApplication1\ConsoleApplication1\bin\x64\Debug\ConsoleApplication1.exe > _180911_234639.dmp > [23:46:39] Dump 1 error: Error writing dump file: 0x800703E6 > Invalid access to memory location. (0x800703E6, -2147023898) > > Stacktrace at the time the exception is thrown > -------------------------------------------------------------- > > ntdll.dll!RtlPcToFileHeader () Unknown > msvcr120_clr0400.dll!_CxxThrowException () Unknown > msvcr120_clr0400.dll!_CallSettingFrame () Unknown > msvcr120_clr0400.dll!__CxxCallCatchBlock () Unknown > ntdll.dll!RcFrameConsolidation () Unknown > clrjit.dll!Compiler::lvaInitTypeRef() Line 316 C++ > clrjit.dll!Compiler::compCompileHelper(CORINFO_MODULE_STRUCT_ * > classPtr, ICorJitInfo * compHnd, CORINFO_METHOD_INFO * methodInfo, void * * > methodCodePtr, unsigned long * methodCodeSize, JitFlags * compileFlags, > CorInfoInstantiationVerification) Line 5874 C++ > clrjit.dll!Compiler::compCompile(CORINFO_METHOD_STRUCT_ * methodHnd, > CORINFO_MODULE_STRUCT_ * classPtr, ICorJitInfo * compHnd, > CORINFO_METHOD_INFO * methodInfo, void * * methodCodePtr, unsigned long * > methodCodeSize, JitFlags * compileFlags) Line 5359 C++ > clrjit.dll!jitNativeCode(CORINFO_METHOD_STRUCT_ * methodHnd, > CORINFO_MODULE_STRUCT_ * classPtr, ICorJitInfo * compHnd, > CORINFO_METHOD_INFO * methodInfo, void * * methodCodePtr, unsigned long * > methodCodeSize, JitFlags * compileFlags, void * inlineInfoPtr) Line 6666 > C++ > clrjit.dll!CILJit::compileMethod(ICorJitInfo * compHnd, > CORINFO_METHOD_INFO * methodInfo, unsigned int flags, unsigned char * * > entryAddress, unsigned long * nativeSizeOfCode) Line 315 C++ > mscoreei.dll!_CorExeMain () Unknown > mscoree.dll!_CorExeMain_Exported () Unknown > kernel32.dll!BaseThreadInitThunk () Unknown > ntdll.dll!RtlUserThreadStart () Unknown > > > > On Tue, Sep 11, 2018, 11:15 PM Jacob Barrett <[email protected]> wrote: > >> The sources at the HEAD of develop branch have not been tested on Windows >> 7. Since Windows 7 is very old and out of general support from Microsoft we >> don’t have any intention of testing on it. >> >> Your best bet is to compile on Windows 7 with VS2015 and then run in the >> debugger. If you can provide a stack dump we might be able to point you in >> a direction. >> >> -Jake >> >> >> > On Sep 11, 2018, at 7:48 PM, Jeff Y <[email protected]> wrote: >> > >> > Has anyone had any luck compiling a Geode .NET DLL that works on >> Windows 7? Following the BUILDING.md I can generate a DLL successfully that >> works on Windows 10, however if I take that same DLL to Windows 7 I get >> this error when the DLL is loaded (picture is attached): >> > >> > "The instruction at 0x77a3ce4b referenced memory at 0x00000050. The >> memory could not be read." >> > >> > The actual exception is a System.AccessViolationException in >> mscorlib.dll. >> > >> > At this point the application does not proceed. I'm able to replicate >> it in something as simple as a console application which references the DLL >> and then tries to use some class from it (ie: CacheFactory f = new >> CacheFactory()) in the main method. In my sample application it doesn't >> specifically reference the memory instruction, just that: "Attempted to >> read or write protected memory. This is often an indication that other >> memory is corrupt". >> > >> > I've tried a number things already including but not limited to: >> > >> > 1. Recompiling the same DLL on the Windows 7 machine itself (following >> the same BUILDING.md instructions). >> > >> > 2. Installing VC++ 2015 redistributable (both x64 and x86 for good >> measure). I subsequently installed 2008, 2010, 2012, 2013 and 2017 >> redistributables as well. I've also included the VC++ runtime DLLs in >> various locations relevant to the application (just in case it wasn't >> picking up from System32) >> > >> > 3. Retargeting CMake to build using VS2013 and VS2017 generators >> instead of VS2015. VS2013 I couldn't get to compile, likely due to C++11 >> not being supported/fully supported. VS2017 had some issues with auto&& >> pointers, but I was at least able to get it to compile eventually. The same >> error occurs, though. >> > >> > When I put the DLL into Dependencies it's able to resolve all required >> DLLs. My testing machine is a vanilla Windows 7 SP1 installation with .NET >> 4.7.2 installed (started with 4.5.2 and gradually upgraded as I tested out >> various configurations). >> > >> > Any help or advice would be greatly appreciated. >> > >> > Thanks, >> > Jeffrey Yankowski >> > <geode_native_win7_error.png> >> >
