 | |
"Attempted to read or write protected memory" on some vista machin
Dotnet Framework (Interop) microsoft.public.dotnet.framework.interop
 |
| | Thread Tools | Search this Thread | Display Modes |
#1
 
| |||
| |||
|
"Attempted to read or write protected memory" on some vista machin -
12-17-2007
, 11:14 PM
#2
| |||
| |||
|
|
I have a strange issue when using a COM component in VS 2005 or 2008. If I compile my application and run it, it works on any xp machine, but does not work on most vista machines. I get an "Attempted to read or write protected memory" error on a certain line. I contacted the vendor of the com component about this issue, sent them a sample project to demonstrate it and they were able to reproduce it with the build i sent them. But, when they recompiled it, the issue went away. I ran their build of my sample project on several installations of vista and all editions and it works just fine. My question is, what could cause a problem like this? I did a binary comparison of both builds and there are definate differences between them (not that I know what they mean). No code was changed at all, and i even tried changing the compile settings such as turning off optimizations, switching between release/debug and even turned off the "suppress JIT optimizations on module load" option in tools->options->debugging->general and nothing changed. What could be different about my install of visual studio 2005 and 2008 that would produce different IL on different machines? Anyone run into this problem before? |
#3
| |||
| |||
|
|
This may be due to ASLR and DEP (or a combination thereof) on Vista. ASLR basically means the load/heap/stack address of the application is randomly changed for each execution. This is a security feature that makes it hard to exploit an application's buffer over-/under-flow flaws. DEP is another security feature that disallows execution of code from data pages. For non exploited applications expecting to access data a constant memory address (ASLR) or expecting to be able to execute code from a data page, this would cause the error you see. I think DEP is also in XP, so it may simply be ASLR causing the problem. As far as I know a binary has to opt into ASLR, which means the vendor is compiling/linking with the /DYNAMICBASE command-line argument. You could try disabling DEP to see if that makes the problem go away. There's some good websites that explain how to do that, like : http://vistasupport.mvps.org/disable...prevention.htm -- Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote. http://www.peterRitchie.com/blog/ Microsoft MVP, Visual Developer - Visual C# "Jason Rodman" wrote: I have a strange issue when using a COM component in VS 2005 or 2008. If I compile my application and run it, it works on any xp machine, but does not work on most vista machines. I get an "Attempted to read or write protected memory" error on a certain line. I contacted the vendor of the com component about this issue, sent them a sample project to demonstrate it and they were able to reproduce it with the build i sent them. But, when they recompiled it, the issue went away. I ran their build of my sample project on several installations of vista and all editions and it works just fine. My question is, what could cause a problem like this? I did a binary comparison of both builds and there are definate differences between them (not that I know what they mean). No code was changed at all, and i even tried changing the compile settings such as turning off optimizations, switching between release/debug and even turned off the "suppress JIT optimizations on module load" option in tools->options->debugging->general and nothing changed. What could be different about my install of visual studio 2005 and 2008 that would produce different IL on different machines? Anyone run into this problem before? |
#4
| |||
| |||
|
|
Thanks for your reply Peter. Im not sure this makes much sense, why would one build from one machine work, and another build from a different machine not work. Same exact vb code, same exact COM dll. If it was ASLR or DEP, wouldnt it break for both builds? I dont think the issue is on the host vista machine, but more in the vb compiler. What could be different in the build that would cause this to fail? "Peter Ritchie [C# MVP]" wrote: This may be due to ASLR and DEP (or a combination thereof) on Vista. ASLR basically means the load/heap/stack address of the application is randomly changed for each execution. This is a security feature that makes it hard to exploit an application's buffer over-/under-flow flaws. DEP is another security feature that disallows execution of code from data pages. For non exploited applications expecting to access data a constant memory address (ASLR) or expecting to be able to execute code from a data page, this would cause the error you see. I think DEP is also in XP, so it may simply be ASLR causing the problem. As far as I know a binary has to opt into ASLR, which means the vendor is compiling/linking with the /DYNAMICBASE command-line argument. You could try disabling DEP to see if that makes the problem go away. There's some good websites that explain how to do that, like : http://vistasupport.mvps.org/disable...prevention.htm -- Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote. http://www.peterRitchie.com/blog/ Microsoft MVP, Visual Developer - Visual C# "Jason Rodman" wrote: I have a strange issue when using a COM component in VS 2005 or 2008. If I compile my application and run it, it works on any xp machine, but does not work on most vista machines. I get an "Attempted to read or write protected memory" error on a certain line. I contacted the vendor of the com component about this issue, sent them a sample project to demonstrate it and they were able to reproduce it with the build i sent them. But, when they recompiled it, the issue went away. I ran their build of my sample project on several installations of vista and all editions and it works just fine. My question is, what could cause a problem like this? I did a binary comparison of both builds and there are definate differences between them (not that I know what they mean). No code was changed at all, and i even tried changing the compile settings such as turning off optimizations, switching between release/debug and even turned off the "suppress JIT optimizations on module load" option in tools->options->debugging->general and nothing changed. What could be different about my install of visual studio 2005 and 2008 that would produce different IL on different machines? Anyone run into this problem before? |
#5
| |||
| |||
|
|
It could be that the vendor does not have VS 2005 SP1 installed. the /DYNAMICBASE option was added in SP1 [1]. If you were using it in your project in VS 2005 w/SP1 and compiled it there and give it to someone else, it would be randomizing load/stack/heap addresses; if you gave someone without SP1 the project, they would compile it without radomized load/stack/heap addresses and may not exhibit the problem. [1] http://blogs.msdn.com/michael_howard...-and-aslr.aspx -- Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote. http://www.peterRitchie.com/blog/ Microsoft MVP, Visual Developer - Visual C# "Jason Rodman" wrote: Thanks for your reply Peter. Im not sure this makes much sense, why would one build from one machine work, and another build from a different machine not work. Same exact vb code, same exact COM dll. If it was ASLR or DEP, wouldnt it break for both builds? I dont think the issue is on the host vista machine, but more in the vb compiler. What could be different in the build that would cause this to fail? "Peter Ritchie [C# MVP]" wrote: This may be due to ASLR and DEP (or a combination thereof) on Vista. ASLR basically means the load/heap/stack address of the application is randomly changed for each execution. This is a security feature that makes it hard to exploit an application's buffer over-/under-flow flaws. DEP is another security feature that disallows execution of code from data pages. For non exploited applications expecting to access data a constant memory address (ASLR) or expecting to be able to execute code from a data page, this would cause the error you see. I think DEP is also in XP, so it may simply be ASLR causing the problem. As far as I know a binary has to opt into ASLR, which means the vendor is compiling/linking with the /DYNAMICBASE command-line argument. You could try disabling DEP to see if that makes the problem go away. There's some good websites that explain how to do that, like : http://vistasupport.mvps.org/disable...prevention.htm -- Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote. http://www.peterRitchie.com/blog/ Microsoft MVP, Visual Developer - Visual C# "Jason Rodman" wrote: I have a strange issue when using a COM component in VS 2005 or 2008. If I compile my application and run it, it works on any xp machine, but does not work on most vista machines. I get an "Attempted to read or write protected memory" error on a certain line. I contacted the vendor of the com component about this issue, sent them a sample project to demonstrate it and they were able to reproduce it with the build i sent them. But, when they recompiled it, the issue went away. I ran their build of my sample project on several installations of vista and all editions and it works just fine. My question is, what could cause a problem like this? I did a binary comparison of both builds and there are definate differences between them (not that I know what they mean). No code was changed at all, and i even tried changing the compile settings such as turning off optimizations, switching between release/debug and even turned off the "suppress JIT optimizations on module load" option in tools->options->debugging->general and nothing changed. What could be different about my install of visual studio 2005 and 2008 that would produce different IL on different machines? Anyone run into this problem before? |
#6
| |||
| |||
|
|
I see. So by disabling this we can test to see if this is the issue. If this does turn out to be the problem, how could I fix the issue on my end without having to affect the end user's machine? "Peter Ritchie [C# MVP]" wrote: It could be that the vendor does not have VS 2005 SP1 installed. the /DYNAMICBASE option was added in SP1 [1]. If you were using it in your project in VS 2005 w/SP1 and compiled it there and give it to someone else, it would be randomizing load/stack/heap addresses; if you gave someone without SP1 the project, they would compile it without radomized load/stack/heap addresses and may not exhibit the problem. [1] http://blogs.msdn.com/michael_howard...-and-aslr.aspx -- Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote. http://www.peterRitchie.com/blog/ Microsoft MVP, Visual Developer - Visual C# "Jason Rodman" wrote: Thanks for your reply Peter. Im not sure this makes much sense, why would one build from one machine work, and another build from a different machine not work. Same exact vb code, same exact COM dll. If it was ASLR or DEP, wouldnt it break for both builds? I dont think the issue is on the host vista machine, but more in the vb compiler. What could be different in the build that would cause this to fail? "Peter Ritchie [C# MVP]" wrote: This may be due to ASLR and DEP (or a combination thereof) on Vista. ASLR basically means the load/heap/stack address of the application is randomly changed for each execution. This is a security feature that makes it hard to exploit an application's buffer over-/under-flow flaws. DEP is another security feature that disallows execution of code from data pages. For non exploited applications expecting to access data a constant memory address (ASLR) or expecting to be able to execute code from a data page, this would cause the error you see. I think DEP is also in XP, so it may simply be ASLR causing the problem. As far as I know a binary has to opt into ASLR, which means the vendor is compiling/linking with the /DYNAMICBASE command-line argument. You could try disabling DEP to see if that makes the problem go away. There's some good websites that explain how to do that, like : http://vistasupport.mvps.org/disable...prevention.htm -- Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote. http://www.peterRitchie.com/blog/ Microsoft MVP, Visual Developer - Visual C# "Jason Rodman" wrote: I have a strange issue when using a COM component in VS 2005 or 2008. If I compile my application and run it, it works on any xp machine, but does not work on most vista machines. I get an "Attempted to read or write protected memory" error on a certain line. I contacted the vendor of the com component about this issue, sent them a sample project to demonstrate it and they were able to reproduce it with the build i sent them. But, when they recompiled it, the issue went away. I ran their build of my sample project on several installations of vista and all editions and it works just fine. My question is, what could cause a problem like this? I did a binary comparison of both builds and there are definate differences between them (not that I know what they mean). No code was changed at all, and i even tried changing the compile settings such as turning off optimizations, switching between release/debug and even turned off the "suppress JIT optimizations on module load" option in tools->options->debugging->general and nothing changed. What could be different about my install of visual studio 2005 and 2008 that would produce different IL on different machines? Anyone run into this problem before? |
#7
| |||
| |||
|
|
After a bit more research, if that's the issue, it would mean you're compiling a C/C++ project. If you're not, it sounds like DEP; but it doesn't explain why rebuilding makes the problem go away. If you are compiling a C/C++ project then VS 2005 doesn't have a UI for the DYNAMICBASE linker option; but you can add /DYNAMICBASE:NO to the linker command-line options in the Linker/Advanced properties. In VS 2008, there is a "Randomized Base Address" option in the Linker/Advance properties that affects the /DYNAMICBASE command-line option for C/C++ projects. -- Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote. http://www.peterRitchie.com/blog/ Microsoft MVP, Visual Developer - Visual C# "Jason Rodman" wrote: I see. So by disabling this we can test to see if this is the issue. If this does turn out to be the problem, how could I fix the issue on my end without having to affect the end user's machine? "Peter Ritchie [C# MVP]" wrote: It could be that the vendor does not have VS 2005 SP1 installed. the /DYNAMICBASE option was added in SP1 [1]. If you were using it in your project in VS 2005 w/SP1 and compiled it there and give it to someone else, it would be randomizing load/stack/heap addresses; if you gave someone without SP1 the project, they would compile it without radomized load/stack/heap addresses and may not exhibit the problem. [1] http://blogs.msdn.com/michael_howard...-and-aslr.aspx -- Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote. http://www.peterRitchie.com/blog/ Microsoft MVP, Visual Developer - Visual C# "Jason Rodman" wrote: Thanks for your reply Peter. Im not sure this makes much sense, why would one build from one machine work, and another build from a different machine not work. Same exact vb code, same exact COM dll. If it was ASLR or DEP, wouldnt it break for both builds? I dont think the issue is on the host vista machine, but more in the vb compiler. What could be different in the build that would cause this to fail? "Peter Ritchie [C# MVP]" wrote: This may be due to ASLR and DEP (or a combination thereof) on Vista. ASLR basically means the load/heap/stack address of the application is randomly changed for each execution. This is a security feature that makes it hard to exploit an application's buffer over-/under-flow flaws. DEP is another security feature that disallows execution of code from data pages. For non exploited applications expecting to access data a constant memory address (ASLR) or expecting to be able to execute code from a data page, this would cause the error you see. I think DEP is also in XP, so it may simply be ASLR causing the problem. As far as I know a binary has to opt into ASLR, which means the vendor is compiling/linking with the /DYNAMICBASE command-line argument. You could try disabling DEP to see if that makes the problem go away. There's some good websites that explain how to do that, like : http://vistasupport.mvps.org/disable...prevention.htm -- Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote. http://www.peterRitchie.com/blog/ Microsoft MVP, Visual Developer - Visual C# "Jason Rodman" wrote: I have a strange issue when using a COM component in VS 2005 or 2008. If I compile my application and run it, it works on any xp machine, but does not work on most vista machines. I get an "Attempted to read or write protected memory" error on a certain line. I contacted the vendor of the com component about this issue, sent them a sample project to demonstrate it and they were able to reproduce it with the build i sent them. But, when they recompiled it, the issue went away. I ran their build of my sample project on several installations of vista and all editions and it works just fine. My question is, what could cause a problem like this? I did a binary comparison of both builds and there are definate differences between them (not that I know what they mean). No code was changed at all, and i even tried changing the compile settings such as turning off optimizations, switching between release/debug and even turned off the "suppress JIT optimizations on module load" option in tools->options->debugging->general and nothing changed. What could be different about my install of visual studio 2005 and 2008 that would produce different IL on different machines? Anyone run into this problem before? |
#8
| |||
| |||
|
|
This is actually a vb.net project. Is there an option for it there? "Peter Ritchie [C# MVP]" wrote: After a bit more research, if that's the issue, it would mean you're compiling a C/C++ project. If you're not, it sounds like DEP; but it doesn't explain why rebuilding makes the problem go away. If you are compiling a C/C++ project then VS 2005 doesn't have a UI for the DYNAMICBASE linker option; but you can add /DYNAMICBASE:NO to the linker command-line options in the Linker/Advanced properties. In VS 2008, there is a "Randomized Base Address" option in the Linker/Advance properties that affects the /DYNAMICBASE command-line option for C/C++ projects. -- Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote. http://www.peterRitchie.com/blog/ Microsoft MVP, Visual Developer - Visual C# "Jason Rodman" wrote: I see. So by disabling this we can test to see if this is the issue. If this does turn out to be the problem, how could I fix the issue on my end without having to affect the end user's machine? "Peter Ritchie [C# MVP]" wrote: It could be that the vendor does not have VS 2005 SP1 installed. the /DYNAMICBASE option was added in SP1 [1]. If you were using it in your project in VS 2005 w/SP1 and compiled it there and give it to someone else, it would be randomizing load/stack/heap addresses; if you gave someone without SP1 the project, they would compile it without radomized load/stack/heap addresses and may not exhibit the problem. [1] http://blogs.msdn.com/michael_howard...-and-aslr.aspx -- Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote. http://www.peterRitchie.com/blog/ Microsoft MVP, Visual Developer - Visual C# "Jason Rodman" wrote: Thanks for your reply Peter. Im not sure this makes much sense, why would one build from one machine work, and another build from a different machine not work. Same exact vb code, same exact COM dll. If it was ASLR or DEP, wouldnt it break for both builds? I dont think the issue is on the host vista machine, but more in the vb compiler. What could be different in the build that would cause this to fail? "Peter Ritchie [C# MVP]" wrote: This may be due to ASLR and DEP (or a combination thereof) on Vista. ASLR basically means the load/heap/stack address of the application is randomly changed for each execution. This is a security feature that makes it hard to exploit an application's buffer over-/under-flow flaws. DEP is another security feature that disallows execution of code from data pages. For non exploited applications expecting to access data a constant memory address (ASLR) or expecting to be able to execute code from a data page, this would cause the error you see. I think DEP is also in XP, so it may simply be ASLR causing the problem. As far as I know a binary has to opt into ASLR, which means the vendor is compiling/linking with the /DYNAMICBASE command-line argument. You could try disabling DEP to see if that makes the problem go away. There's some good websites that explain how to do that, like : http://vistasupport.mvps.org/disable...prevention.htm -- Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote. http://www.peterRitchie.com/blog/ Microsoft MVP, Visual Developer - Visual C# "Jason Rodman" wrote: I have a strange issue when using a COM component in VS 2005 or 2008. If I compile my application and run it, it works on any xp machine, but does not work on most vista machines. I get an "Attempted to read or write protected memory" error on a certain line. I contacted the vendor of the com component about this issue, sent them a sample project to demonstrate it and they were able to reproduce it with the build i sent them. But, when they recompiled it, the issue went away. I ran their build of my sample project on several installations of vista and all editions and it works just fine. My question is, what could cause a problem like this? I did a binary comparison of both builds and there are definate differences between them (not that I know what they mean). No code was changed at all, and i even tried changing the compile settings such as turning off optimizations, switching between release/debug and even turned off the "suppress JIT optimizations on module load" option in tools->options->debugging->general and nothing changed. What could be different about my install of visual studio 2005 and 2008 that would produce different IL on different machines? Anyone run into this problem before? |
#9
| |||
| |||
|
|
I can't verify it, but it appears VB.NET and C# applications have the ASLR bit set in VS 2005 SP1. Without verifying it, I can't tell if there's a way to change it or not. If you can verify that the vendor is in fact not using SP1, that would be a step in the right direction. -- Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote. http://www.peterRitchie.com/blog/ Microsoft MVP, Visual Developer - Visual C# "Jason Rodman" wrote: This is actually a vb.net project. Is there an option for it there? "Peter Ritchie [C# MVP]" wrote: After a bit more research, if that's the issue, it would mean you're compiling a C/C++ project. If you're not, it sounds like DEP; but it doesn't explain why rebuilding makes the problem go away. If you are compiling a C/C++ project then VS 2005 doesn't have a UI for the DYNAMICBASE linker option; but you can add /DYNAMICBASE:NO to the linker command-line options in the Linker/Advanced properties. In VS 2008, there is a "Randomized Base Address" option in the Linker/Advance properties that affects the /DYNAMICBASE command-line option for C/C++ projects. -- Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote. http://www.peterRitchie.com/blog/ Microsoft MVP, Visual Developer - Visual C# "Jason Rodman" wrote: I see. So by disabling this we can test to see if this is the issue. If this does turn out to be the problem, how could I fix the issue on my end without having to affect the end user's machine? "Peter Ritchie [C# MVP]" wrote: It could be that the vendor does not have VS 2005 SP1 installed. the /DYNAMICBASE option was added in SP1 [1]. If you were using it in your project in VS 2005 w/SP1 and compiled it there and give it to someone else, it would be randomizing load/stack/heap addresses; if you gave someone without SP1 the project, they would compile it without radomized load/stack/heap addresses and may not exhibit the problem. [1] http://blogs.msdn.com/michael_howard...-and-aslr.aspx -- Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote. http://www.peterRitchie.com/blog/ Microsoft MVP, Visual Developer - Visual C# "Jason Rodman" wrote: Thanks for your reply Peter. Im not sure this makes much sense, why would one build from one machine work, and another build from a different machine not work. Same exact vb code, same exact COM dll. If it was ASLR or DEP, wouldnt it break for both builds? I dont think the issue is on the host vista machine, but more in the vb compiler. What could be different in the build that would cause this to fail? "Peter Ritchie [C# MVP]" wrote: This may be due to ASLR and DEP (or a combination thereof) on Vista. ASLR basically means the load/heap/stack address of the application is randomly changed for each execution. This is a security feature that makes it hard to exploit an application's buffer over-/under-flow flaws. DEP is another security feature that disallows execution of code from data pages. For non exploited applications expecting to access data a constant memory address (ASLR) or expecting to be able to execute code from a data page, this would cause the error you see. I think DEP is also in XP, so it may simply be ASLR causing the problem. As far as I know a binary has to opt into ASLR, which means the vendor is compiling/linking with the /DYNAMICBASE command-line argument. You could try disabling DEP to see if that makes the problem go away. There's some good websites that explain how to do that, like : http://vistasupport.mvps.org/disable...prevention.htm -- Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote. http://www.peterRitchie.com/blog/ Microsoft MVP, Visual Developer - Visual C# "Jason Rodman" wrote: I have a strange issue when using a COM component in VS 2005 or 2008. If I compile my application and run it, it works on any xp machine, but does not work on most vista machines. I get an "Attempted to read or write protected memory" error on a certain line. I contacted the vendor of the com component about this issue, sent them a sample project to demonstrate it and they were able to reproduce it with the build i sent them. But, when they recompiled it, the issue went away. I ran their build of my sample project on several installations of vista and all editions and it works just fine. My question is, what could cause a problem like this? I did a binary comparison of both builds and there are definate differences between them (not that I know what they mean). No code was changed at all, and i even tried changing the compile settings such as turning off optimizations, switching between release/debug and even turned off the "suppress JIT optimizations on module load" option in tools->options->debugging->general and nothing changed. What could be different about my install of visual studio 2005 and 2008 that would produce different IL on different machines? Anyone run into this problem before? |
#10
| |||
| |||
|
|
Okay. I will get back to you as soon as they respond to my email. Thanks. "Peter Ritchie [C# MVP]" wrote: I can't verify it, but it appears VB.NET and C# applications have the ASLR bit set in VS 2005 SP1. Without verifying it, I can't tell if there's a way to change it or not. If you can verify that the vendor is in fact not using SP1, that would be a step in the right direction. -- Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote. http://www.peterRitchie.com/blog/ Microsoft MVP, Visual Developer - Visual C# "Jason Rodman" wrote: This is actually a vb.net project. Is there an option for it there? "Peter Ritchie [C# MVP]" wrote: After a bit more research, if that's the issue, it would mean you're compiling a C/C++ project. If you're not, it sounds like DEP; but it doesn't explain why rebuilding makes the problem go away. If you are compiling a C/C++ project then VS 2005 doesn't have a UI for the DYNAMICBASE linker option; but you can add /DYNAMICBASE:NO to the linker command-line options in the Linker/Advanced properties. In VS 2008, there is a "Randomized Base Address" option in the Linker/Advance properties that affects the /DYNAMICBASE command-line option for C/C++ projects. -- Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote. http://www.peterRitchie.com/blog/ Microsoft MVP, Visual Developer - Visual C# "Jason Rodman" wrote: I see. So by disabling this we can test to see if this is the issue. If this does turn out to be the problem, how could I fix the issue on my end without having to affect the end user's machine? "Peter Ritchie [C# MVP]" wrote: It could be that the vendor does not have VS 2005 SP1 installed. the /DYNAMICBASE option was added in SP1 [1]. If you were using it in your project in VS 2005 w/SP1 and compiled it there and give it to someone else, it would be randomizing load/stack/heap addresses; if you gave someone without SP1 the project, they would compile it without radomized load/stack/heap addresses and may not exhibit the problem. [1] http://blogs.msdn.com/michael_howard...-and-aslr.aspx -- Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote. http://www.peterRitchie.com/blog/ Microsoft MVP, Visual Developer - Visual C# "Jason Rodman" wrote: Thanks for your reply Peter. Im not sure this makes much sense, why would one build from one machine work, and another build from a different machine not work. Same exact vb code, same exact COM dll. If it was ASLR or DEP, wouldnt it break for both builds? I dont think the issue is on the host vista machine, but more in the vb compiler. What could be different in the build that would cause this to fail? "Peter Ritchie [C# MVP]" wrote: This may be due to ASLR and DEP (or a combination thereof) on Vista. ASLR basically means the load/heap/stack address of the application is randomly changed for each execution. This is a security feature that makes it hard to exploit an application's buffer over-/under-flow flaws. DEP is another security feature that disallows execution of code from data pages. For non exploited applications expecting to access data a constant memory address (ASLR) or expecting to be able to execute code from a data page, this would cause the error you see. I think DEP is also in XP, so it may simply be ASLR causing the problem. As far as I know a binary has to opt into ASLR, which means the vendor is compiling/linking with the /DYNAMICBASE command-line argument. You could try disabling DEP to see if that makes the problem go away. There's some good websites that explain how to do that, like : http://vistasupport.mvps.org/disable...prevention.htm -- Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote. http://www.peterRitchie.com/blog/ Microsoft MVP, Visual Developer - Visual C# "Jason Rodman" wrote: I have a strange issue when using a COM component in VS 2005 or 2008. If I compile my application and run it, it works on any xp machine, but does not work on most vista machines. I get an "Attempted to read or write protected memory" error on a certain line. I contacted the vendor of the com component about this issue, sent them a sample project to demonstrate it and they were able to reproduce it with the build i sent them. But, when they recompiled it, the issue went away. I ran their build of my sample project on several installations of vista and all editions and it works just fine. My question is, what could cause a problem like this? I did a binary comparison of both builds and there are definate differences between them (not that I know what they mean). No code was changed at all, and i even tried changing the compile settings such as turning off optimizations, switching between release/debug and even turned off the "suppress JIT optimizations on module load" option in tools->options->debugging->general and nothing changed. What could be different about my install of visual studio 2005 and 2008 that would produce different IL on different machines? Anyone run into this problem before? |
|
« Previous Thread
|
Next Thread »
| Thread Tools | Search this Thread |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.4
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.