Disable Windows XP Screen Saver through Policies

4 02 2011

Today I had to fix a problem on a Windows XP Embedded system where it was not possible to disable the Windows screensaver. The Windows XP Embedded device has a custom (touchscreen) GUI for modifying the screensaver timeout and enabling/disabling the screensaver. Enabling/disabling the screensaver was implemented through the following Win32 API call:


This worked on an Windows XP Professional development system, but it failed to disable the screensaver on the Windows XP Embedded target device. The API call succeeded, but the screensaver was still activated by the system.

During analysis of this problem I opened the screensaver configuration page (desk.cpl, Screen Saver tab) and found that the screensaver selection dropdown combobox was disabled. My first idea was that this dropdown was disabled because there was only a single screensaver (.scr file) installed. I checked the C:\Windows\system32 directory for *.scr files and found that there were two screensavers available. So why was the dropdown combobox disabled?

Googling for “screen saver selection disabled” revealed this very helpful blog post: Screen Saver Selection is Grayed Out or Disabled

From this blog post I learned that you can control (overwrite!) the availability of screensaver options through system policies stored in the following registry key:

HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Control Panel\Desktop

If you add a ScreenSaveActive=1 value here, this forces the screensaver to be always active, no matter what API the user calls. (You can also e. g. enforce one specific screensaver by adding a SCRNSAVE.EXE=<path> value.)

Note: When the ScreenSaveActive=1 policy is set, the ScreenSaveActive entry at

HKEY_CURRENT_USER\Control Panel\Desktop

is always 0 and ignored.

msbuild for 64-bit “Any CPU” platform

3 02 2011

Today I solved a problem with one of the executables of a .NET application not starting on Win7 x64. The application ran fine on both WinXP (32-bit) and Win7 (64-bit) when built from within VS2010, no matter if it was built on a WinXP (32-bit) or Win7 (64-bit) machine. But it failed when built on our hudson build server which is running on the WinXP (32-bit) machine.

As it turned out, two of the application’s assemblies where compiled for the x86 platform when the application was built through hudson. The following msbuild command line argument was used to build the solution:


Digging inside the solution’s .vcproj files revealed that the project files for the two assemblies in question erroneously contained Release|x86 and Debug|x86 configurations in addition to the Release|AnyCPU and Debug|AnyCPU configurations.

Obviously msbuild decided to build one of the x86 configurations of these assemblies as no explicit platform target was specified on the command line. This was surprising as the project file for these assemblies defaulted to the AnyCPU platform. This looks like a bug in msbuild to me.

The problem could be solved by explicitly specifying the target platform through an additional msbuild command line argument:

/p:Configuration=Release /p:Platform="Any CPU"

Note that the value of the Platform property has to be “Any CPU” (with a blank inside) even through it’s called “AnyCPU” (with no blank) inside the .vcproj file!

Additionally I eliminated the Release|x86 and Debug|x86 configurations from the conflicting assemblies to avoid running into the same pitfall again.