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> >
