Now that sounds really strange that both are loading that dll. Give me some time to check on my host if that dll is coming into play at all.
The reason you aren’t seeing the other C runtime libraries loading on windows 7 is that this library is crashing while initializing. -Jake > On Sep 12, 2018, at 10:18 AM, Jeff Y <[email protected]> wrote: > > I took the output of the loaded DLLs from ProcMon (once the application had > either fully loaded or at the crash) on both Windows 10 and Windows 7 (I've > attached them and screenshots of the Load Image events). This is from the > same sample application using the same Apache.Geode.dll, just run on the > different PCs. > > Both Windows 10 and Windows 7 load the msvcr120_clr0400.dll, however I see > Windows 10 properly loading vcruntime140.dll and msvcp140.dll, whereas in > Windows 7 this is not happening (neither are showing as loaded). I guess the > question now is why is it that the same application trying to load the > correct DLLs on one and not the other? I don't even see any queries for > msvcp140.dll, for example, on Windows 7. > > Jeff > >> On Wed, Sep 12, 2018 at 12:25 PM Jeff Y <[email protected]> wrote: >> 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> > <dll_dump_win10.txt> > <loaded_dlls_win10.png> > <loaded_dlls_win7.png> > <dll_dump_win7.txt>
