Debugging a Windows Service is always a pain. You can’t run a service like a regular application, you have to run it from Windows Service Control Manager (SCM) and then have your debugger attach to the process while it’s running. The problem is that it’s difficult to debug problems with the service startup as the debugger can’t attach to the service in time.
I came across a tip on the .NET Tip of The Day site, “How to debug Windows Service startup”. Basically, you just add a line that calls Debugger.Launch() or Debugger.Break() in your startup code. When your code hits one of those lines, the Visual Studio Just-In-Time Debugger dialog will be invoked and you can select your debugger to handle the error. That will allow you to continue along in the code and debug until the cows come home.
That works better than a service debugging tip I posted a couple of years back, calling the Sleep API in your startup code to allow enough time to attach a debugger to the service. That was a hack, this is much cleaner.
All in all, I still prefer to separate the functional code from the service specific code. I can then run that code from a desktop app, making it much easier to debug. That works about 99.9% of time. Every now and then, I do need to run the actual service code and the Debugger.XXXX() calls will make that task much easier.
Various reports on the Intertubes are reporting that Microsoft has acknowledge that last weeks Vista Update, 938371, has been causing “problems” with USB devices. The money quote:
“We are aware of concerns that a recent Microsoft update may be causing problems with USB devices. We are investigating the matter, and at this time, do not have any information to share.”
Supposedly this was an update to fix a security hole in Windows Defender. Read about more people hit by 938371 in MS’s own forums.
This is starting to feel like an endless series of misadventures with 938371. See Work around for KB938371 disabling HID-compliant input devices , KB 938371 woes continue and the first post, Vista update KB938371 disabled my mouse.
I just want to know when a permanent fix will be available. Come on Microsoft, there is enough people reporting this problem that you should be able to reach out for more information to help diagnose and fix this problem.
There are times where you need to know what version of SQL Server is installed. Usually you want to know which version and which service pack has been applied. There have been a few isolated cases over the years where we saw bugs go away or significant performance boosts by merely installing the latest service pack. It’s less of an issue with 2005, but with SQL Server 2000, we wanted to make sure the user installed the latest service packs to block against stuff like the “Slammer” worm.
The following bit of T-SQL will send back the version information in easy to process pieces
SERVERPROPERTY(‘productversion’) AS ProductVersion, SERVERPROPERTY (‘productlevel’) AS ProductLevel, SERVERPROPERTY (‘edition’) AS Edition
For SQL Server 2005, you could get back something like this:
ProductVersion ProductLevel Edition
--------------- ------------- ----------------
9.00.2047.00 SP1 Standard Edition
Which indicates the Standard Edition of SQL Server 2005, with Service Pack 1 installed. You can also get most of that information with
But you would have to parse out the version from a block of text like this:
Microsoft SQL Server 2005 - 9.00.2047.00 (Intel X86)
Apr 14 2006 01:12:25
Copyright (c) 1988-2005 Microsoft Corporation
Standard Edition on Windows NT 5.2 (Build 3790: Service Pack 2)
Using SERVERPROPERTY (2000, 2005 or 2008) is much easier than parsing that block of text. To determine which version is running based just on the version number, Microsoft has a KB article that lists all of the releases under KB321185.