Windows 8 Beta („Consumer Preview“) Experiences

2 03 2012

I’d like to summarize my so far very positive experiences with the Windows 8 Beta („Consumer Preview“) here.

I downloaded and installed the 64-bit en-US version on my XPS15z laptop into a virtual disk (.vhd file). The download was very fast (on an average download rate of 6.2 MB/s!), so it took less than 10 minutes to get it from the Microsoft servers.

Installation was seemless despite the extra hops that need to be taken to get it installed into a .vhd file. I followed the Guide to Installing and Booting Windows 8 Developer Preview off a VHD (Virtual Hard Disk) by Scott Hanselman for the Windows 8 Developer Preview and it still works exactly as described with the Beta. The only thing you need to be aware off is that the drive letter where you created the .vhd file upfront might change from C: to D: (in my case).

Windows 8 benefits over Windows 7

1. Hardware Support

Windows 8 seamlessly recognized the most important of the XPS15z’s quite modern hardware components, namely the Intel WLAN adapter, the Atheros Ethernet adapter, and the USB 3.0 host controller. On Windows 7 it was a PITA to get the drivers installed if you have neither access to USB, nor to a network and you don’t have a driver DVD handy.

Also, my network enabled EPSON BX635FWD printer was automatically detected, and the EPSON driver software was automatically installed.

Very nice experience!

2. Out-of-the-box support for mounting .ISO images

No more need to download and install Virtual Clone Drive or alike.

3. Mouse Without Borders

Installation Mouse Without Borders (one of my favorite tools) was a bit bumpy because this software is dependent on the .NET framework 2.0. Windows 8 comes with .NET framework 4.5 preinstalled, but this does not include the older .NET framework 3.5.1 (which includes 2.0). Installation through the „Programs and Features“ applet failed, maybe because Internet was only available through the company proxy.

But I could get .NET framework 3.5.1 by mounting the downloaded Windows 8 installation .ISO image (which was a snap thanks to the integrated .ISO support) and executing the following command:

Dism.exe /online /enable-feature /featurename:NetFX3 /All /Source:F:\sources\sxs /LimitAccess

WPF Application Shutdown on Windows 7 x64

3 02 2012

In WPF applications, the Application.Exit event is not (reliably) called – at least on Windows 7 x64 – when the user logs off from or shuts down or restarts the Windows machine. I found that my Application_Exit handler which performs important cleanup was not called.

I tried to remedy this first by hooking into the SystemEvents.SessionEnding event and calling Application.Shutdown from there. After doing this, I found that my Application_Exit handler was called, but then the process seemed to be killed in the middle of the shutdown processing (log output stopped suddenly).

Then I removed the SystemEvents.SessionEnding event handler again and tried to override the Application.OnSessionEnding virtual method. This resulted in the same behavior. The Application_Exit handler was sometimes called, sometimes not, but when it was called, the process died during shutdown processing.

I finally solved this by overwriting the Application.OnSessionEnding method, calling the base class implementation first, then setting SessionEndingCancelEventArgs.Cancel=true to avoid my process being killed by the OS, and finally explicitly calling Application.Shutdown to initiate the shutdown process. The end result is a clean application shutdown while Windows shows the „Application not responding“ screen for several seconds while my application shuts down.

Here’s the code:

public partial class App : Application
  protected override void OnSessionEnding(SessionEndingCancelEventArgs e)

    // Cancel application shutdown to prevent Windows 7 killing
    // the process
    e.Cancel = true;

    // Terminate myself

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.

VMware 64-bit Guest OS on 32-bit Host OS

8 01 2010

Es ist möglich, ein 64-bit Gast-Betriebssystem (z. B. Windows Server 2008 R2) auf einem 32-bit Host-Betriebssystem (z. B. Windows 7 Ultimate x86) zu installieren. Heute ist mir das auf meinem DELL XPS M1530 Notebook mit dem VMware Player 3.0.0 build-203739 gelungen.

Voraussetzungen dafür sind:

  • Der Prozessor muss 64-bit fähig sein (hier: Intel Core2 Duo 2,40 GHz T7700).
  • Prozessor und BIOS müssen VT (“Virtualization Technology”) Unterstützung bieten. Ggf. ist das im BIOS zunächst zu aktivieren.

Der 2. Punkt ist auf dem DELL XPS M1530 problematisch, weil die VT-Unterstützung im aktuellen BIOS (A12) deaktiviert und auch nicht über das BIOS Setup aktivierbar ist (Option fehlt!). Erst durch einen Downgrade auf BIOS A08 wurde die Option wieder sichtbar und ließ sich aktivieren.