A .NET application in the company I work for recently started crashing under Windows Vista when trying to open a window implemented in an ActiveX DLL. Investigations showed that they were caused by an AccessViolationException "Attempted to read or write protected memory. This is often an indication that other memory is corrupt.". The cause was one of the ActiveX controls in the window. When instantited directly in a .NET Form the exception above was contained in a TargetInvocationException "Unable to get the window handle for the '<control name>' control. Windowless ActiveX controls are not supported.". Knowing that the control didn't suddenly turn windowless we dug deeper.

It turned out that the problem appeared with .NET Framework 2.0 Service Pack 1. Apparently it caused the C# compiler in Visual Studio 2005 and later to set the NXCOMPAT bit for all build targets without an option to turn this new behavior off. For those who don't know, this means that DEP (data execution prevention) will kick in unless it is turned off completely in the operating system. This wouldn't be a big deal unless ATL before Visual Studio 2005 didn't have a bug which caused the heap allocated memory not to be flagged as executable, which under the new circumstances results as the already mentioned exception. Windows XP has DEP turned off by default therefore everything still works but in Windows Vista it is turned on and prevents such application from functioning properly.

The best solution would of course be to recompile the ActiveX controls in Visual Studio 2005 or later but this might not be possible if they are supplied by a third party. In this case the most obvious approach to dealing with the situation is to disable DEP in Vista. There is a Data Execution Prevention tab in the Performance Options which open when you click the Settings button in the Performance frame of the Advanced tab in the System Properties dialog but it only allows switching between DEP for all processes with defined exceptions and DEP for essential Windows programs and services, i.e. executables flagged with the NXCOMPAT bit. The only way to turn DEP completely off is executing the following command with administrative privileges:

bcdedit.exe /set {current} nx AlwaysOff

After restart DEP will be turned off and problematic binaries will work once again. To restore the previous (default) state replace AlwaysOff with OptIn. The AlwaysOn option enables DEP for all processes and might cause additional problems (e.g. Google Calendar Sync in its current version 0.9.3.2 doesn't work in this mode).

Unfortunately, this solution would require all your Vista using customers to disable DEP as well which really isn't an option for commercial software. Fortunately, there is another solution. Although there is no compiler option to turn keep the NXCOMPAT bit unset, you can still do this after compilation using the editbin.exe which comes with C++ compiler for Visual Studio 2005 and later:

editbin.exe /NXCOMPAT:NO <filename.exe>

This command removes the NXCOMPAT bit and restores the behavior before .NET 2.0 SP1. If your assembly was signed it also invalidates the signature so you'll have to resign it:

sn.exe -R <filename.exe> <keyfile.snk>

You can automate this by putting the two commands in the Post-build event command line for the project:

editbin.exe /NXCOMPAT:NO "$(TargetPath)"
sn.exe -R "$(TargetPath)" "$(ProjectDir)<keyfile.snk>"

You might need to call vcvars32.bat before that to put the required executables in path and enable editbin.exe dependencies to be resolved. Note that in a completely automated build scenario using MSBuild you'll have to specify full path for the vcvars32.bat because $(DevEnvDir) resolves to *Undefined* outside Visual Studio 2005. Also your strong name key should be in a snk file instead of a password protected pfx file because sn.exe doesn't allow the password to be read from a redirected standard input.

The MonthCalendar control's BoldedDates functionality doesn't appear to work properly on Windows Vista. The dates added to any of the BoldedDates, MonthlyBoldedDates and AnnuallyBoldedDates collections are rendered just the same as those not added to any of the collections. The same code works just fine on Windows XP and causes those dates to be rendered bold. The only workaround i've managed to find is disabling visual styles in the application, i.e. commenting out the first line in the Program.Main() method of a new Windows Application:

Application.EnableVisualStyles();

The Xbox 360 Dashboard update released on 4th December 2007 added support for playing DivX and XviD videos natively, i.e. without installing Transcode 360 for Windows Media Center. Unfortunatelly this only works for media played directly from the dashboard and not within Media Center Extender. Since I didn't want to copy my videos to CDs, DVDs or other external devices, the only thing left to do was to setup Windows Media Player media sharing which I never had to use before.

This turned out to be more difficult than I expected - the reason being that the media I wanted to share wasn't stored locally but on a separate file server. By default such media is not shared and there are few steps one has to follow to make this work, as thoroughly explained here:

• Enable remote content sharing by adding the following entry into the registry:
  [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MediaPlayer\Preferences\HME]
  "EnableRemoteContentSharing"=dword:00000001
• Grant anonymous users access to the shared folders on the file server by adding the read permission on the folder and on the share to the ANONYMOUS LOGON user
• Modify the file server's group policy to allow anonymous access to the selected shares by listing them in the Network access: Shares that can be accessed anonymously policy in the Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options branch of the group policy tree (just run gpedit.msc to start the Group Policy Object Editor)

In my opinion RSACryptoServiceProvider class is seriously under-documented in MSDN. Since there is also no abundance of examples on the web, I spent more time than I should figuring out how to use it correctly. For future reference I'm listing below the solution to two problems I had.

The maximum byte array length for encrypting without OAEP padding is Modulus size - 11 which is written somewhere in the Encrypt() method documentation. If you pass it a larger array it will return a not so informative Unspecified error. To encrypt a larger chunk of data you have to split it in smaller parts, encrypt them individually and concatenate them back together. You have to do the same when decrypting the data, with the only difference that each part has the size of Modulus in stead of Modulus - 11. To get the modulus size you can use the following piece of code (rsa is an instance of RSACryptoServiceProvider):

RSAParameters rsaParams = rsa.ExportParameters(false);
int modulusSize = rsaParams.Modulus.Length;

Each time you instantiate RSACryptoServiceProvider it generates a new pair of keys. If you want to use existing ones, you can import them by calling:

rsa.FromXmlString(key);

The key parameter is a string with the XML representation of the keys. You can get it by calling the ToXmlString() method once and storing its results. It's only parameter specifies whether to also export the private key. I guess I don't have to remind you that you need the private key only for decryption and that you should always keep it private for the encryption to make any sense at all.

Is the code below correct? Will inputString and outputString be equal?

string inputString = "The text to compress and decompress";
byte[] inputArray = Encoding.UTF8.GetBytes(inputString);

MemoryStream stream = new MemoryStream();
DeflateStream compressionStream =
    new DeflateStream(stream, CompressionMode.Compress);
compressionStream.Write(inputArray, 0, inputArray.Length);
compressionStream.Flush();

stream.Position = 0;

DeflateStream decompressionStream =
    new DeflateStream(stream, CompressionMode.Decompress);
byte[] outputArray = new byte[inputArray.Length];
decompressionStream.Read(outputArray, 0, outputArray.Length);
string outputString = Encoding.UTF8.GetString(outputArray);

Console.WriteLine(outputString == inputString);
Console.ReadLine();

As it turns out, they won't. The reason for it being that compressionStream.Close() was not called before reading from stream started. Calling compressionStream.Flush() is not enough in this case. I haven't managed to find this documented anywhere but the example in the DeflateStream documentation does it correctly. You can find the fixed code below. Notice the additional last parameter in the first call to the DeflateStream constructor. Without it stream will also be closed when compressionStream gets closed.

string inputString = "The text to compress and decompress";
byte[] inputArray = Encoding.UTF8.GetBytes(inputString);

MemoryStream stream = new MemoryStream();
DeflateStream compressionStream =
    new DeflateStream(stream, CompressionMode.Compress, true);
compressionStream.Write(inputArray, 0, inputArray.Length);
compressionStream.Close();

stream.Position = 0;

DeflateStream decompressionStream =
    new DeflateStream(stream, CompressionMode.Decompress);
byte[] outputArray = new byte[inputArray.Length];
decompressionStream.Read(outputArray, 0, outputArray.Length);
string outputString = Encoding.UTF8.GetString(outputArray);

Console.WriteLine(outputString == inputString);
Console.ReadLine();

Thanks once again to my coworker for suggesting this when I was already running out of ideas.