Debugging a Service on Vista with VMWare Virtual Debugger

Note to self about using the VMWare Visual Studio Integrated Virtual Debugger to attach to a service running on a VMWare Vista guest OS --

If you get the message similar to "Failed to attach to process" as below:

Don't forget to do the following in the Vista guest OS:

1. Turn off firewall
2. Add logged in user to Administrators group
3. Disable User Account Control (UAC) by clicking "User Accounts" on the Control Panel, typing "user" in the search box and then clicking "Turn User  Account Control (UAC) on or off".

Fool me once shame on you Vista, fool me twice  shame on me -- I should have written this down the first time!

Taxonomy of Exceptions

Eric Lippert offers an interesting taxonomy of exceptions:

Fatal exceptions are not your fault, you cannot prevent them, and you cannot sensibly clean up from them.  [...]

Boneheaded exceptions are your own darn fault, you could have prevented them and therefore they are bugs in your code. [...]

Vexing exceptions are the result of unfortunate design decisions.  [...]

And finally, exogenous exceptions [...] are the result of untidy external realities impinging upon your beautiful, crisp program logic.

When I worked on DevPartner Fault Simulator (now unfortunately discontinued) we dealt with understanding these kinds of exceptions both in code Fault Simulator analyzed and in our own code.

As Eric points out,  writing good error handling code is hard in any language, whether you have exception handling or not.  I see far to much code that either simply ignores return values or overly aggressively catches exceptions.  Eric's taxonomy is a useful way to think about how your code should handle (or not) error conditions.

Go Large Hadron Collider, Go!

I've got to say, I think today's Google homepage image is awesome!

Help Firefox set a Guinness World Record

The First Rule of Programming : It's Always Your Fault -- A Corollary

Jeff Atwood, on the CodingHorror blog, recently posted about taking ownership of your code by way of always assuming a problem is your fault:

No matter what the problem is with your software-- maybe it's not even your code in the first place-- always assume the problem is in your code and act accordingly. If you're going to subject the world to your software, take full responsibility for its failures. Even if, technically speaking, you don't have to.

I'll add just one more bit of advice:

Assume that it's the last thing you changed that caused the problem.

(Source control systems make it relatively easy to find the breaking change by allowing you to progressively fetch earlier versions of the source code.  I usually employ a binary search technique that lets me close in on the breaking change pretty quickly.)

MIDL error: 'annotation'

Recently, after upgrading Visual Studio 2005 Professional to Visual Studio 2005 Team Suite (1) I received these errors when building:

unknwn.idl(108) : error MIDL2025 : syntax error : expecting ] or , near "annotation"
unknwn.idl(108) : error MIDL2026 : cannot recover from earlier syntax errors; aborting compilation

This post has some advice that I suppose would have worked.  However, I found that opening the SDK command prompt and running 'vcintegrate' worked just as well.

Follow these steps:

1. Start->All Programs->Windows SDK->CMD Shell
2. cd setup
3. vcintegrate -i

-----------------------------------------

(1) I just installed the latter over the former.  Perhaps I should have uninstalled Visual  Studio 2005 Professional first.

Programming Language Cheat Sheets

Here's a really useful thing -- a list of cheat sheets for various programming languages like C++, C#, Ruby, etc. I only which there was a cheat sheet for F#.