Good deal! Since it blows up in the C++/CLR runtime I’d suggest focusing on anything that inits when the IJW initializes. We had to refactor a ton of global initialization to modernize. Perhaps something there isn’t compatible.
Also check your machine for multiple versions of that runtime. I found several in windows side by side. Maybe the wrong one is loading? DLL hell! Good luck! -Jake > On Sep 14, 2018, at 4:11 PM, Jeff Y <[email protected]> wrote: > > 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>
