Windows Update Killed Our Build
Our product build machine is running Windows XP. On September 1st we ran Windows update which installed 28 updates (we were a bit behind) on that machine. From that point forward builds on that machine no longer run on Windows Vista machines.
KB970653, KB970653, KB970653, KB890830, KB890830, KB973540, KB973354, KB973507, KB973507, KB973869, KB971633, KB971633, KB951847, KB973346, KB956744, KB971557, KB971557, KB961371, KB970483, KB960859
This error is encountered when loading any of our 3rd party Active X controls and is triggered by Digital Execution Protection (DEP). If I turn off DEP on my machine completely the build works just fine (don’t do this though, it makes a mess).
c:\> bcdedit.exe /set nx AlwaysOff
Also curious is that, in the build immediately prior to the update, I can go into “System Properties / Advanced / Performance / Data Execution Prevention” and add an exclusion for our program binary. For the build immediately after the updates I get the following:
From this forum post it looks like you would not be able to turn off DEP if the EXE is one of the following:
There are three possible causes for why you cannot add the app to the
exceptions list:
1.) This is a 64-bit application.
2.) The application is in the Windows directory.
3.) The application has been compiled for Vista and, therefore, DEP is
enforced for it.
Our application is compiled for Any-CPU and is not in the Windows directory and I have no idea what a “Vista” build is.
After way too much searching I came across this article that states:
The C# compiler in Visual Studio 2008 and the .NET 3.5 Framework (csc.exe) is now generating PE files with the NXCOMPAT bit set. What is that bit and who cares, you ask? You may very well care if your application interops with native binaries or exposes a plugin model to 3rd parties.
…
The .NET 2.0 and VS 2005 compilers are also affected
The fix seems to be to turn off the NXCOMPAT bit for our application until we can get rid of our ActiveX dependencies.
Naturally VC++ includes a setting for turning of this NXCOMPAT feature but C# and VB.NET do not:
We can execute the following command on our EXE after the build process and it seems to fix things up for us.
c:\> editbin.exe /NXCOMPAT:NO <insert EXE here>
Unfortunately our EXE is strong named because we use ClickOnce. So doing this after the build invalidates our signed executable.
So now we need to turn resign the EXE after doing this.
c:\> sn –Ra
<exe> <keyfile>
Trying to add editbin.exe to a post build action raised some error code that isn’t documented anywhere that I could find. Grumble…
I settled on adding the following to our MSBuild script and that seems to have worked… for now.
<!– NX Hack –>
<Exec Command="editbin /NXCOMPAT:NO &quot;$(BinDir)\Program.exe&quot;" />
<Exec Command="sn -Ra &quot;$(BinDir)\Program.exe&quot; &quot;$(MSBuildProjectDirectory)\Port\keypair.snk&quot;" />
That was a lot of work rummaging around to find this. Why Microsoft would sneak this change into a hotfix and is beyond me. Surely Visual Studio can tell if the assembly is using ActiveX controls and could, at least, warn me that it is going to break my build. Go Microsoft!
