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>
