| Groups | Blog | Home |
dotnet interop : "Attempted to read or write protected memory" on some vista machin
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
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_data_execution_prevention.htm -- Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote. http://www.peterRitchie.com/blog/ Microsoft MVP, Visual Developer - Visual C# [quoted text, click to view] "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
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? [quoted text, click to view] "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_data_execution_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
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/archive/2006/09/26/visual-studio-2005-sp1-beta-windows-vista-and-aslr.aspx -- Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote. http://www.peterRitchie.com/blog/ Microsoft MVP, Visual Developer - Visual C# [quoted text, click to view] "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_data_execution_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
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? [quoted text, click to view] "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/archive/2006/09/26/visual-studio-2005-sp1-beta-windows-vista-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_data_execution_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
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# [quoted text, click to view] "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/archive/2006/09/26/visual-studio-2005-sp1-beta-windows-vista-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_data_execution_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
This is actually a vb.net project. Is there an option for it there?
[quoted text, click to view] "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/archive/2006/09/26/visual-studio-2005-sp1-beta-windows-vista-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_data_execution_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
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# [quoted text, click to view] "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/archive/2006/09/26/visual-studio-2005-sp1-beta-windows-vista-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_data_execution_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
Okay. I will get back to you as soon as they respond to my email. Thanks.
[quoted text, click to view] "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/archive/2006/09/26/visual-studio-2005-sp1-beta-windows-vista-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_data_execution_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
I had one of end users follow the instructions to disable DEP and the error
goes away, so we are on the right track. I will hunt around to see if there is an option in the compiler options to turn off this option when i compile it. I will let you know what I find out. [quoted text, click to view] "Jason Rodman" wrote:
> 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/archive/2006/09/26/visual-studio-2005-sp1-beta-windows-vista-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_data_execution_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
Your problem is IMO due to a COM component which uses ATL version 7.1 or
earlier. These versions of ATL have a known bug that triggers an NX fault when run on a system with DEP enabled for user processes. Rebuilding the COM component with VS2005 or higher updates the ATL to a version with correct NX behavior. Willy. [quoted text, click to view] "Jason Rodman" <JasonRodman@discussions.microsoft.com> wrote in message
news:2D8BB02D-C859-4F02-ADE8-3704496C7375@microsoft.com... >I had one of end users follow the instructions to disable DEP and the error > goes away, so we are on the right track. I will hunt around to see if > there > is an option in the compiler options to turn off this option when i > compile > it. I will let you know what I find out. > > "Jason Rodman" wrote: > >> 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/archive/2006/09/26/visual-studio-2005-sp1-beta-windows-vista-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_data_execution_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 verified that the vendor does indeed have SP1 installed as well. Any other
suggestions? [quoted text, click to view] "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/archive/2006/09/26/visual-studio-2005-sp1-beta-windows-vista-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_data_execution_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
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |