I wrote this primarily because the instructions for turning off Windows 98's automatic file scan on boot after a forced shutdown are not widely available. Windows 98 shutdown problems are widespread amongst those still using Windows 98. Many Windows users simply can't persuade Windows 98 to shut down properly. Fixing that problem generally proves to be a good deal more difficult than those who have not had to deal with a lot of non-identical Windows 98 PCs think. In fact, there is not just one shutdown problem. There are dozens of different shutdown problems -- some of which are very difficult to tame. The automatic file scan is not especially necessary and is really aggravating. So, along toward the end of this article, you will find step by step instructions for turning the file scan off.
The distant ancestor of Windows 98 is MSDOS. MSDOS is a fairly simple command line oriented operating system for MicroComputers. When you finish using MSDOS, you just turn the computer off. MSDOS version 5 or so, added a file caching scheme that meant (after some tinkering with delay times) that users had to wait a second -- rarely more -- before turning off the machine. This turned out not to be a problem despite reasonable concerns that it might be. Users almost invariably wait for disk activity to cease before turning the computer off.
Windows added a pretty graphical user Interface to MSDOS. Users were supposed to exit Windows before you turned off the computer. But since applications software for early versions of Windows crashed a lot and frequently took Windows with them, uncontrolled shutdowns were pretty common. Windows 95 was more reliable. It is designed to give you the impression that it needs a controlled shutdown ... but it usually doesn't really. A minority of users continued to just turn the computer off ... with few or no serious side affects.
Windows 98 like earlier versions of Windows doesn't really require a controlled shutdown unless it is actively writing a disk. But it added a new wrinkle. It runs pretty well usually. But fairly often, it won't shut down. Unfortunately, there isn't just one cause of failure to shut down. There are dozens of known causes. And a probably a bunch more that have never been identified. The good news is that as long as you wait for disk reading and writing to stop before turning the power off, Windows will generally survive OK. The bad news is that Windows is designed to chide you about failing to properly shut down then go through a very lengthy file checking process. If this process finds an error, the user is then asked what to do about it -- a question that 90% of them find pretty baffling. Most users with machines that don't shut down find this process to be really, really aggravating.
(The fact that 98% of computer techies think this is perfectly OK engineering, tells you a lot about why computers aren't easier to use).
In this article, I'm going to review fixes for some known Windows 98 shutdown problems, and also tell you how to kill the automatic file integrity check. I'll finish up with some background about why there is a problem at all.
This is really a special case of running a program that won't shut down. There are a number of ways that programs can be started. Here's a list.
If you routinely tweak your CMOS settings, by all means see if you can tweak them to fix shutdown. If you don't have a clue what CMOS is, I'd suggest that you leave it be. You are at least as likely to break something as you are to fix shutdown.
The above is more of a sampler than a complete list. As you can see, there is no single 'Windows Shutdown Bug' there is a whole hive of bugs with the same symptom.
These instructions will also work for Windows 95. I expect that they won't work for Windows NT, 2000, XP and probably not for Millennium. For the first three, you probably don't want to follow them anyway. For Windows Me ... who knows? Very few people use it as most system administrators prefer Windows 98 and/or 2000.
What you are going to do here is change a setting in a file called MSDOS.SYS. Most things in Windows are more easily done from the Graphical User Interface, but this is an exception. The file is hidden and marked read only. The default settings in Windows, hide part of its name. It's possible to deal with these peculiarities from the Graphical Interface, but it's not especially easy. Overall it is a good deal easier to change the setting from the command line and the instructions for doing so are a lot more concise. So, I'm going to tell you how to change it from the command line. If you are determined to change it from the GUI, feel free to do so.
Windows 9 uses a set of file systems know collectively as File Allocation Table (FAT) based systems. These are viewed with some contempt by many techies who fail to understand just how hard it is to maintain file system integrity in a typical home/small office environment using a sometimes unreliable OS with unreliable power sources. Basically, the FAT file systems maintain a large table called (surprise) the File Allocation Table. The FAT divides the disk into a multitude of small areas and specifies for each area used, where the next area to be used is. When things work right, the FAT on disk will be updated whenever disk allocations change.
There are a small number of things that can go wrong with the FAT. The most common fault is that an area will be marked as used, but the pointers to it will not be properly updated. The FAT system is designed to leave this situation if the system crashes or is turned off while in the process of updating disk information. It's a primitive version of a more sophisticated technique called journalling ... but with one important difference. In journalling, disk operations that were not completed are discarded on the next boot. In FAT, the failed transactions are hidden, but a time consuming disk check program (CHKDSK or SCANDISK) must be run to clean out the space allocated to the failed transaction. This is called "recovering Lost Clusters". There are a few other more serious problems that can occur. The most serious of these is a cross-link where the OS has allocated the same space to two different files.
Unless you manage to get all of the unused disk space allocated to lost clusters, recovering them is not urgent. I have managed to tie up all the disk space once or twice in two decades. You probably won't. However, cross links and some other rare errors do need to be cleared up as they can result in loss of data -- which is really annoying -- especially if it is a lot of data. Therefore, it is a good idea to run CHKDSK or SCANDISK or SCANDSKW occasionally. My recommendation is to run SCANDSKW from Windows from time to time. On a system with critical data (Why are you using Windows if you have critical data?) you may want to scan every day. For most users, a few times a year is plenty. I'm a lot more meticulous about backups than most people, but I only scan my disks every three months. If errors are frequently found, run the scan more often. And look into what errors are being found and why.
The disk scanning programs often give you an option of saving lost clusters as files. This made a lot of sense in 1983 when most PC users were computer savvy, and files were easier to understand. Back then, it was occasionally possible to salvage data that would otherwise be lost by doing so. The possibility of recovering the data has become progressively less likely over the years. My recommendation is that you simply discard any faulty data. Otherwise, you will need to actually look at the files you salvage and manually delete most of them.
If you actually understood the previous paragraph and feel that manually screening recovered files is worth the trouble, by all means do so. Otherwise, save yourself some trouble and select discard when you are given the choice.
Three disk verification programs are shipped with Windows 98. CHKDSK is an older MSDOS utility whose use with Windows is deprecated. It's kept around because some users have scripts that depend on CHKDSK's screen output of memory and disk usage information. SCANDISK is an improved (well, newer anyway) disk scanner that will run from MSDOS. This is the program used to do the Automatic disk scan. It is used in order to maximize the probability that disk problems are identified as early in the boot up process as possible. Since MSDOS requires many fewer resources than Windows, an MSDOS based disk scanner may work when a Windows based scanner wouldn't. Finally, there is a scanner that runs under Windows called SCANDSKW. It is slightly the most sophisticated of the three scanners, and is probably the best choice if you just want to check the disk(s) for integrity from time to time.
When you tell Windows 9 to shut down, messages are sent to all active processes telling them to shut down. They are then supposed to send a message back when they are finished. There are two things that can and do sometimes go wrong. First, you may not be able to get to the shutdown menu. This will happen if one of the key functions in the user shell (the thing that manages all those icons) has broken or is locked out. [And yes, Linux and Windows XP can have this problem also although it is much less frequent]. The second problem is that you can tell Windows to shut down and it can send out its messages, but the messages or replies never get to their destination. If so, Windows will wait forever. Ironically, the task preventing the shutdown probably will not be a task whose shutdown is important.
I'm not entirely happy with this article, so I'll continue to try to document known problems with Windows 9 shutdown. This is a low priority effort -- a few minutes a week.
If I ever find time, I'd like to look into whether it is possible (and not too hard, I'm not that great a programmer) to build a tool that will help in identifying why Windows won't shut down. For starters, here's a link to some basic information on Windows' internal message queue handling. http://msdn.microsoft.com/en-us/library/ms632590(VS.85).aspx
And here's some information on the shutdown messaging scheme http://msdn.microsoft.com/en-us/aa376890(VS.85).aspx [Note: Searching msdn for 'wm_queryendsession' may produce additional information.]