Tiny Code

Tiny Code

Sunday, May 3, 2009

Windows strikes again

Despite the fact I made the switch to a Mac about 6 years ago, Windows still manages to be a thorn in my side from time to time. Yesterday morning my wife discovered that her XP laptop which had been working Friday night had decided not to boot. What was even more entertaining was it decided to display a completely blank screen so there was no clue what was causing the boot to fail. What's even more disturbing is this is the second time I've seen these same symptoms.

I poked around a bit after booting the system under Linux using a System Rescue CD. That allowed me to see which files had been added or modified since the last full backup a month ago. To do so, I had to issue a few Linux commands.

Here's the command to mount the Windows NTFS file system on the /mnt/windows mount point.

ntfs-3g /dev/sda1 /mnt/windows

Here's the commands to mount an external USB disk containing a Windows FAT32 file system on the /mnt/usbdisk mount point. Note that you have to create the mount point first. Also note that the device name of the USB drive may be different than /dev/sdb1. You can figure this out by issuing the command "ls -l /dev/sd*" before and after connecting the USB disk. The device name which appears after connecting the disk will be the correct one.

mkdir /mnt/usbdisk
mount -t vfat /dev/sdb1 /mnt/usbdisk

Here's the command to show you the files which have a later modification date than the last backup. This will give us an idea of what files need to be backed up before we perform any potentially destructive operations to the old disk.

find /mnt/windows -newer /mnt/usbdisk/backup -print

Once I did this, I had a quick look at the partition table/MBR to see if that might be the cause of the failure to boot. That required dumping sector 0 via a program which can display binary data in hexadecimal form. The xxd command will display hexadecimal equivalents for binary data and we can use the dd command to copy the first sector to xxd. Here's the command I used.

dd if=/dev/sda1 count=1 | xxd

A cursory glance indicated the partition table looked okay. It ended with the required 0xaa55 (since PCs are little endian this appears as 0x55aa when viewed as bytes).

I verified the rest of the files involved in the early portion of the XP boot process appeared to be present and had a reasonable size and time stamp. All appeared fine.

Now I was almost ready to try to fix the problem. Since this involved issuing some potentially destructive commands, I booted from the Acronis True Image CD to create a new "since save" backup of the data which had changed since the last full backup.

First I tried booting into the XP Recovery Console to issue the fixmbr command. Sadly, that didn't fix the problem. It did issue some stern looking warnings about the drive having a nonstandard partition table. Since I had used Windows to set up the disk, I found this very irritating. Why would Windows use a partitioning scheme which it would later declare to be nonstandard, especially when the default method is chosen? By this point, there aren't many of Windows' quirks which surprise me. They do make me all the happier that I deal mostly with MacOS and Linux these days.

I also tried an XP Repair Installation. Strangely enough that didn't change the boot failure symptoms at all.

What finally fixed the problem? Doing a full restore with Acronis True Image followed by a restore of the Acronis "since save" data. I may be completely disillusioned with Windows but Acronis makes a very nice product. I don't think I'd consider running Windows without it.

No comments: