You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geode.apache.org by Jeff Y <ge...@gmail.com> on 2018/09/12 02:48:38 UTC
Geode Native (.NET) on Windows 7 (x64)
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
Re: Geode Native (.NET) on Windows 7 (x64)
Posted by Jacob Barrett <jb...@pivotal.io>.
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 <ge...@gmail.com> 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 <jb...@pivotal.io> 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 <jb...@pivotal.io> 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 <ge...@gmail.com> 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 <ge...@gmail.com> 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 <jb...@pivotal.io> 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 <ge...@gmail.com> 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 <jb...@pivotal.io> 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 <ge...@gmail.com> 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 <jb...@pivotal.io> 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 <ge...@gmail.com> 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>
Re: Geode Native (.NET) on Windows 7 (x64)
Posted by Jeff Y <ge...@gmail.com>.
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 <jb...@pivotal.io> 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 <jb...@pivotal.io>
> 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 <ge...@gmail.com> 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 <ge...@gmail.com> 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 <jb...@pivotal.io>
>>> 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 <ge...@gmail.com> 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 <jb...@pivotal.io>
>>>> 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 <ge...@gmail.com> 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 <jb...@pivotal.io>
>>>>> 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 <ge...@gmail.com> 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>
>>
>>
Re: Geode Native (.NET) on Windows 7 (x64)
Posted by Jacob Barrett <jb...@pivotal.io>.
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 <jb...@pivotal.io> 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 <ge...@gmail.com> 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 <ge...@gmail.com> 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 <jb...@pivotal.io>
>> 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 <ge...@gmail.com> 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 <jb...@pivotal.io>
>>> 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 <ge...@gmail.com> 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 <jb...@pivotal.io>
>>>> 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 <ge...@gmail.com> 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>
>
>
Re: Geode Native (.NET) on Windows 7 (x64)
Posted by Jacob Barrett <jb...@pivotal.io>.
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 <ge...@gmail.com> 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 <ge...@gmail.com> 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 <jb...@pivotal.io> 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 <ge...@gmail.com> 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 <jb...@pivotal.io> 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 <ge...@gmail.com> 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 <jb...@pivotal.io> 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 <ge...@gmail.com> 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>
Re: Geode Native (.NET) on Windows 7 (x64)
Posted by Jeff Y <ge...@gmail.com>.
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 <ge...@gmail.com> 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 <jb...@pivotal.io>
> 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 <ge...@gmail.com> 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 <jb...@pivotal.io>
>> 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 <ge...@gmail.com> 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 <jb...@pivotal.io>
>>> 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 <ge...@gmail.com> 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>
>>>>
>>>
Re: Geode Native (.NET) on Windows 7 (x64)
Posted by Jeff Y <ge...@gmail.com>.
Let me give that a try and report back, thanks for the suggestion!
On Wed, Sep 12, 2018 at 12:24 PM Jacob Barrett <jb...@pivotal.io> 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 <ge...@gmail.com> 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 <jb...@pivotal.io> 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 <ge...@gmail.com> 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 <jb...@pivotal.io> 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 <ge...@gmail.com> 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>
>>>
>>
Re: Geode Native (.NET) on Windows 7 (x64)
Posted by Jacob Barrett <jb...@pivotal.io>.
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 <ge...@gmail.com> 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 <jb...@pivotal.io> 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 <ge...@gmail.com> 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 <jb...@pivotal.io> 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 <ge...@gmail.com> 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>
Re: Geode Native (.NET) on Windows 7 (x64)
Posted by Jeff Y <ge...@gmail.com>.
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 <jb...@pivotal.io> 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 <ge...@gmail.com> 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 <jb...@pivotal.io> 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 <ge...@gmail.com> 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>
>>
>
Re: Geode Native (.NET) on Windows 7 (x64)
Posted by Jacob Barrett <jb...@pivotal.io>.
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 <ge...@gmail.com> 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 <jb...@pivotal.io> 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 <ge...@gmail.com> 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>
Re: Geode Native (.NET) on Windows 7 (x64)
Posted by Jeff Y <ge...@gmail.com>.
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 <jb...@pivotal.io> 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 <ge...@gmail.com> 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>
>
Re: Geode Native (.NET) on Windows 7 (x64)
Posted by Jacob Barrett <jb...@pivotal.io>.
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 <ge...@gmail.com> 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>