B# .NET Blog : Windows Vista

Calling the Task Scheduler in Windows Vista (and Windows Server 2008) from managed code

bart — Sat, 23 Feb 2008 10:20:55 GMT

Introduction

Today I received the following mail from one of my blog readers:

Hi Bart,

The task scheduler in Vista and Windows Server 2008 has improved dramatically.

Unfortunately, there are no classes in the .NET Framework that allow us VB.NET/C# developers to leverage its power.

Many .NET applications require some form of scheduling or alerting, and instead of trying to roll our own with timers and stuff, over and over again, it seems to me that it would be much nicer to use the stable and powerful foundation that the OS offers for this.

Therefore, I thought it would be a great idea for a future article on your blog, about how to access and use the Task Scheduler 2.0 from .NET, with possibly an easy-to-use .NET wrapper class?

It seems that a lot of developers don't realize or think about what's sitting there right under the hood, 'cause I haven't seen any blog posts about this new Task Scheduler and its many features from a .NET developer's perspective yet. So here's my thought... :)

Best regards,

************

Obviously I completely agree with the statement on leveraging the power of the OS foundations whenever possible rather than reinventing the wheel once over again. Task Scheduler 2.0 is a great sample of such rich functionality offered by the OS and especially now we're shipping Windows Server 2008 this becomes even more important for server applications. Nevertheless, for desktop uses the Task Scheduler provides a tremendous amount of functionality as well and Windows Vista is using its own dogfood as you can see when you execute schtasks from the command-line (indicated a few well-known tasks in red):

In this post I'll cover how to use this API in a fairly easy way from managed code though COM interop, and I'll explain some of the richness the platform can give you.

Importing the library

I assume you've already created a Console Application in C# (though all of this would work in e.g. VB.NET as well). The Task Scheduler 2.0 API lives in a file called Taskschd.dll under the System32 folder on your system. In order to reference it from your .NET project, simply go to Solution Explorer, right-click the project node and choose Add Reference:

This will create the COM interop assembly as shown in Solution Explorer:

A simple demo task

Time to write our first task, or better to register it. Essentially tasks in Task Scheduler 2.0 are represented as XML fragments as you can see from schtasks:

I'd encourage readers to take a closer look at schtasks and the information one can obtain through it about the wide variety of tasks registered on the system. The API we'll be talking to allows us to manage these tasks (create new ones for example) though code, which provides an object model to create the metadata that represents a task as displayed above under the format of XML.

Step 1 - Establish a connection with the service

In order to talk to the Task Scheduler service we need to create a proxy object to it and connect to the service, either on the local machine or remote machine. We'll stick with the local machine for the scope of this post. Start by writing the following piece of code:

This will require to import the namespace TaskScheduler as revealed by the 'SmartTag' in Visual Studio. Notice I'm using the C# 3.0 local variable type inference keyword "var" here, but one could well write:

TaskSchedulerClass scheduler = new TaskSchedulerClass();

but not (using the TaskScheduler interface provided by the interop assembly)

TaskScheduler scheduler = new TaskSchedulerClass();

(little quiz - why?). Anyhow, we still need to connect to it using the Connect method:

We can simply supply four null arguments indicating we want to use the token of the user logged on currently (tip: run using administrative privileges to manage the service effectively). Needless to say, you can use other values for those parameters to connect to a particular machine (first parameter) and to specify a particular user (parameters 2-4 specify user name, password and domain) but we won't go there in this post.

Step 2 - Create a new task

The scheduler class provides a factory approach to create new tasks using the NewTask method. It takes one parameter that's reserved for future use (a typical COM API phenomenon) and should be set to 0 for the time being. Once the task has been created, we'll set some properties on it; the most typical ones living under RegistrationInfo and Settings (others will be covered further on):

Notice the amount of settings available to tweak the task, e.g. to control behavior with respect to the current power state of the machine, idle time, etc. For our purposes, the RegistrationInfo settings are enough as shown above.

Step 3 - Triggers

When to run the task? Enter triggers. There are a bunch of different trigger types available as revealed when calling Triggers.Create:

Most of these are self-explanatory (in case of doubt more information can be found on MSDN). The more interesting part is how to create a trigger in managed code. The crux lies in the fact you need to cast the result of the Create call to the right interface, such as ITimeTrigger for the TASK_TRIGGER_TIME type. Let's show a sample:

Other similar interfaces for other types of triggers can be found in the TaskScheduler namespace. Time triggers are pretty simple to understand so let's stick with those. In the sample above, we add an identifier to the trigger (tasks can have more than one trigger by the way) as well as some specific settings for this particular trigger. Besides of this we set the start and end time for the trigger; the settings in the sample specify a point in the past and the future so our current time falls nicely in between, triggering the demo task right away once we run it. If you want more powerful triggering, you can take a look at the Repetition property or use tasks such as 'daily' or 'monthly day-of-week (DOW)' or ...

Notice the strange (ISO 8601) date/time format specified on MSDN as: YYYY-MM-DDTHH:MM:SS(+-)HH:MM. In here, the first part is self-explanatory; the part after the +- is used to specify a time zone since tasks are stored based on UTC time. Tip: a string formatter will prove useful to generate this format.

Step 4 - Actions

After when comes what. Again there's some choice amongst the different types of actions to be taken:

The EXEC task is one of the most common ones though. The common pattern is the same again: Create, cast, configure. Here's an example of a mail-task but this will require some server configuration in order to work:

Here's another one in the category EXEC:

Feel free to choose either of those, I'll go for yet another one that displays a message (by now the pattern should be captured I guess):

Step 5 - Task registration

We've created all the data needed to hook up the task. Last step is to hook it really up by calling RegisterTaskDefinition in some folder. Tasks are logically grouped in folders which you can managed through the ITaskFolder interface. One can obtain a specific folder using the GetFolder call on the scheduler service object. For demo purposes (and because of lack of inspiration tonight :-)) we'll drop the task in the root folder:

Again there's a bunch of flexibility available here but simplicity rules for blogging, so the stuff above is pretty much the easiest one can get. Basically we create (or update if it already exists) a named task "Demo" with the credentials of the logged-on used that can only be run when an interactive user is logged on to the machine and with no custom ACL to protect the task (which could be set using an SDDL descriptor).

Step 6 - Running it

To run the task we could add a line of code (though you could use schtasks /Run too or obivously rely on your (complex) triggers you've put in place). Since the API is not only about creating tasks, this shows nicely how to control tasks. Here's the whole program with the run line at the bottom:

Run it and you should see the following dialog coming out of the blue:

Victory at last :-).

Step 7 - Geeks only

Geeks can check where the message comes from e.g. using task manager (or a more advanced tool like Process Explorer):

Also, you can take a look at the task metadata using schtasks.exe:

And finally, if you want to delete the experiment, use schtasks.exe with the /Delete flag:

schtasks /delete /tn Demo

(or use the API to do so obviously :-)).

Happy multi-tasking!

Getting started with Windows PE 2.0 for Windows Vista: boot Windows from a USB flash drive

bart — Sun, 07 Oct 2007 17:42:54 GMT

This is going to be a somewhat unfamiliar post on my blog. The history for it goes back to 2003-2004 when I was involved in a local Microsoft Belux project called "SchoolServer". At that time, we used a Windows PE (where PE stands for "Pre-Installation Environment" and not "Portable Executable") version extracted from the Windows Server 2003 branch (NT 5.2), which was available to volume licensing customers only. But what's Windows PE?

Windows PE is a version of the Windows OS that runs without installation entirely in memory (no harddisk required) and boots from a cd-rom or the network (as we'll see it goes further than that in v2.0).

The reason to use it is pretty straightforward: for "Pre-Installation" tasks, such as disk partitioning, or even to build a (scripted) system setup that runs in a familiar Windows environment right from the start (e.g. generating a winnt.sif unattended installation file using a nice graphical wizard, making the right partitions, copying setup sources to the harddrive and invoking setup using winnt.exe or so). But also for day-to-day computer (disk) administration tasks, this proves very useful. Indeed, Microsoft's Windows PE solution isn't the only one out there but are others as well which have similar ideas like BartPE (I'm not that Bart).

If you've installed Windows Vista or Windows Server 2008 already (I hope you did), you'll have noticed that there's no blue-background textual setup anymore, the system boots into Windows from the cd to have an end-to-end graphical setup which is based on the Windows PE technology. As a developer I loved to have such a Windows PE version myself bootable from USB Flash and for free. In this post I explain how I did it from A to Z. I'll also explain how to create an ISO image for Windows PE cd's.

Getting started: download and install the WAIK

WAIK stands for the Windows Automated Installation Kit and is available as a download. It's a big download, but it's worth to put your connection under stress for :-). Burn it to a cd or mount it using some ISO/IMG mounting tool and install it.

The Windows PE Tools Command Prompt

Next, open up the Windows PE Tools Command Prompt from the Start Menu and make sure to Run as Administrator:

Alternatively, you can change the shortcut's properties, Advanced..., Run as Administrator to run it everytime elevated as an administrator:

You should see something like this:

Notice the message points you at a few usable executables: peimg, oscdimg and imagex. We're going to use these in a minute.

Building your Windows PE

In order to build your custom Windows PE, follow the next steps:

Run copype.cmd as follows:

> copype.cmd x86 c:\winpe_x86

This makes a copy of the Windows PE files to the specified folder. Alternatively, you can specify amd64 for 64-bit machines. We'll manipulate this folder in the next steps.
Next, you can customize the Windows PE image (using the Windows Imaging Format, aka WIM) using ImageX:

You can mount a WIM file to a folder like this:

> mkdir c:\winpe_x86\mount
> imagex /mountrw c:\winpe_x86\winpe.wim 1 c:\winpe_x86\mount

For the curious, this works through a file system driver called WimFltr (see sc queryex WimFltr).
Add all apps you like to add to the image in the mounted folder. Windows PE is based on packages that can be added to the image at will. This is done through peimg, like this:

> peimg /list /image=c:\winpe_x86\mount\Windows

to show a list of all images:

Next, you can add packages by calling:

> peimg /install=<package> c:\winpe_x86\mount\Windows

where package is either * (all packages) or one from the list shown by invoking peimg with the /list switch.
You could add drivers and language packs as well, but for that I refer kindly to the excellent help documentation that comes with the WAIK. When you're done with the image customization, run peimg with the prep switch:

> peimg /prep c:\winpe_x86\mount\Windows

and unmount the image using ImageX:

> imagex /unmount c:\winpe_x86\mount /commit

and copy the created .wim file to the ISO folder:

> copy c:\winpe_x86\winpe.wim c:\winpe_x86\ISO\sources\boot.wim
Next you can create an ISO file for the image using oscdimg:

> oscdimg -n -bc:\winpe_x86\etfsboot.com c:\winpe_x86\ISO c:\winpe_x86\winpe_x86.iso

where the -b flag specifies the El Torito boot sector for the ISO to be created. It just takes a few seconds to complete:
To test your image, just create a new Virtual PC virtual machine (e.g. with 256 MB of RAM) and mount the ISO file. No harddisk or network adapters needed:

VPC should boot like this:

Feel free to start taskmgr and notepad or so to get familiar with your next big friend :-). Finally shut it down using wpeutil shutdown.
You might have noticed the image has the QWERTY keyboard layout, but you can change that if you like to do so. Go back to step 2 to mount and do the following on the mounted image using intlcfg:

> intlcfg -inputlocale:<locale> -image:c:\winpe_x86\mount
> intlcfg -syslocale:<locale> -image:c:\winpe_x86\mount
> intlcfg -userlocale:<locale> -image:c:\winpe_x86\mount

where <locale> is replaced by the locale you want (e.g. nl-be for Belgian Period keyboard).

Go back to step 4 to unmount, commit, prep and create the iso. Rerun VPC to test.

For the curious, this changes some of the <mount>\Windows\System32\config\*.* registry hives:

In regedit.exe you can mount these hives to see what's in. To do this, open regedit, select HKLM and choose File, Load Hive. Next select the file to load (e.g. DEFAULT) and specify a name for the loaded hive (e.g. Mount):

As you can see, intlcfg has changed the Keyboard Layout\Preload list. Of course, the hardcore ones of you might prefer to make changes to the registry hive directly this way. By the way, while you're in the loaded hive, check out other settings like:

- desktop wallpaper via Control Panel\Desktop\WallPaper
- (from the SYSTEM hive) command line to invoke after starting Windows PE via Setup\Cmdline

Tip: regedit.exe is also available in Windows PE itself, so you can check the outcome over there. However, changes mage while running Windows PE won't take effect since the registry is loaded in memory.
Finally, it's time to put the whole thing on a USB Flash key or to burn the ISO created in step 5 to a cd-rom. I'll cover the former option. Open up diskpart and execute the following commands:

WARNING! Make sure to select the right disk in step 1; you can view all disks using the "list disk" command. In the steps below, all data from the USB Flash disk will be removed!

> select disk 1
> clean
> create partition primary
> select partition 1
> active
> format fs=fat32
> assign
> exit

Now copy to the c:\winpe_x86\ISO folder contents to the USB disk (which I assume has letter E: assigned):

> xcopy c:\winpe_x86\ISO\*.* E: /E
Now you should be able to boot from the USB Flash disk. Make sure to select the right boot device during the boot cycle or to change the boot order in your computer's BIOS.

Enjoy!

Simple managed code UAC elevation tool

bart — Fri, 14 Sep 2007 23:34:20 GMT

Everyone knows UAC by now. One core element of Vista's UAC vision is the elevation of processes, used to run something as an administrator. Typically, you open up a command line instance (cmd.exe) which has been elevated already prior to invoking commands that require elevation. But what if you're already in a non-elevated command prompt window and need to start an executable that runs elevated? In a such a scenario a tool like the one shown below might be useful:

using System;
using System.Diagnostics;
using System.Reflection;
class Program
{
    static void Main(string[] args)
    {
        if (args.Length == 0)
        {
            Console.WriteLine("Usage: {0}.exe <command>", Assembly.GetExecutingAssembly().GetName().Name);
            return;
        }
        string @params = "";
        if (args.Length > 1)
            @params = string.Join(" ", args, 1, args.Length - 1);
        ProcessStartInfo psi = new ProcessStartInfo(args[0], @params);
        psi.Verb = "runas";
        Process.Start(psi);
    }
}

This tool uses the regular Process class from the .NET Framework but specifies a Verb on the ProcessStartInfo object. You can find more info on verbs in the Windows SDK under "Verbs and File Associations". Enjoy!

Windows Vista - WinSta0 isolation explained

bart — Tue, 06 Mar 2007 07:08:13 GMT

Time for another security feature in Windows Vista: WinSta0 isolation. The first question that might pop up in your head is "So, what exactly is WinSta0?". Keith Brown has the answer.

The problem with WinSta0 is the possibility for Windows Services to display a UI prompt in the window station. Pre-Vista, this prompt just appears on top of the desktop of the user logged on to the system. Because of this, the service is exceeding its boundary of isolation and the inware user is providing information across that "trust boundary".

Windows Vista reduces this risk by isolating WinSta0 from the active user's desktop; a user has to provide his/her consent to switch to the bare WinSta0 when that screams for attention (which is detected by an executable called UI0Detect.exe as displayed below):

When you see this kind of message, the app you're dealing with has "partial incompatibility with Windows Vista". The message to developers: fix it - Windows doesn't like the old approach anymore! An example I've been faced with in practice is the HP LaserJet 1020 software that uses WinSta0 to show out of paper messages and other printer maintenance messages.

In this post, I'm showing you the code for a demo of a WinSta0 isolation demo I gave some time ago, together with demonstration instructions.

Step 1 - Creating an interactive Windows Service

So, for sake of the demo, let's create something we really shouldn't have created: an interactive Windows Service. Open Visual Studio 2005 and create a new Windows Service project called "WinSta0Inspector" in C#:

Next, go to Service1.cs and change the service name to WinSta0Inspector:

Right-click the designer surface and choose Add Installer. This will create a new file ProjectInstaller.cs that makes the executable installutil.exe-able. In there, select the serviceProcessInstaller1 "control" and set the Account property to Local System (to make things really bad):

In order to make the service interactive, we'll create a simple Windows Form. Right click the project in the Solution Explorer, choose Add New Item and add a Windows Form called ExecuteCommand.cs. Design it so that it looks like this:

Hook up event handlers for both LinkLabels, with definitions like this:

private void linkLabel1_LinkClicked(object sender, LinkLabelLinkClickedEventArgs e)
{
    Process.Start("cmd.exe");
}

private void linkLabel2_LinkClicked(object sender, LinkLabelLinkClickedEventArgs e)
{
    DialogResult = DialogResult.OK;
}

Don't forget to import System.Diagnostics in order to have access to the Process class. Now go back to Service1.cs and switch to the code view. Define the Service1 class as follows:

public partial class Service1 : ServiceBase
{
    private ExecuteCommand dialog = new ExecuteCommand();

    public Service1()
    {
        InitializeComponent();
    }

    protected override void OnStart(string[] args)
    {
    }

    protected override void OnCustomCommand(int command)
    {
        MessageBox.Show("Welcome to WinSta0.", "WinSta0 is calling you!", MessageBoxButtons.OK, MessageBoxIcon.Exclamation);
        dialog.ShowDialog();
    }
}

You'll need to import System.Windows.Forms to have access to MessageBox. This completes our interactive service.

Step 2 - Installing it

Compile the solution and switch to a Visual Studio 2005 Command Prompt which runs elevated with administrator privileges. Install the service using installutil -i WinSta0Inspector.exe. Then open the Services MMC snap-in (services.msc), locate the WinSta0Inspector service and change its properties to make it interactive:

Command-line freaks could also use the following command to install the service directly as an interactive service; no need to run installtutil then, just do this:

sc create WinSta0Inspector binPath= WinSta0Inspector.exe type= interact DisplayName= "WinSta0 Inspector"

Step 3 - Action!

In order to see it in action, start the service and send it a custom command. You could write another app to send the custom command using the System.Service.ServiceController::ExecuteCommand method, but sc.exe has everything we need:

First, we started the service using net start WinSta0Inspector. Next, we sent a command to the service by using sc control WinSta0Inspector 129 (valid commands should be higher than 128, other values are system-reserved). Right away you'll see the Interactive services dialog detection dialog popping up in the background:

Click Show me the message and Vista will bring you to the raw WinSta0 environment which should look somewhat like this:

Press OK in our message box; the WinForms dialog will show up now:

Feel free to take a look around WinSta0 using the command-prompt link on the form. For example, run whoami /all to find out about your SYSTEM power :-)

If you have a hacker's mindset you might find HKLM\SECURITY\SAM an attractive place to visit while you're the Windows übermensch :o. Below you can see a few other screenshots of what it is like to be in WinSta0 (e.g. how did I create the screenshots?):

Have fun!

New in Orcas - Embedding Vista UAC manifests in 30 seconds

bart — Mon, 05 Mar 2007 07:58:41 GMT

Note: This article applies to the Visual Studio "Orcas" March 07 CTP build that can be downloaded from the Microsoft website.

In this post we'll talk about embedding UAC (User Account Control) manifests in managed code executables without having to rely on rather dirty tricks, as I explained in my older blog post entitled Windows Vista - Demand UAC elevation for an application by adding a manifest using mt.exe. Please read this post prior to reading this post, in order to get a good idea about UAC and manifests.

Essentially, this article performs a little word substitution on the title of the previous post: adding a manifest ~~using mt.exe~~ using Visual Studio "Orcas".

Step 1 - Creating the Windows Forms app

We'll start by creating the same app as we did in the previous post mentioned above. Open up VS "Orcas", create a new (C#) Windows Forms project called UacDemo and add a label called "label1" to the designer surface. As a side-note, play around with the IDE designer for Windows Forms a bit, you'll see that the Layout toolbar has been revamped (for example, add another label, select both labels and observe the options in this toolbar):

Next, go to the code and add an event handler for Form1_Load that does the following:

label1.Text = new WindowsPrincipal(WindowsIdentity.GetCurrent()).IsInRole(WindowsBuiltInRole.Administrator) ? "Yup" : "Nope";

You'll need to bring the System.Security.Principal namespace in scope in order to compile the code above.

Step 2 - Add a manifest to the project

Add a new item to the project and choose for an XML file. Call it UacDemo.exe.manifest:

Add the following contents to it:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
   <assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="UacDemo" type="win32"/>
      <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
      <security>
         <requestedPrivileges>
            <requestedExecutionLevel level="requireAdministrator"/> 
         </requestedPrivileges>
      </security>
   </trustInfo>
</assembly>

Notice that the name attribute of the assemblyIdentity element has to be set to the name of the executable (without .exe extension). Information about UAC manifests can be found by searching "requestedPrivileges" on the internet for instance.

Step 3 - Tell the build environment to include the manifest

This is where things got difficult in the past. A solution pre-Orcas was explained on my aforementioned previous blog entry on UAC using a post-build step calling the mt.exe tool. Now, things have become much more simple. Just go to the properties of the project, tab Application and scroll down to the section "Resources" as shown below:

In the manifest dropdown box you can now point to the manifest we've created in the previous step.

Step 4 - Build, inspect, test

That's it; we're done now! To illustrate what has happened, take a look at the .csproj file of the project using an XML editor; below is a snippet from this file on my machine:

<Project ToolsVersion="3.5" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProductVersion>9.0.20209</ProductVersion>
    <SchemaVersion>2.0</SchemaVersion>
    <ProjectGuid>{8FB484D6-73DB-4AEE-8222-7FE5B0CBD622}</ProjectGuid>
    <OutputType>WinExe</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>UacDemo</RootNamespace>
    <AssemblyName>UacDemo</AssemblyName>
    <TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
    <FileAlignment>512</FileAlignment>
    <ApplicationManifest>UacDemo.exe.manifest</ApplicationManifest>
  </PropertyGroup>

First, observe the presence of multi-targeting: the Project's ToolsVersion attribute tells the tools that use the .csproj file to use the 3.5 version of the framework; furthermore, TargetFrameworkVersion tags appear in the file, as well as RequiredTargetFramework tags for dependencies (not illustrated in the snippet above). However, for us the ApplicationManifest element is much more interesting since it points to our manifest file; this tells MSBuild to take mt.exe alike steps to include the manifest in the executable when compilation has been done successfully.

To see that the manifest is included correctly, you can go to the Visual Studio Orcas Command Prompt, cd into the bin\Debug or bin\Release folder of the UacDemo project and call mt -inputresource:uacdemo.exe -out:uacdemo.exe.manifest to extract the manifest from the file and to see what's in there:

Finally, run the file on your Vista machine and you should see the UAC prompt popping up to elevate the privileges of the app:

Notice that creating screenshots from the UAC prompt isn't easy due to the presence of the "UAC Secure Desktop" where the UAC prompts are displayed. In order to make it possible, open up secpol.msc, go to Local Policies, Security Options and tweak the "User Account Control: Switch to the secure desktop when prompting for elevation" setting to Disabled (don't forget to revert it afterwards!):

Enjoy!

Windows Vista - Introducing TxF in C# (part 3) - CreateFileTransacted demo

bart — Thu, 22 Feb 2007 07:03:35 GMT

In November last year, I blogged about TxF:

A few days ago I received a mail from a reader of my blog who had an issue with a similar CreateFileTransacted code snippet which allows to manipulate file content in the scope of a transaction. In today's post, I show a little demo on how to do this.

  1 using System;
  2 using System.IO;
  3 using Microsoft.Win32.SafeHandles;
  4 using System.Runtime.InteropServices;
  5 
  6 class TxfDemo
  7 {
  8    const uint GENERIC_READ = 0x80000000;
  9    const uint GENERIC_WRITE = 0x40000000;
 10    const uint CREATE_NEW = 1;
 11    const uint CREATE_ALWAYS = 2;
 12    const uint OPEN_EXISTING = 3;
 13 
 14    [DllImport("kernel32.dll", SetLastError = true)]
 15    static extern SafeFileHandle CreateFile(
 16       string lpFileName,
 17       uint dwDesiredAccess,
 18       uint dwShareMode,
 19       IntPtr lpSecurityAttributes,
 20       uint dwCreationDisposition,
 21       uint dwFlagsAndAttributes,
 22       IntPtr hTemplateFile);
 23 
 24    [DllImport("kernel32.dll", SetLastError = true)]
 25    static extern SafeFileHandle CreateFileTransacted(
 26       string lpFileName,
 27       uint dwDesiredAccess,
 28       uint dwShareMode,
 29       IntPtr lpSecurityAttributes,
 30       uint dwCreationDisposition,
 31       uint dwFlagsAndAttributes,
 32       IntPtr hTemplateFile,
 33       IntPtr hTransaction,
 34       IntPtr pusMiniVersion,
 35       IntPtr pExtendedParameter);
 36 
 37    [DllImport("ktmw32.dll", SetLastError = true)]
 38    static extern IntPtr CreateTransaction(
 39       IntPtr lpTransactionAttributes,
 40       IntPtr uow,
 41       uint createOptions,
 42       uint isolationLevel,
 43       uint isolationFlags,
 44       uint timeout,
 45       string description);
 46 
 47    [DllImport("ktmw32.dll", SetLastError = true)]
 48    static extern bool CommitTransaction(
 49       IntPtr transaction);
 50 
 51    [DllImport("ktmw32.dll", SetLastError = true)]
 52    static extern bool RollbackTransaction(
 53       IntPtr transaction);
 54 
 55    [DllImport("Kernel32.dll")]
 56    static extern bool CloseHandle(IntPtr handle); 
 57 
 58    static void Main()
 59    {
 60       string file = "txfdemo.txt";
 61 
 62       //
 63       // For demo purposes, delete the file first (if it already exists).
 64       //
 65       if (File.Exists(file))
 66         File.Delete(file);
 67 
 68       //
 69       // Create KTM transaction.
 70       //
 71       IntPtr transaction = CreateTransaction(IntPtr.Zero, IntPtr.Zero, 0, 0, 0, 0, null);
 72 
 73       //
 74       // Check transaction handle.
 75       //
 76       if (transaction == IntPtr.Zero)
 77       {
 78          Console.WriteLine("Oops! KTM has taken a day off.");
 79          return;
 80       }
 81 
 82       try
 83       {
 84          //
 85          // Non-transacted.
 86          //
 87          //SafeFileHandle handle = CreateFile(file, GENERIC_READ | GENERIC_WRITE, 0, IntPtr.Zero, CREATE_NEW, 0, IntPtr.Zero);
 88 
 89          //
 90          // Transacted file creation (CREATE_NEW).
 91          //
 92          SafeFileHandle handle = CreateFileTransacted(file, GENERIC_READ | GENERIC_WRITE, 0, IntPtr.Zero, CREATE_NEW, 0, IntPtr.Zero, transaction, IntPtr.Zero, IntPtr.Zero);
 93 
 94          //
 95          // Check handle.
 96          //
 97          if (handle.IsInvalid)
 98             Marshal.ThrowExceptionForHR(Marshal.GetLastWin32Error());
 99 
100          //
101          // Using pattern for stream operations.
102          //
103          using (FileStream fs = new FileStream(handle,FileAccess.ReadWrite))
104          {
105             using (StreamWriter sw = new StreamWriter(fs))
106             {
107                sw.WriteLine("Hello");
108             }
109          }
110 
111          //
112          // To commit or not to commit?
113          //
114          Console.WriteLine("Press Y to commit");
115 
116          char c = Console.ReadKey().KeyChar;
117          if (c == 'y' || c == 'Y')
118             CommitTransaction(transaction);
119          else
120             RollbackTransaction(transaction);
121       }
122       catch (Exception ex)
123       {
124          Console.WriteLine("Oops! {0}", ex.Message);
125 
126          //
127          // Rollback.
128          //
129          RollbackTransaction(transaction);
130       }
131       finally
132       {
133          //
134          // Close kernel mode transaction handle.
135          //
136          CloseHandle(tx); 
137       }
138    }
139 }

The sample shows how to create a file (change CREATE_NEW on line 89 if you want to open an existing file for instance) and how to hand over the SafeFileHandle to the FileStream class for further usage. Notice that the code above has some fundamental security problems concerning path sanitation of the variable "file". You might want to take a look at the SSCLI code (\clr\src\bcl\system\io\filestream.cs - FileStream::Init(...) method) for details on how to implement a much safer library that calls CreateFile(Transacted). Especially, you have to pay attention to path normalization (do you really want ".." sequences in your path?), the infamous \\.\ sequence that allows to talk to ports (e.g. COM1), the \\?\ prefix for long path names (cf. MAX_PATH), code access security (cf. FileIOPermission demand), etc.

Ignoring the warnings above (which - one day - I might resolve using a TxF aware set of classes that incorporates the required security checks), the sample will create a file called "txfdemo.txt" in the current folder, write "Hello" to it (line 104) and wait for the end-user to press Y to commit. Before you press a key (line 113), open up an instance of Windows Explorer or another command prompt and observe that (due to the isolation property of ACID transactions) the file isn't present yet. If you press Y, the file will appear out of the blue because of the transaction commit. Any other key (other than 'y' and 'Y') will rollback the transaction, which also happens in case of an exception.

Exercise: (re)read Windows Vista - Introducing TxF in C# (part 2) - Using System.Transactions and the DTC and make the code above System.Transactions aware (also adding more flexibility concerning various parameters - line 89 - see Windows SDK CreateFileTransacted documentation for more info, as well as the .h header file that come with the SDK for symbolic constant values).

Brain.Commit();

Windows Vista Application Recovery on MSDN (woohoo)

bart — Thu, 28 Dec 2006 14:03:07 GMT

I couldn't believe my own eyes when reviewing the blog stats of yesterday: a 90% overall increase in the number of requests. Impossible at first sight, but here's the explanation: a link on MSDN's Windows Vista homepage to my article on Application Recovery :o.

Update: December 28, 2006 finished with a total number of 150,979 page requests. Compared to an average of 20,192 page requests per day this is too good to be true (647% increase). For the overall month score, there's already a growth of 50% compared to November. Seems like my New Year's gift will be additional bandwidth at my hosting company...

Apparently the "other side" was reading this page too, quoting the following phrase:

Although it's always better to fix the bugs, a smooth "crashing experience" [...] also helps to improve the end-user experience.

What I want to stress on is that the Application Recovery API is a generic OS-level API that controls how Windows responds to the event of an application that crashes. In the past, error reporting and immediate process termination was the only possible outcome. Now developers have the tools at hand to control what happens: application restart and a recovery opportunity before process termination.

In the end, who wants to bet his or her software to be 100% bug free? Think of the number of dependencies software rely on nowadays ... lots of places where something might go wrong you didn't account for.

Note: Others mention that lots of software packages in the past had the same functionality, allowing for document recovery etc. That's true of course, but with the Application Recovery API this kind of functionality becomes more available for all sorts of developers and all sorts of applications. The whole point is that existing software packages with recovery functionality have to employ some strategy in the code to make this possible, e.g. by working on temporary files (cf. Word) that can be recovered when the app is restarted. Or by some kind of auto-save functionality (I recall what I read in some manual 10 years or so ago: "auto-save prevents loosing information when the computer's power supply fails or electricity outage occurs"). When programming with the Application Recovery API, action is taken right after the moment the software crashed, allowing you to do recovery from the inside before the process is terminated. In lots of cases, you'll just grab some internal data structure and persist it to disk. It all depends on the kind of app.

Last but not least, it's a tradeoff once more. Do you want to go through the burden of writing possible complex recovery mechanisms, allowing to "clean up" the "normal" code paths (i.e. eliminating the "aspect" of recovery allowance thoughout the code), or do you trust the software to be bug-free enough, or maybe you just don't care about crashes (but you still might to want to use the Application Recovery API just to restart the app automatically after a possible crash, just like Windows Services can be restarted automatically by the SCM after unexpected termination).

After all, it's about fighting Finagle's law (wouldn't that be even nicer to quote me on?). And under any circumstance, including the recovery itself, something might go wrong.

Just my .314 cents.

Windows Vista - Introducing TxR in C# (Part 2)

bart — Fri, 15 Dec 2006 16:15:35 GMT

Introduction

In the previous post about TxR, we covered how to interact with the KTM (Kernel Transaction Manager) directly from managed code and how to perform transactional registry operations, illustrated by using RegDeleteKeyTransacted. In today's post, we'll bring the DTC (Distributed Transaction Coordinator) and System.Transactions into play, which will allow us to do things like this:

using (TransactionScope tx = new TransactionScope())
{
    DeleteKey(HKey.HKEY_CURRENT_USER, key1);
    DeleteKey(HKey.HKEY_CURRENT_USER, key2);
}

Needless to say, because of the role of the DTC, we can perform other transactional operations in the same scope and make all of these either complete together or not. Examples include the use of TxF in the same transaction scope, or database operations on SQL Server, or MSMQ stuff, or ... well whatever you might think of.

The code

Below, you can find a piece of sample code on how you might go ahead and create a very basic TxR library. The focus of this post will be on the System.Transactions stuff you have to take care of and the low-level plumbing to involve the DTC:

  1 using System;
  2 using System.Runtime.InteropServices;
  3 using System.IO;
  4 using Microsoft.Win32;
  5 using System.Transactions;
  6 
  7 namespace TxR
  8 {
  9     class Program
 10     {
 11         #region Transactional Registry operations
 12 
 13         [DllImport("advapi32.dll", EntryPoint="RegDeleteKeyTransactedW")]
 14         static extern long RegDeleteKeyTransacted(uint hkey, [MarshalAs(UnmanagedType.LPWStr)]string subkey, RegSam sam, uint reserved, IntPtr transaction, IntPtr reserved2);
 15 
 16         enum HKey : uint
 17         {
 18             HKEY_CURRENT_USER = 0x80000001
 19         }
 20 
 21         [DllImport("Kernel32.dll")]
 22         static extern bool CloseHandle(IntPtr handle);
 23 
 24         enum RegSam : uint
 25         {
 26             KEY_WOW64_32KEY = 0x0200,
 27             KEY_WOW64_64KEY = 0x0100
 28         }
 29 
 30         [ComImport]
 31         [InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
 32         [Guid("79427A2B-F895-40e0-BE79-B57DC82ED231")]
 33         internal interface IKernelTransaction
 34         {
 35             void GetHandle([Out] out IntPtr handle);
 36         }
 37 
 38         static void DeleteKey(HKey hkey, string subkey)
 39         {
 40             if (Transaction.Current != null)
 41             {
 42                 IKernelTransaction tx = (IKernelTransaction)TransactionInterop.GetDtcTransaction(Transaction.Current);
 43                 IntPtr txh;
 44                 tx.GetHandle(out txh);
 45 
 46                 if (txh == IntPtr.Zero)
 47                     throw new Exception(); //Q-n-D
 48 
 49                 if (RegDeleteKeyTransacted((uint)hkey, subkey, RegSam.KEY_WOW64_32KEY, 0, txh, IntPtr.Zero) != 0)
 50                     throw new Exception(); //Q-n-D
 51 
 52                 CloseHandle(txh);
 53             }
 54             else
 55             {
 56                 //
 57                 // Perform non-transacted delete using Microsoft.Win32 APIs.
 58                 //
 59             }
 60         }
 61 
 62         #endregion
 63 
 64         static void Main(string[] args)
 65         {
 66             //
 67             // Demo setup.
 68             //
 69             string key1 = "RegDeleteKeyTransactedDemo_01";
 70             string key2 = "RegDeleteKeyTransactedDemo_02";
 71             Registry.CurrentUser.CreateSubKey(key1);
 72             Registry.CurrentUser.CreateSubKey(key2);
 73 
 74             //
 75             // Start the demo.
 76             //
 77             Console.WriteLine("Press <ENTER> to start the transaction.");
 78             Console.ReadLine();
 79 
 80             //
 81             // Make it transacted.
 82             //
 83             using (TransactionScope tx = new TransactionScope())
 84             {
 85                 //
 86                 // Delete the keys (transacted).
 87                 //
 88                 DeleteKey(HKey.HKEY_CURRENT_USER, key1);
 89                 DeleteKey(HKey.HKEY_CURRENT_USER, key2);
 90 
 91                 //
 92                 // Commit or rollback?
 93                 //
 94                 char c;
 95                 do
 96                 {
 97                     Console.WriteLine("{0} {1}.", key1, Registry.CurrentUser.OpenSubKey(key1) != null ? "still exists" : "has vanished");
 98                     Console.WriteLine("{0} {1}.", key2, Registry.CurrentUser.OpenSubKey(key2) != null ? "still exists" : "has vanished");
 99                     Console.Write("Commit transaction (Y/N)? ");
100                     c = (char)Console.Read();
101                 }
102                 while (c != 'Y' && c != 'y' && c != 'N' && c != 'n');
103 
104                 if (c == 'Y' || c == 'y')
105                     tx.Complete();
106             }
107        }
108    }
109 }

The "library" is implemented in lines 11 to 62. First of all, compared to the code in the previous post, observe the omission of the KTM-related functions. Instead, we'll rely on the DTC to do the plubming behind the scenes to create the transaction. We only need to obtain a handle to the transaction to get ahead and call the RegDeleteKeyTransacted function in line 49.

A few remarks:

Line 14 has remained unchanged compared to the original version. It just declares our much desired demo function RegDeleteKeyTransacted.
Lines 16 to 19 define a simple enum which of course needs to be extended to be really useful. Basically, I just wanted to encapsulate HKEY_CURRENT_USER in a an enum that will be used further on as a parameter to indicate the root hive when calling our DeleteKey function.
Lines 30 to 36 are used to obtain a handle to the KTM transaction through DTC. This IKernelTransaction interface is new in Windows Vista and is used to build the bridge between DTC and the KTM for transactional Windows API. It has only one method called GetHandle described as follows in the SDK: Returns a handle that represents the transaction and can be passed as a parameter to transacted Windows APIs.
One line 40, we investigate whether or not we're already involved in a System.Transactions transaction (by means of a TransactionScope that is):
- If not, we'll just perform the operation without using a transaction (line 56-59) using Microsoft.Win32 (you can supply this code yourself; I didn't want to do it here because it'd need a switch over different HKey values, which still needs to be extended).
- Otherwise, in line 42, the IKernelTransaction::GetHandle function gets called. Luckily, the System.Transactions.TransactionInterop class has a static method GetDtcTransaction defined that can obtain the low-level DTC transaction corresponding to a System.Transactions transaction. The handle is obtained in lines 43 and 44.
  - If no valid handle is retrieved, we throw an exception, which on the caller side of our function will terminate the transaction in flight (when exceptions are thrown through the course of a TransactionScope, it rolls back).
  - Otherwise, the RegDeleteKeyTransacted function is called on line 49. Again, if something goes wrong, we throw an exception (which is done in a quick-n-dirty way for demo purposes; you'll need to provide more information through a self-written exception to do it the right way).
- On line 52, the transaction's handle is closed using CloseHandle. Again, code needs to be polished to be ready for production and to make sure this handle is closed under all circumstances. SafeHandles might be your friends to do this (which I'll blog about later).

On the consumer side, not much has changed. Again we do create two keys for demo purposes (on lines 69 to 72). Next, in the System.Transactions.TransactionScope transaction scope (lines 83 to 106), the keys are deleted. If one of the deletions fails, an exception is thrown by our DeleteKey function and the transaction will roll back. Otherwise, execution reaches line 94, triggering the end-user decision logic, which ultimately calls Complete for commit the transaction scope if the user decides to do so.

Conclusion

All of the magic done in DeleteKey makes the use of the KTM and transactional APIs completely invisible for the managed code programmers that can rely on the comfortable System.Transactions namespace. Just what we needed.

Windows Vista - Introducing TxR in C# (Part 1)

bart — Thu, 14 Dec 2006 21:12:48 GMT

Introduction

Last month I blogged about TxF in Windows Vista and how to use it from your own application to perform transactional file operations. You can find both posts over here:

Today we'll take a look at TxR brother, TxR which stands for Transactional Registry, a brand new feature in Windows Vista (and Longhorn Server) that makes it possible to perform registry operations in a transactional manner. A typical usage scenario might be a setup application that's performing a bunch of file operations (using TxF) and registry operations (using TxR) which can either be committed all together or rolled back in case something went wrong (or the user cancelled the installer).

The next two paragraphs are borrowed from my orginal TxF posts, but adapted for TxR and to reflect the situation in Windows Vista RTM.

**Your new friends are *Transacted**

Probably you know about the Reg* functions in the Windows API, like RegDeleteKey, RegDeleteKeyEx, RegCreateKeyEx, amongst many others (take a look at the MSDN documentation for a full list). All these functions remain unchanged in Windows Vista, with the same semantics.

However, if you want to perform transactional registry operations, a new set of functions is in place to help you out: Reg*Transacted, for example RegDeleteKeyTransacted and RegOpenKeyTransacted (which makes all subsequent operations performed against that key - with classic functions to set values and stuff). All of the transactional functions rely on the Kernel Transaction Manager (KTM) which manages transactions in the operating system. As an example, consider the following RegDeleteKeyTransacted function which has a pretty simple signature:

LONG RegDeleteKeyTransacted( HKEY hKey, LPCTSTR lpSubKey, REGSAM samDesired, DWORD Reserved, HANDLE hTransaction, PVOID pExtendedParameter );

The last two parameters are the ones used to make the operation transactional: hTransaction passes a handle to the KTM transaction, the pExtendedParameter is currently reserved and has to be set to NULL.

The KTM in a few words

On to the KTM stuff right now. As mentioned earlier, KTM stands for Kernel Transaction Manager. Don't get confused by the word kernel, it only refers to the fact the KTM's transaction engine is in the kernel. This doesn't imply the transaction can only run in kernel mode (i.e. KTM-transactions can be used in kernel and user mode) nor does it mean the transaction would be machine-local (i.e. the transaction is DTC-able). On Vista and Longhorn Server, the KTM is in charge of TxF (Transactional NTFS) and TxR (Transactional Registry).

Important remark: Today we walk the low-level path, interacting directly with the KTM. This is not the ideal way but just a mind-setter for follow-up posts. Later on, we'll bring System.Transactions on stage to interact with the KTM transaction.

Warning: Do read the Windows SDK documentation carefully before working with TxR operations, especially the RegOpenKeyTransacted function information concerning the pick-up of the active transaction by other functions subsequently.

A demo

Let's start by showing you the code right away:

 1 using System;
 2 using System.Runtime.InteropServices;
 3 using System.IO;
 4 using Microsoft.Win32;
 5 
 6 namespace TxR
 7 {
 8     class Program
 9     {
10         [DllImport("advapi32.dll", EntryPoint="RegDeleteKeyTransactedW")]
11         static extern long RegDeleteKeyTransactedW(uint hkey, [MarshalAs(UnmanagedType.LPWStr)]string subkey, RegSam sam, uint reserved, IntPtr transaction, IntPtr reserved2);
12 
13         static uint HKEY_CURRENT_USER = 0x80000001; 
14 
15         [DllImport("Kernel32.dll")]
16         static extern bool CloseHandle(IntPtr handle);
17 
18         [DllImport("Ktmw32.dll")]
19         static extern bool CommitTransaction(IntPtr transaction);
20 
21         [DllImport("Ktmw32.dll")]
22         static extern bool RollbackTransaction(IntPtr transaction);
23 
24         [DllImport("Ktmw32.dll")]
25         static extern IntPtr CreateTransaction(IntPtr securityAttributes, IntPtr guid, int options, int isolationLevel, int isolationFlags, int milliSeconds, string description);
26 
27         static void Main(string[] args)
28         {
29             //
30             // Demo setup.
31             //
32             string key1 = "RegDeleteKeyTransactedDemo_01";
33             string key2 = "RegDeleteKeyTransactedDemo_02";
34             Registry.CurrentUser.CreateSubKey(key1);
35             Registry.CurrentUser.CreateSubKey(key2);
36 
37             //
38             // Start the demo.
39             //
40             Console.WriteLine("Press <ENTER> to start the transaction.");
41             Console.ReadLine();
42 
43             //
44             // Create a kernel transaction.
45             //
46             IntPtr tx = CreateTransaction(IntPtr.Zero, IntPtr.Zero, 0, 0, 0, 0, null);
47 
48             //
49             // Delete the keys (transacted).
50             //
51             bool rollback = false;
52             if (RegDeleteKeyTransacted(HKEY_CURRENT_USER, key1, RegSam.KEY_WOW64_32KEY, 0, tx, IntPtr.Zero) != 0)
53                 rollback = true;
54             if (RegDeleteKeyTransacted(HKEY_CURRENT_USER, key2, RegSam.KEY_WOW64_32KEY, 0, tx, IntPtr.Zero) != 0)
55                 rollback = true;
56 
57             //
58             // Commit or rollback?
59             //
60             if (!rollback)
61             {
62                 char c;
63                 do
64                 {
65                     Console.WriteLine("{0} {1}.", key1, Registry.CurrentUser.OpenSubKey(key1) != null ? "still exists" : "has vanished");
66                     Console.WriteLine("{0} {1}.", key2, Registry.CurrentUser.OpenSubKey(key2) != null ? "still exists" : "has vanished");
67                     Console.Write("Commit transaction (Y/N)? ");
68                     c = (char)Console.Read();
69                 }
70                 while (c != 'Y' && c != 'y' && c != 'N' && c != 'n');
71 
72                 if (c == 'Y' || c == 'y')
73                     CommitTransaction(tx);
74                 else
75                     RollbackTransaction(tx);
76             }
77             else
78             {
79                 Console.WriteLine("Forced rollback!");
80                 RollbackTransaction(tx);
81             }
82 
83             //
84             // Close kernel mode transaction handle.
85             //
86             CloseHandle(tx);
87         }
88 
89         enum RegSam : uint
90         {
91             KEY_WOW64_32KEY = 0x0200,
92             KEY_WOW64_64KEY = 0x0100
93         }
94     }
95 }

So, what's going on in here? Some explanation:

Lines 19, 22 and 25 contain the KTM functions to create a transaction (CreateTransaction), commit a transaction (CommitTransaction) and rollback a transaction (RollbackTransaction). More information can be found in the Windows SDK.
On line 11, the RegDeleteKeyTransacted function is declared with the parameters aforementioned in this post. The handle retrieved from CreateTransaction has to be past as the 5th parameter. Notice the EntryPoint property of the DllImport attribute to choose the Unicode version of the function, as well as the LPWStr marshal type for the second parameter. (All of this is done for clarity and explicitness to see the relation between the Windows API and the interop code.)
To use the HKCU hive of the registry, we're declaring the symbolic constant HKEY_CURRENT_USER on line 13. This will be the first parameter to our RegDeleteKeyTransacted call subsequently.
Next, lines 32 to 35 create two registry keys under HKCU for further demonstration purposes. These are using the non-transactional APIs which have been wrapped in the Microsoft.Win32 managed code namespace's RegistryKey class.
One line 46, the real work starts by creating a KTM transaction using a call to CreateTransaction. We keep things simple by passing a lot of default values. For more information, take a look at the SDK.
Lines 52 and 54 perform the RegDeleteKeyTransacted calls. If those return an error code (non-zero), we set the rollback boolean value to true, to indicate that not all operations succeeded and the transaction has to be rolled back (if that's the behavior you want if any of the operations fails, you might want to do more error code analysis to make this decision too of course).
- If the transaction has to be rolled back, line 80 does that work by calling RollbackTransaction.
- Otherwise, we leave the decision to the user to either commit (CommitTransaction) or rollback.
Finally, let's clean up things an close the handle used for the KTM transaction on line 86 by calling CloseHandle.

In action

Let's show a few pictures on a "breakpoint" basis. If the code reaches the specified line, the displayed screenshot (click to enlarge) will reflect the actual situation in the registry:

Line 28 - the demo keys haven't been created yet:
Line 40 - the demo keys are there:
Line 67 - the transactional delete operations have been executed but because of the ACID Isolation property, nothing is visible yet for the outside world:
Line 73 - the user decided to commit the transaction, now the keys are gone:

What's next?

In part 2 we'll take a look at how we can use the DTC and the System.Transactions namespace to enroll the KTM transaction in a distributed transaction and how to encapsulate the low level plumbing in a little library. Again, we'll focus on the RegDeleteKeyTransacted stuff because of its simplicity. In a later post, we might take a look at other registry operations too, which - however - need a bit more work regarding various parameters and would take the focus off the transactional stuff we're covering. The ultimate solution would be a change to Microsoft.Win32 to incorporate transactional support in Windows Vista and higher.

Windows Vista - Exploring the Windows System Assessment Tool (WinSAT) API in C# (some reactions)

bart — Wed, 13 Dec 2006 22:59:41 GMT

Yesterday I published a blog post about the WinSAT API in Windows Vista. It's always great to see others referring to posts and providing comments and suggestions, as this was the case with AddressOf.com. However, a few reactions on the reactions:

I really distaste the idea of "unsafe" code unless there is absolutely no way around using it... and even then I'd probably choose to implement a solution using C/C++ if that was the case.

What unsafe code is concerned, if you know what you're doing there's no real problem but I agree it's better to avoid it whenever you can. I didn't want to go through the whole burden of explaining GCHandle, pinning, etc and for sake of the demo I just took advantage of some simple pointer stuff. So, I certainly wouldn't exchange one line of unsafe code for a complete makeover in C/C++ unmanaged code. In that case I wouldn't have written the article at all since the Windows SDK has all the info C/C++ devs need. Nevertheless, thanks for pointing to the alternative using GCHandle.Alloc. I won't ever pronounce the word unsafe code anymore :p.

I also didn't like the fact that he was using GetEnumerator instead of using the much more friendly foreach functionality and because he was using GetEnumerator, he was having to do some unnecessary casting in the process.

Then tell me how to foreach over an enumeration without casting. Okay, I could just have duplicated the code five times, like this, which would be more explicit:

IProvideWinSATAssessmentInfo i;
i = q.Info.GetAssessmentInfo(WINSAT_ASSESSMENT_TYPE.WINSAT_ASSESSMENT_CPU);
Console.WriteLine(format, i.Title, i.Description, i.Score);
i = q.Info.GetAssessmentInfo(WINSAT_ASSESSMENT_TYPE.WINSAT_ASSESSMENT_D3D);
Console.WriteLine(format, i.Title, i.Description, i.Score);
i = q.Info.GetAssessmentInfo(WINSAT_ASSESSMENT_TYPE.WINSAT_ASSESSMENT_DISK);
Console.WriteLine(format, i.Title, i.Description, i.Score);
i = q.Info.GetAssessmentInfo(WINSAT_ASSESSMENT_TYPE.WINSAT_ASSESSMENT_GRAPHICS);
Console.WriteLine(format, i.Title, i.Description, i.Score);
i = q.Info.GetAssessmentInfo(WINSAT_ASSESSMENT_TYPE.WINSAT_ASSESSMENT_MEMORY);
Console.WriteLine(format, i.Title, i.Description, i.Score);

In the end we're talking about 5 casts; no big deal for a demo app. Difference in perf? Maybe 5 to 10 ms I guess; the relatively slow API calls overshadow the whole thing. Or maybe the source of the confusion is the classic misconception that the method A1 in the following piece of code would be more efficient than method A2:

private static void A1(CQueryWinSATClass q, string format)
{
    foreach (WINSAT_ASSESSMENT_TYPE wat in Enum.GetValues(typeof(WINSAT_ASSESSMENT_TYPE)))
    {
        IProvideWinSATAssessmentInfo i = q.Info.GetAssessmentInfo(wat);
        Console.WriteLine(format, i.Title, i.Description, i.Score);
    }
}

private static void A2(CQueryWinSATClass q, string format)
{
    IEnumerator e = Enum.GetValues(typeof(WINSAT_ASSESSMENT_TYPE)).GetEnumerator();
    while (e.MoveNext())
    {
        IProvideWinSATAssessmentInfo i = q.Info.GetAssessmentInfo((WINSAT_ASSESSMENT_TYPE)e.Current);
        Console.WriteLine(format, i.Title, i.Description, i.Score);
    }
}

The point is that GetValues returns an Array, which contains elements of type System.Object, which in case of enums introduces boxing to occur. What happens in A1 is that the foreach loop is translated in similar logic as in A2, which is iterating over the (non-generic) IEnumerator returned by calling System.Array::GetEnumerator. Inside the loop, the IEnumerator's Current property will be retrieved and unboxed to the enum type. Because my blog readers like IL, I've included this analysis below. For A1 take a look at lines IL_001a and IL_001f, for A2 look at IL_0020 and IL_0025.

.method private hidebysig static void  A1(class [Interop.WINSATLib]WINSATLib.CQueryWinSATClass q,
                                          string format) cil managed
{
  // Code size       122 (0x7a)
  .maxstack  4
  .locals init ([0] valuetype [Interop.WINSATLib]WINSATLib.WINSAT_ASSESSMENT_TYPE wat,
           [1] class [Interop.WINSATLib]WINSATLib.IProvideWinSATAssessmentInfo i,
           [2] class [mscorlib]System.Collections.IEnumerator CS$5$0000,
           [3] bool CS$4$0001,
           [4] class [mscorlib]System.IDisposable CS$0$0002)
  IL_0000:  nop
  IL_0001:  nop
  IL_0002:  ldtoken    [Interop.WINSATLib]WINSATLib.WINSAT_ASSESSMENT_TYPE
  IL_0007:  call       class [mscorlib]System.Type [mscorlib]System.Type::GetTypeFromHandle(valuetype [mscorlib]System.RuntimeTypeHandle)
  IL_000c:  call       class [mscorlib]System.Array [mscorlib]System.Enum::GetValues(class [mscorlib]System.Type)
  IL_0011:  callvirt   instance class [mscorlib]System.Collections.IEnumerator [mscorlib]System.Array::GetEnumerator()
  IL_0016:  stloc.2
  .try
  {
    IL_0017:  br.s       IL_0052
    IL_0019:  ldloc.2
    IL_001a:  callvirt   instance object [mscorlib]System.Collections.IEnumerator::get_Current()
    IL_001f:  unbox.any  [Interop.WINSATLib]WINSATLib.WINSAT_ASSESSMENT_TYPE
    IL_0024:  stloc.0
    IL_0025:  nop
    IL_0026:  ldarg.0
    IL_0027:  callvirt   instance class [Interop.WINSATLib]WINSATLib.IProvideWinSATResultsInfo [Interop.WINSATLib]WINSATLib.CQueryWinSATClass::get_Info()
    IL_002c:  ldloc.0
    IL_002d:  callvirt   instance class [Interop.WINSATLib]WINSATLib.IProvideWinSATAssessmentInfo [Interop.WINSATLib]WINSATLib.IProvideWinSATResultsInfo::GetAssessmentInfo(valuetype [Interop.WINSATLib]WINSATLib.WINSAT_ASSESSMENT_TYPE)
    IL_0032:  stloc.1
    IL_0033:  ldarg.1
    IL_0034:  ldloc.1
    IL_0035:  callvirt   instance string [Interop.WINSATLib]WINSATLib.IProvideWinSATAssessmentInfo::get_Title()
    IL_003a:  ldloc.1
    IL_003b:  callvirt   instance string [Interop.WINSATLib]WINSATLib.IProvideWinSATAssessmentInfo::get_Description()
    IL_0040:  ldloc.1
    IL_0041:  callvirt   instance float32 [Interop.WINSATLib]WINSATLib.IProvideWinSATAssessmentInfo::get_Score()
    IL_0046:  box        [mscorlib]System.Single
    IL_004b:  call       void [mscorlib]System.Console::WriteLine(string,
                                                                  object,
                                                                  object,
                                                                  object)
    IL_0050:  nop
    IL_0051:  nop
    IL_0052:  ldloc.2
    IL_0053:  callvirt   instance bool [mscorlib]System.Collections.IEnumerator::MoveNext()
    IL_0058:  stloc.3
    IL_0059:  ldloc.3
    IL_005a:  brtrue.s   IL_0019
    IL_005c:  leave.s    IL_0078
  }  // end .try
  finally
  {
    IL_005e:  ldloc.2
    IL_005f:  isinst     [mscorlib]System.IDisposable
    IL_0064:  stloc.s    CS$0$0002
    IL_0066:  ldloc.s    CS$0$0002
    IL_0068:  ldnull
    IL_0069:  ceq
    IL_006b:  stloc.3
    IL_006c:  ldloc.3
    IL_006d:  brtrue.s   IL_0077
    IL_006f:  ldloc.s    CS$0$0002
    IL_0071:  callvirt   instance void [mscorlib]System.IDisposable::Dispose()
    IL_0076:  nop
    IL_0077:  endfinally
  }  // end handler
  IL_0078:  nop
  IL_0079:  ret
} // end of method Program::A1

.method private hidebysig static void  A2(class [Interop.WINSATLib]WINSATLib.CQueryWinSATClass q,
                                          string format) cil managed
{
  // Code size       90 (0x5a)
  .maxstack  4
  .locals init ([0] class [mscorlib]System.Collections.IEnumerator e,
           [1] class [Interop.WINSATLib]WINSATLib.IProvideWinSATAssessmentInfo i,
           [2] bool CS$4$0000)
  IL_0000:  nop
  IL_0001:  ldtoken    [Interop.WINSATLib]WINSATLib.WINSAT_ASSESSMENT_TYPE
  IL_0006:  call       class [mscorlib]System.Type [mscorlib]System.Type::GetTypeFromHandle(valuetype [mscorlib]System.RuntimeTypeHandle)
  IL_000b:  call       class [mscorlib]System.Array [mscorlib]System.Enum::GetValues(class [mscorlib]System.Type)
  IL_0010:  callvirt   instance class [mscorlib]System.Collections.IEnumerator [mscorlib]System.Array::GetEnumerator()
  IL_0015:  stloc.0
  IL_0016:  br.s       IL_004f
  IL_0018:  nop
  IL_0019:  ldarg.0
  IL_001a:  callvirt   instance class [Interop.WINSATLib]WINSATLib.IProvideWinSATResultsInfo [Interop.WINSATLib]WINSATLib.CQueryWinSATClass::get_Info()
  IL_001f:  ldloc.0
  IL_0020:  callvirt   instance object [mscorlib]System.Collections.IEnumerator::get_Current()
  IL_0025:  unbox.any  [Interop.WINSATLib]WINSATLib.WINSAT_ASSESSMENT_TYPE
  IL_002a:  callvirt   instance class [Interop.WINSATLib]WINSATLib.IProvideWinSATAssessmentInfo [Interop.WINSATLib]WINSATLib.IProvideWinSATResultsInfo::GetAssessmentInfo(valuetype [Interop.WINSATLib]WINSATLib.WINSAT_ASSESSMENT_TYPE)
  IL_002f:  stloc.1
  IL_0030:  ldarg.1
  IL_0031:  ldloc.1
  IL_0032:  callvirt   instance string [Interop.WINSATLib]WINSATLib.IProvideWinSATAssessmentInfo::get_Title()
  IL_0037:  ldloc.1
  IL_0038:  callvirt   instance string [Interop.WINSATLib]WINSATLib.IProvideWinSATAssessmentInfo::get_Description()
  IL_003d:  ldloc.1
  IL_003e:  callvirt   instance float32 [Interop.WINSATLib]WINSATLib.IProvideWinSATAssessmentInfo::get_Score()
  IL_0043:  box        [mscorlib]System.Single
  IL_0048:  call       void [mscorlib]System.Console::WriteLine(string,
                                                                object,
                                                                object,
                                                                object)
  IL_004d:  nop
  IL_004e:  nop
  IL_004f:  ldloc.0
  IL_0050:  callvirt   instance bool [mscorlib]System.Collections.IEnumerator::MoveNext()
  IL_0055:  stloc.2
  IL_0056:  ldloc.2
  IL_0057:  brtrue.s   IL_0018
  IL_0059:  ret
} // end of method Program::A2

As the matter in fact, the explicit enumeration logic using a while-loop might look less elegant, but it makes the casting explicit which is otherwise introduced by compiler magic. By the way, don't worry about the try-finally block in A1 which doesn't provide us with more value, since System.Array isn't IDisposable. (Btw, if you really want to optimize somewhat, take q.Info out of the loop.)

Finally, implementing this as a console application just seemed wrong somehow; especially since he was still showing a windows form from the console app to demonstrate the ability to garner the Windows Vista generated image representing the base score.

I always intend to make things as simple as possible (cf. Einstein's famous quote mentioned in this post), in this case the console app just does the trick; everyone knows you can put the whole stuff in a WinForms app too in a completely similar manner. The score display was the only aspect that required WinForms and the orginal implementation just invoked the Save method on the bitmap to store it as a .bmp file, like this:

if (t != IntPtr.Zero)
   Bitmap.FromHbitmap(t).Save("WinSATDemo.bmp");

It would have been even shorter, I agree. Ultimately, I decided to use WinForms instead to display the picture. For me, the focus is on retrieving the numbers, not cloning what's already available in Windows to display the scores. Lots of WinForms code hide the real intention of the app in quite some cases. Anyway, just my .314 cents.

(PS: Sorry I had to delay the real technical post of today, but I felt I had to put a reaction online.)