wyDay blog

Over the last couple of months I've gotten a surprising number of questions asking about the same thing: how to debug a Windows Service like you would debug a normal Window Forms application. There are lots of hacks to pseudo-debug a Windows service like running your code from a console, or even adding a massive amount of logging throughout your code.

But what if you need to run your Windows Service as it normally runs (i.e. as an actual service) in order to track down bugs?

The good news is that's there's a little snippet of code to make debugging Windows Services a snap. The first thing to do is to add the following DebugMode() function to your app:

C#

/// <summary>Helper function to attach a debugger to the running service.</summary>
[Conditional("DEBUG")]
static void DebugMode()
{
    if (!Debugger.IsAttached)
        Debugger.Launch();


    Debugger.Break();
}

Visual Basic .NET

''' <summary>Helper function to attach a debugger to the running service.</summary>
<Conditional("DEBUG")>
Shared Sub DebugMode()
    If Not Debugger.IsAttached Then
        Debugger.Launch()
    End If


    Debugger.Break()
End Sub

When you call the newly added DebugMode() function within your Windows Service, if there isn't already a debugger attached to your service it gives you the option of adding a debugger:

Now you can debug your service like you would a Windows Forms application. Also, because you're using the [Conditional("DEBUG")] attribute on the DebugMode() function when you compile your service in "Release" mode all the calls to the "DebugMode()" function will be removed.

Pretty cool, huh?

After two years of writes and re-writes, I'm finally releasing InstantUpdate 1.0 Release Candidate. Aside from the heap of fixes, some of the notable features are:

• Full Windows Vista compatibility
• Overhauled designer and client interfaces
• Uploading your updates within the designer
• Entirely re-written update engine which includes, among other notable enhancements, restoring your software to the previous state (registry and files) if an error occurs or if the user cancels the update
• Ability to update on non-administrator accounts

What are the system requirements?

The requirement for the both InstantUpdate Designer and Client is the .NET Framework 2.0. This is included with Windows Vista right out of the box, and is available for download on Windows Update for Windows 98, 2000, and XP. So, the ideal user of InstantUpdate is someone who programs in one of the .NET languages (C#, VB.NET, etc.) or someone who's programming solely for Windows Vista.

Documentation and forum

Also, some documentation is now online - the content ranging from simple instructions on how to distribute the InstantUpdate client, to more advanced topics like the version numbering system used in the client. I will expand the help topics when I get closer to releasing the final version of InstantUpdate. If you have any questions, comments, bug reports, or otherwise, take advantage of the forum.

Speaking of the forum, you no longer need to register to post a message. I know how much of a pain in the ass it is to sign up for forums, so I removed the requirement altogether. Of course, if you do register in the forum you'll have greater control over your posts (upload files, edit posts, etc.). But, like I said, it's no longer a necessity.

I hope you enjoy using the release candidate of InstantUpdate.

Download InstantUpdate now.

Comment on InstantUpdate Release Candidate.