Error Reading Drive C:

This might move along a bit fast for you if you don't have much experience with basic DOS wrangling. I'm assuming that you already know about AUTOEXEC.BAT, and maybe Windows's SYSTEM.INI and such things. If the above title has the general effect of raising the hair on the back of your neck, then that's probably a sign that you are ready for this.

(Updated 2/9/1999.)

I was installing a Microsoft Mouse one of my Windows for Workgroups 3.11 computers. I plugged it in (while the power was turned off!), and booted up. I started Windows, and then File/Run a:setup.exe to install the new Microsoft Mouse drivers

Install procedure went normally and it came time to reboot. This is normal, because there are new drivers to load all around. Re-boot progressed until it stopped with

Error reading drive C:
Abort, Retry, Fail?

Uh? Maybe the hard drive was just having trouble getting up to speed after the re-boot? Try again. Nope. Power off for ten seconds. Uhhhh. Nope.

Uh, oh.

OK, now it's time to dig out my emergency boot disk. Boot from it. Good. Now I can function.

Finding Out What is Wrong

Change drive to C:. Change to \DOS where SCANDISK is. Start SCANDISK. The FAT (File Allocation Table -- the overall directory structure) checks good. Do I want to do a surface scan? (To test all parts of the hard disk.) Yes.

Bingo! SCANDISK had found honest-to-goodness bad clusters that were now being used by the new files that had been installed by the new mouse driver. Tell SCANDISK to repair the damage. The result of this repair is to mark the damaged sectors as bad, so that DOS (and Windows) won't attempt to ever use them. AND to copy the damaged data to a new location.

By this time, of course, any file that SCANDISK detected that was in a bad cluster was indeed toast. (If it was a text file, you MIGHT be able to see some of it, but anything executable should not be run.) So I write down on paper all the files so that I can later decide what to do about them.

OK. Several SCANDISK repair operations later I find that all the damaged files did belong to the new mouse driver. Apparently my hard disk had developed bad sectors that weren't detectable under normal usage UNTIL something was copied into those bad sectors.

Hmmm. Well, no particular good will come from trying to boot now, because autoexec.bat will try to load the mouse driver that is now trashed. Also, the mouse software also includes a file that Windows uses during its boot.

Try to get a Working System Back Again

Temporary fix is to first edit autoexec.bat and REM out the new mouse driver and insert a new line starting the old driver.


I knew from past experience that the original DOS mouse driver was c:\, and that anything that was in C:\MSINPUT\MOUSE\ must be new, and must belong to the new mouse software.

Remove the emergency boot diskette and then re-boot. YES! This time it boots into DOS and loads the old mouse driver. Start EDIT from DOS and see that the mouse cursor works. Good.

Then change to C:\WINDOWS, edit SYSTEM.INI. Hmmm.


Not good, but expected. Go to another Windows for Workgoups computer that doesn't have the new Microsoft Mouse software installed and see


Change system.ini on the sick computer to read


The semicolon "comments out" the line that would load the new (corrupted) MSINPUT.DRV file. The mouse=mouse.drv line re-establishes the original "stock" mouse software.

Start Windows. It comes up, and the mouse works like it always does. (Win 3.x will generally always function with the original stock mouse drivers with most brands of mice. You just don't have access to all the fancy mouse parameter adjustments that the newer software gives you.)

Complete the Repair

NOW re-install the Microsoft Mouse software, so that we will overwrite the now corrupted files.

Re-boot. Good. Everything works.


Not quite happy yet. Why did those bad clusters appear? It is possibly a sign that the hard disk is failing. So the first thing that I did after getting Windows running again was to do another SCANDISK surface scan, which found no additional errors. Good, so far. BUT the next thing that I did was to do a complete backup of the hard disk.

And I will do a SCANDISK surface scan every day for a while in order to see if this disk is indeed failing.

And I'll make more of an effort to keep separate copies of all the Windows .INI files, so that I have something to compare with when I attempt to install something new and a problem develops.

Addendum. Several days later, I had a reoccurrance of the same problem, so it looks like that hard drive really is failing. I have a spare hard drive, so it is only a minor problem. Bummer, nevertheless.

Actual hard drive failures like this aren't that common. Most of the "computer crash" problems that you will actually have will be because of software problems. Oh, well--stuff happens.

Good thing that I had a backup!

2/9/1999 Update

One year later. I got a copy of Spinrite, which is the best disk testing program on the market. I had another WFW 486 opened up, so I decided to temporarily put this drive in and test it with Spinrite.

Spinrite found a lot more bad sectors, but none were unrecoverable. OK. However, I tested it again the next day and the bad sectors moved around and this time, Spinrite found several unrecoverable errors.

Even though this drive is still toast, Spinrite is still a lot better than Scandisk, because it does more extensive testing, and has a pretty sophisticated method of trying to recover data from unreadable sectors. Even though my drive is beyond hope, the odds of saving data from a "bad" disk are a lot better when you use Spinrite.

You can get Spinrite from