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.

Installing SQL Server Compact Edition 3.5 SP2 with ADO.NET Entity Framework locally

2 09 2010

When using SQL Server CE as a local database engine the SQL Server CE components need to be installed locally. This could easily be done using the SQL Server CE setup package provided by Microsoft. But this requires the end user to manually install the SQL Server CE .msi as a prerequisite component.

As an alternative one could create a setup bootstrapper to include and automatically run the SQL Server CE installer during setup of the custom application. But this requires additional development effort.

What I wanted was to completely include the SQL Server CE runtime components with the setup installer of my application. All components should be installed locally. I managed to solve this with the help of several blog posts, namely:

I applied a combination of the techniques described in the previous blog posts. Essentially I did the following:

  • Installed the following files from the %ProgramFiles%\Microsoft SQL Server Compact Edition\v3.5 directory to the application’s target directory. These are the files from SQL Server CE 3.5 SP2 which came with Visual Studio 2010, though the application was created using Visual Studio 2008 SP1 (targeting .NET Framework 3.5 SP1). The version number of the files is displayed as 3.5.8080.0.
  1. sqlceca35.dll
  2. sqlcecompact35.dll
  3. sqlceer35EN.dll
  4. sqlceme35.dll
  5. sqlceoledb35.dll
  6. sqlceqp35.dll
  7. sqlcese35.dll
  • Installed the following files from the %ProgramFiles%\Microsoft SQL Server Compact Edition\v3.5\Private directory to the application’s target directory. It is important to use the files from the Private directory and not from the base and Desktop directories, otherwise other problems will arise.
  1. System.Data.SqlServerCe.dll
  2. System.Data.SqlServerCe.Entity.dll
  • Added the following section to the application’s app.config file. This was taken from the before mentioned blog post.
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <assemblyIdentity name="System.Data.SqlServerCe"                            publicKeyToken="89845dcd8080cc91" 
      <bindingRedirect oldVersion="" 
  • Added the following section to the application’s app.config file. This was copied from the machine.config file of a development machine where the SQL Server CE runtime was installed. The remove tag is required to make the configuration work on machines, where this entry is already contained in the machine.config file.
    <remove invariant="System.Data.SqlServerCe.3.5" />
    <add name="Microsoft SQL Server Compact Data Provider"
         description=".NET Framework Data Provider for Microsoft SQL Server Compact"
         type="System.Data.SqlServerCe.SqlCeProviderFactory, System.Data.SqlServerCe, Version=, Culture=neutral, PublicKeyToken=89845dcd8080cc91" />
  • Done.

To figure this out it was helpful to add the following entry to the registry to enable assembly binding logging. This entry causes detailed error information to be included with the exceptions thrown when assembly binding errors occur.

  • HKLM\SOFTARE\Microsoft\Fusion\EnableLog=1 (DWORD)

This solution has been tested only on Windows XP SP3 so far. Additional steps might be required to make it work on 64-bit platforms.

Visual Studio Macro for Tab Settings

10 06 2010

I’m still dreaming of integrated support for project specific tab settings in the Visual Studio editor. This would allow me to work on my own projects with my preferred tab settings (TabSize=2, Insert Spaces) and also to work on open source projects which mostly use the default settings (TabSize=4, Insert Tabs).

As a workaround I use the following macros to quickly switch the tab settings from within Visual Studio.

Imports System
Imports EnvDTE
Imports EnvDTE80
Imports EnvDTE90
Imports EnvDTE90a
Imports EnvDTE100
Imports System.Diagnostics

Public Module TabSettings

    Dim category = "TextEditor"
    Dim language = "AllLanguages"

    Sub TabSize2_InsertSpaces()

        Dim props = DTE.Properties(category, language)
        props.Item("IndentSize").Value = 2
        props.Item("TabSize").Value = 2
        props.Item("InsertTabs").Value = False

    End Sub

    Sub TabSize4_InsertTabs()

        Dim props = DTE.Properties(category, language)
        props.Item("IndentSize").Value = 4
        props.Item("TabSize").Value = 4
        props.Item("InsertTabs").Value = True

    End Sub

End Module

Access Network Share on Windows XP or Windows Server 2003 from Windows 7

29 04 2010

Heute hatte ich das Problem, dass der Zugriff auf einen unter Windows Server 2003 R2 freigegebenen Netzwerkordner von Windows 7 aus nicht funktioniert hat (access denied). Die umgekehrte Richtung, also der Zugriff auf einen unter Windows 7 freigegebenen Ordner von Windows Server 2003 R2 aus, hat jedoch geklappt.

Das Problem lässt sich lösen, indem man unter Windows 7 den Local Group Policy Editor (gpedit.msc) startet und unter Windows Settings – Security Settings – Local Policies – Security Options die Einstellung Network security: LAN Manager authentication level auf Send LM & NTLM responses setzt.


Die Lösung habe ich hier gefunden: http://social.technet.microsoft.com/Forums/en-US/w7itpronetworking/thread/ed05788a-af43-4df6-b124-fdb57391752e

EASEUS Partition Master 5.5.1 Home Edition

22 04 2010

Habe heute ein nettes, kostenloses(!) Tool gefunden, mit dem man u. a. auch Partitionen verkleinern kann: EASEUS Partition Master 5.5.1 Home Edition.

Download: http://www.partition-tool.com/personal.htm

Die neue Partitionsgröße lässt sich bequem und übersichtlich über eine GUI einstellen. Anschließend muss neu gebootet werden. Dabei wird die eigentliche Operation erst ausgeführt.

ASP.NET Compilerfehlermeldung CS0016

27 02 2010

Heute hatte ich folgende Fehlermeldung beim Zugriff auf eine alte ASP.NET 1.1 Anwendung aus dem Jahre 2004 auf einem Windows Server 2003 SP2.

Compilerfehlermeldung: CS0016: In die Ausgabedatei ‚c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files\adward_common_clientstatistics\xxxxxxxx\xxxxxxxx\xxxxxxxx.dll‘ konnte nicht geschrieben werden — ‚Der Verzeichnisname ist ungültig. ‚

[Keine relevanten Quellzeilen]

Quelldatei:    Zeile: 0

Der selbe Fehler ist bereits in einem Blogeintrag vom 18.08.2006 von Thomas Kötzing beschrieben. Der dort als Lösung angegebene Microsoft KB-Eintrag http://support.microsoft.com/default.aspx?scid=kb;en-us;825791 konnte das Problem auch in meinem Fall beheben.

Es fehlten die Zugriffsrechte für den “Netzwerkdienst” für den Ordner C:\Temp. Auf diesen Ordner zeigen die System-Umgebungsvariablen TEMP und TMP.

Warum das Problem plötzlich aufgetreten ist, nachdem die Anwendung seit über 6 Jahren problemlos lief, wird wohl ein Rätsel bleiben…