Most common cause of a "can't run" is insufficient free space on the disk. Defrag requires at least 10%(?) free to run on Win98, and more with some other Win versions. (The 10% is a vague recollection.) The more fragmented the disk is, the more free space is needed, so any "minimum" is a pretty loose guess. Sometimes you can move a few files off to get room to defrag, and then move them back and still get a rerun of defrag, since the contiguous free space after the first defrag is "more usable."
General -
The Microsoft "answer" on this is that other programs may interfere with scandisk and/or defrag, but there is a little more to it than that. They don't tell you that defrag itself may make disk changes that require it to restart - at least in any of their articles that I've found.
IF you do happen to have a particular program that interferes, it can slow things down drastically, and you should shut off the interfering progam(s), or defrag in Safe Mode. If you've found an improvement doing it that way, it just means that you probably do have some other program that intrudes. Most of the programs that people have "blamed" do affect defrag, but often not to the extent claimed.
Even with nothing except defrag itself running, you may still get the "something writing to disk" notice, since defrag itself can write stuff to the disk that requires it to restart on a FAT32 drive.
The key here is that the "Volume Index" (VI) used in place of the "File Allocation Table" on FAT32 drives does not have a fixed length like the simpler FAT did with FAT16 (or FAT12) drives. Unlike FAT16, the VI is not required to be the first thing on the drive, but in practice it always is (2 copies), after boot sector data. Much of the information that can be included in the FAT32 VI is "optional," and quite a lot of it may be added only when defrag tries to clean up the disk. In addition, file locations may be recorded as "relative offset" in addition to "absolute addresses."
When defrag finds something that it "needs to add" to the "Volume Index," the size of the VI can change, and this means that all the "relative addresses" - distance from the data in VI - have to be corrected, and all subsequent data has to move to make room for the change in VI size. When it writes the new information into the Volume Index, that is a "restart required" write-to-disk.
Once the VI is "defragged" on the first pass, the "first file" is written immediately adjacent (to the second copy of the VI). If the size of the VI changes, everything that comes after it has to be moved, which can "fragment" the subsequent data so that the "defrag" of everything that comes after it has to be redone. (If the defrag program had been set up to leave a "gap" or some "loose space" at the end of the VI, the restart problem probably would not occur, or at least wouldn't be as frequent.)
If you turn on the "view disk map" in Win98 during defrag, you can see where (approximately) on the disk the utility is doing its thing. You'll see it work up to a certain point, make a change, start over. It will work past that first point (usually) until it finds something else that requires a change. When it starts over, it will again (usually) stop at the same "first stop" location, make a change, and start over. The next time through it may pass the second "stop" but will eventually hit another place where it has to write a change, and will start over. If the 3d change affected the VI size enough, it may have changed data for the 2d "stop," and it's already been shown that the change at the 2d stop affects the first stop - so everything has to repeat from the beginning.
In somewhat oversimplified terms, when defrag finds the "last change," that last change may affect the VI size, which means that everything up to it may have to be redone. i.e. defrag is half finished.
In later versions, you don't have the option of watching the disk map during a defrag, but something of the same sort may go on. Defrag in later Windows versions is, fortunately, a lot more efficient.
In Win98, you have a choice of two methods of defrag. You can choose the "simple" method where the files are just written - without gaps - in whatever order they appear. You can also allow defrag to attempt to sort things so that "frequently used" files are placed where they can be found more quickly, and "files used together" are placed near each other. For an initial defrag of a badly scrambled drive, the simple sort may be quicker; but subsequent "simple sorts" may not improve much if a file that gets frequently modified is early on the disk. In simple mode, something is moved to make room to defragment the first file, and the all subsequent files have to be moved to fill in the gaps - unless or until there's a big enough "blank" space that happens to "fit" what defrag puts there.
If you allow the "sorted" defrag, the initial defrag may take longer; but you often will see an improvement in time required once the disk is "sorted out." Note that it may take several defrag passes before the time improves significantly.
The size of your drive has some effect on how long a defrag will take. Many Win98 machines are set up with 8 GB or smaller partitions, because that's all Win98 could read without overlays. 80 GB is a fairly small partition for later versions of Windows, and >300 GB drives are not too uncommon now. The problem is somewhat less severe with larger drives, simply because the cluster size may be much larger so defrag can make more changes within the "cluster slop" without having to move subsequent stuff on the drive. Of course, the larger drive can contain a lot more files that have to be handled.
The problem pretty much goes away with WinXP and NTFS format for the hard drives. It shouldn't be much of a problem with WinXP even if, for some reason, you're forced to use FAT32 disks. Because the "normal" defrag in WinXP or Win2K defrags the files but usually leaves some "fragmented white space," there's more room to move files around without the "restart" problem arising.