Recovering a FreeDOS System That Won't Boot After a Bad CONFIG.SYS Edit
You edited CONFIG.SYS, rebooted, and now the system hangs or won't load drivers correctly. Here's how to get back to a bootable state without reinstalling.
You made a change to CONFIG.SYS — added a device driver, adjusted memory settings — rebooted, and now the system hangs partway through boot, or loads but behaves incorrectly. Because CONFIG.SYS is processed line by line before COMMAND.COM even loads, a bad entry here can prevent the system from reaching a usable prompt at all.
Step 1: use interactive boot to step through CONFIG.SYS
FreeDOS supports pressing F8 during the boot process to step through CONFIG.SYS line by line, confirming or skipping each one individually:
Starting FreeDOS...
Press F8 for step-by-step confirmationThis lets you skip specifically the line you just added (or any line you suspect), while still loading everything else — the fastest way to confirm which exact line is the actual problem before editing anything.
Step 2: if F8 stepping gets you to a working prompt
Once you’ve identified the offending line (by skipping it and successfully reaching a COMMAND.COM prompt), boot again, skip that same line, and once at a prompt, edit CONFIG.SYS directly to fix or remove it:
C:\>EDIT C:\CONFIG.SYSComment out a suspect line with REM rather than deleting it outright while you’re still diagnosing — this preserves your original intent and makes it easy to re-enable once fixed:
REM DEVICE=C:\FREEDOS\BADDRIVER.SYSStep 3: if the system won’t even reach an interactive F8 prompt
For a more severe hang (the system stops responding before even offering the F8 prompt, or the boot process was interrupted mid-write leaving CONFIG.SYS corrupted), boot from a FreeDOS installation floppy or USB image instead, and edit the file from there:
A:\>EDIT C:\CONFIG.SYSBooting from separate install media entirely sidesteps whatever is preventing the main installation’s own CONFIG.SYS from processing correctly, since you’re running a known-good kernel and shell from the removable media instead.
Step 4: restore from a backup copy, if you kept one
The single best preventive habit for exactly this situation is copying CONFIG.SYS before editing it:
C:\>COPY CONFIG.SYS CONFIG.BAKIf you have a .BAK copy from before your edit, boot from install media (per step 3) and simply restore it:
A:\>COPY C:\CONFIG.BAK C:\CONFIG.SYSStep 5: rebuild a minimal CONFIG.SYS from scratch if all else fails
If the file is genuinely lost or too tangled to fix confidently, a minimal working CONFIG.SYS gets you back to a bootable, if unconfigured, system, from which you can re-add drivers and settings one at a time, testing after each addition:
DOS=HIGH,UMB
DEVICE=C:\FREEDOS\HIMEM.EXE
SHELL=C:\COMMAND.COM C:\ /E:1024 /PWhy testing incrementally matters going forward
The root cause of this entire class of problem is almost always adding or changing multiple CONFIG.SYS lines at once, then rebooting once at the end — when something goes wrong, you’re left guessing which of several changes caused it. Adding one DEVICE= line at a time and rebooting to confirm success before adding the next turns “the system won’t boot and I don’t know why” into “this one specific driver is the problem,” which is a dramatically easier thing to actually fix.