Beach blog

I just got back from a week at the beach. Each morning I grabbed my laptop and bopped off to the internet cafe with Doria to have a latte and make sure we weren't missing something in our email that might change our lives. Part way through the week, I accepted an automatic Windows update. When I rebooted, the computer bluescreened. Every time I rebooted, the computer bluescreened. But it booted up fine in Safe Mode, giving me confidence that the problem had to do with software, not hardware. Indeed, as I stepped it through boot failure about ten times, I noticed the name of the file causing the problem was displayed ever so briefly on the blue screen before it vanished. I found the file in c:\windows\system32\drivers, and renamed it. The computer now booted happily, but I discovered that the wireless had become inoperable. Googling by name for the removed driver, (using another computer), I discovered that it was indeed a driver distributed with my wireless pcmcia card, and has been causing other users trouble with the latest Windows patches. I took the newest version of this file from the vendor's website, and lo! the computer boots again and has wireless access. What is the moral of this story? I needed to find one because I was going to get back from vacation and need material for a blog entry. First I considered using it as fuel in my ongoing dispute with Raven, our network administrator. She's adamant that we should all be taking the latest automatic Windows updates as they become available, that she cannot maintain the network if everyone has different patches installed. But I'm always afraid -- because it's happened two or three times -- that one of the updates will stop me in my tracks. As it did over my latte this morning. So I always avoid taking them. But on reflection, it's not much of an argument - the OS has got to win over apps meant to run on it, and indeed an updated release of the app was ready and waiting for me. So while it is possible a Windows update can cause a problem, its probably best to take it and debug any problems later. Then I thought, let's use this in my ongoing thread on problem solving. After all, this was your typical near disaster that illustrates the zen of computer problem solving. And it illustrates several of Michael's Problem Solving Rules. (1) Your problem is probably caused by the last thing you did. (2) Your new problem was probably caused by fixing the old problem. (3) If you do not know how to fix your problem, watch it blow up over and over again. (4) Someone else has probably had this problem. Ultimately, though, this story gets back to the thread about managing pc failure - how do you set policies in place to minimize the effort to get one of your users back up and running when their pc becomes inoperable? Especially laptops, which are so rarely attached to the company network. Fortunately, I did not need to reinstall Windows, replace my hard-drive, or aim a fire extinguisher at my flaming keyboard. But it's all happened before and it will happen again. Backup is only a part of the solution. Making your deskops as interchangable as possible for the general user is the key to solving this problem. But what can you do for your prima donna developers? Tags: nptech, beach