Brain Surgery, in a Rowboat, on a Rough Sea, with a Bread Knife

By: Grey Staples

Now that sounds like a challenge! Let's recast that absurd image into the real world of computers. A long while ago I was called on a data recovery assignment in which an old PC (8088 class) with a Stacked hard drive was not able to boot or read files on the Stacked, compressed drive.

The basic problem was that there were marginal sectors in the File Allocation Table (FAT), a critical control area, of the partition controlled by Stacker. What Stacker does is to create a "virtual drive" (D:) which really is a big physical file of say 20 meg on the actual "physical drive" (C:). Are you with me so far? When you boot the computer a "driver" program is loaded from Drive C: which allows DOS to think it is referencing a "real" Drive D:. But every request for data from D: is translated and mapped to a compressed sector in the big physical file. In order for Stacker/DOS to be able to complete a boot load it must be able to access the big compressed volume/file. This was the source of the problem. The important words here are "marginal sectors." Many sectors (512 byte blocks stored on the drive) would sometimes produce a "read" error, other times they could be read by the computer with no "errors" but would sometimes contain unreasonable data. Something was amiss. These errors appeared during the initial booting of the computer.

My "brain Surgery" image revolves around the need to apply fixes to the DOS critical areas (the FAT). I am literally performing surgery on the brain stem of DOS. Now the "row boat" and the "rough sea" images just amplify my problems in dealing with very transient results. One time there would be an error, the next time there was not a hardware error.

My problem was one of selecting the right tool for the repair. First I thought of SpinRite, since it can repair marginal sectors by saving the data and performing a "low level format" of the damaged area. Their Technical Support reported that an error in the FAT would cause SpinRite to terminate. They can't handle FAT errors. Next I tried Norton. Their latest version would allow me to identify the second copy of the FAT, which had no read errors, as an object, and then write the good copy over the one with errors. I have found in the past that simply writing to a marginal sector can "repair" it, (with a lot of luck). Unfortunately my only copies of Norton would not work on the 8088 computer at hand. New tools versus old computers.

Now to the "bread knife." The old standby DOS utility of DEBUG was the only crude, but effective tool available. I know you may have some favorite utility or shareware program which would be a natural for my problem. Maybe next time, but now my toolbox was almost empty, and I had to rely on DEBUG.

If DOS and BIOS can reference the marginal sectors, then DEBUG can work. First I had to locate the Logical Sector Number of the start of the first FAT area. By using the command "L100 3 1 80" I was able to locate the Logical Sector Numbers of the start of the first and second copies of the FAT. (As a technical aside the command tells DEBUG to read sectors from drive 3 (D:), put the data at memory location 100(hex), start at logical sector number 1, and read in 80 hex (128 decimal) sectors). I searched memory for the "F8" signature of the FAT and found both that I needed.

By using the "bread knife" of DEBUG, I was able to determine the size of the damaged FAT, the starting sector number of the good, second copy of the FAT, and the sector number of the start of the first copy. The undamaged second copy of the FAT was loaded into memory. The rest of the story was just a simple Write command to DEBUG to take the memory image of the second FAT and copy it over the marginal copy of the first. To do this you have to be ready to perform some basic addition and subtraction calculations in hexadecimal. At this point I would direct you to other references for a discussion of how to count on ten fingers and six toes.

Despite the levity of this story, the person with the "end of the world" problem was able to access their files on the damaged Stacked drive. They saved what they wanted and then did a "low level format" of the whole drive. Sometimes we are extremely lucky in the problems we find and the tools we have available.

Updated: 02-19-99 (9-5-2001 webstat)