Fixing HIMEM and EMM386 Conflicts in a FreeDOS Memory Configuration

Memory-manager failures can appear as hangs, reboots, corrupted displays, or applications that mysteriously lose conventional memory they should have available. Begin diagnosis with a boot option that loads no optional drivers at all, then add complexity back one layer at a time.

CONFIG.SYS supports multiple named boot blocks selectable from a menu at startup — build one with no memory managers loaded, then successive ones adding the XMS manager alone, then EMM386 (or JEMM386/JEMMEX) on top of that, then UMB loading, then your actual device drivers, one at a time. Testing at each stage isolates exactly which specific addition first introduces the failure, rather than trying to reason backward from a fully-loaded configuration that simply doesn’t boot.

The most common root cause: two managers claiming the same role

Confirm that only one XMS manager and one expanded-memory manager are active at once. Loading HIMEM.SYS twice, or an old EMM386.EXE alongside a newer JEMM386, produces exactly the kind of conflict this symptom describes — both drivers may partially initialize, each assuming resources the other has already claimed, corrupting rather than cleanly failing.

Why automatic UMB detection sometimes actively causes the problem

Hardware ROMs, network adapter option ROMs, and video memory shadowing can occupy specific upper-memory address ranges that a memory manager’s automatic scan incorrectly assumes are free. When that happens, the manager hands out a UMB range that’s actually in active hardware use, and whatever driver gets loaded into it corrupts silently or crashes outright. The fix is exclude ranges (X= on EMM386-family tools) specifically documented for your own hardware — not a range copied from an unrelated machine’s working configuration, since upper memory layout genuinely differs by video card, expansion cards installed, and BIOS shadowing behavior.

Verifying with MEM at every stage, not just at the end

Run MEM (or your memory manager’s own diagnostic display) after every single addition to the boot menu, and record conventional, upper, XMS, and EMS totals at each step. A steady, expected progression that suddenly drops or goes to zero at one specific stage tells you precisely which addition is the actual fault, which is considerably faster than troubleshooting a fully-configured system that simply won’t boot.

When different applications need genuinely different profiles

A DOS game requiring EMS access and a protected-mode application requiring a clean DPMI path with no EMS emulation running underneath it can have genuinely incompatible requirements — this is a real reason to maintain more than one working boot-menu profile rather than trying to force a single configuration to satisfy both. Optimize for maximum free memory only after you have at least one fully stable, working profile confirmed for each actual use case.

The single most common concrete error message you’ll actually see

“Unable to control A20 line” is the specific, well-documented error HIMEM.SYS produces when it can’t gain control of the A20 address line it needs for extended-memory access. Its two most common causes are loading a different memory manager or device driver ahead of HIMEM.SYS in CONFIG.SYS (denying it first access to the A20 gate), or HIMEM.SYS misidentifying which of several historical A20-handling mechanisms your specific machine actually uses. The documented fixes address each cause directly: reordering CONFIG.SYS so HIMEM.SYS loads first, or passing an explicit /M:n machine-type switch to bypass HIMEM’s automatic detection when it guesses wrong. The related /A20CONTROL:OFF switch instead tells HIMEM.SYS not to assume control of the A20 gate at all, useful specifically when some other driver has legitimately already taken responsibility for it. Related: FreeDOS Memory Management: Conventional, Upper, and Extended Memory · How to Set Up a RAM Disk on FreeDOS

Sources: