I appreciate you taking the time to help me look into it! Today I tried something that ended up working (hooray). The pre-modernization source is still built against VC++ 2013 and I noticed that the Pivotal Gemfire DLL for 9.2.1 is built against VC++ 2013 as well (and it works on Windows 7). I figured I'd give the pre-modernization code a try and lo-and-behold it worked! While it's obviously missing a lot of fixes and refactoring, it should be suitable for my needs. Why Windows 7 isn't liking the newer code with VC++ 2015 is certainly a confusing issue, one that I hope to figure out at some point (although it may be awhile). If I do figure out how to get the latest code working I'll reply here so at least there's a record of how to make it work with Windows 7.
Thanks again for all of your help and suggestion, I really appreciate. Best, Jeff On Fri, Sep 14, 2018 at 6:02 PM Jacob Barrett <[email protected]> wrote: > I see that same dll being loaded on my builds too. I can only guess that > C++/CLR runtime hasn't evolved past that version of the runtime. > > As to why it is failing on Windows 7, you have me stumped. I don't have > Windows 7 and likely won't have time anytime soon to create an image and > test. > > Best I can suggest right now is to do some googling on some of the symbols > in your stack and see if others have seen this. You may just be out of luck > given the lack of support across the board for Windows 7. > > Sorry, > Jake > > > On Wed, Sep 12, 2018 at 12:03 PM Jacob Barrett <[email protected]> > wrote: > >> 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> >> >>
