That msvcr120_clr0400.dll definitely is a problem and shouldn’t be there. I wonder if perhaps you have an other compile of the Geode native libraries somewhere in you path that is getting picked up. An easy test would be to move msvcr120_clr0400.dll off the system so it will fail to load it. Then use procmon to watch dll loads and see what is trying to load it at runtime.
> On Sep 12, 2018, at 9:01 AM, Jeff Y <[email protected]> wrote: > > 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>
