Let me give that a try and report back, thanks for the suggestion! On Wed, Sep 12, 2018 at 12:24 PM Jacob Barrett <[email protected]> wrote:
> 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> >>> >>
