This is a bit off the topic, too, but I'm running a time consuming process on two other machines right now...
I run a web server in my basement on DSL. Over the weekend I decided to finally upgrade the 80 GB hard disk that had been spinning practically non-stop for 18 months with a shiny new 160 GB disk. Seagate provides a copy utility that runs under windows, so I rebooted in Safe Mode (assuring that virtually all my services were shut down), ran the copy, shut down, pulled the old drive, strapped the new one as a master, and rebooted.
Everything came right up. Except for SQL Server. My website is a derivative of I Buy Spy, so I basically had nothing showing. I tried to manually start the SQL Server service and was ever so pleased to see the error message "Cannot start service. Error 3: File not found." Just which file is left as an exercise for the reader. My Event Log displayed the exact same error.
I searched Google for "SQL Server" and "File Not Found" and got plenty of hits, but no help. I opened the Service manage, stared at the properties of the SQL Service, and noted the name of the exe it launched. I thought if I ran it manually I might get more info. I located it, double clicked it, and it opened a command window and announced that it was opening files, starting this and that, and trying to log in as the disabled "guest" account. It seemed to run fine. Hmmm.
Then I looked more closely at the path to the exe. It pointed to binn in the Microsoft SQL Server directory in Program Files, but the pat used the short versions; .../PROGRA~1/MICROS~2/... An inspiration struck. I used "dir /ad /x" to look at the short names of my program file directories, and indeed, Microsoft SQL Server's was different!
I used RegEdit to locate and change the nasty string, and SQL Server came right up! A happy ending at last. And the moral of this story is: don't store paths in short name format. All your testing may not uncover a single problem, but you can create some hideous problems for your users.