Wow, what a title. Deserving for the debacle it involves. If you are using an older ActiveX/COM component that doesn’t support DEP (Data Execution Prevention) – you might run into this.
Your app will compile file, and when users try to run it, it runs fine, yet when you use the control you get an error about shared and corrupt memory. The ActiveX control might not support DEP and you don’t have any way to go around it. You can have the users turn off DEP but that isn’t a viable solution.
What you can do is set a post-build step to turn off DEP for your exe which works great.
here is the post build step from the link:
call $(DevEnvDir)..toolsvsvars32.bat
editbin.exe /NXCOMPAT:NO $(TargetPath)
But then you go to check it into TFS and your build fails. Why? Because there is no environment variable for $(DevEnvDir) when team build (msbuild) builds your solution.
In order to fix that, you need to add an environment variable on the build controller to
64bit: C:Program Files (x86)Microsoft Visual Studio 10.0Common7IDE
32bit: C:Program FilesMicrosoft Visual Studio 10.0Common7IDE
and then reboot your build controller, and it should build.
Steve Novoselac's Blog 