Change in UMB allocation for DEVICEHIGH drivers when exceeding available upper memory in MS-DOS 6.22

Question

Goal: Identify the rule that MS‑DOS 6.22 uses to decide which DEVICEHIGH‑loaded device drivers remain in upper memory blocks when the total requested UMB space exceeds the amount available from EMM386.

Constraints/uncertainty: The placement varies with the order of DEVICEHIGH lines in CONFIG.SYS, the presence of LOADHIGH programs, the dynamic fragmentation of UMBs caused by hardware such as video BIOS or network adapters, and is not documented in the official MS‑DOS manuals. This makes the outcome appear intermittent across reboots or different machines.

Questions: What specific factors determine which drivers stay high versus fall back to conventional memory? Does the selection depend solely on the order of DEVICEHIGH directives, or are LOADHIGH allocations and hardware‑based UMB layout also involved? Can a predictable guideline be derived from CONFIG.SYS ordering and MEM /C output to guarantee consistent driver placement across boots?

Tasadduq Burney · Answer

Confirmed behavior
When the total UMB space requested by DEVICEHIGH lines exceeds what EMM386 can provide, MS-DOS 6.22 processes each DEVICEHIGH directive in the order it appears in CONFIG.SYS:

For each driver, DOS attempts to allocate a contiguous UMB block large enough for the driver.
  If sufficient UMB is available, the driver stays in upper memory.
  If the UMB attempt fails, DOS checks conventional memory (< 640 KB). If enough conventional RAM is free, the driver is loaded there automatically; no CONFIG.SYS change is needed.
  If neither UMB nor conventional memory can accommodate the driver, boot stops with an "Insufficient memory" error.

Likely influencing factors
The amount of free UMB at the moment each DEVICEHIGH line is evaluated depends on:

The current fragmentation of UMBs caused by hardware ROMs, video BIOS, network adapters, etc.
  Any previous LOADHIGH allocations (which occur after all DEVICEHIGH lines have been processed).
  Thus, while LOADHIGH and hardware layout change the free UMB pool, they do not alter the decision rule itself—each driver is still tried in CONFIG.SYS order against whatever UMB remains at that point.

Practical steps to obtain consistent placement

Run MEM /C after a clean boot and note the "Largest executable program size" and "Largest free upper memory block" values.
  Order DEVICEHIGH lines from largest to smallest (or as needed for priority) to give the biggest drivers the first chance at the limited UMB space.
  Place LOADHIGH lines after all DEVICEHIGH directives; they will consume any leftover UMB without affecting already‑placed drivers.
  Reboot and verify with MEM /C that UMB usage matches expectations and that conventional memory has not dropped unexpectedly.

If after these steps a driver still falls back to conventional memory, the missing diagnostic detail that would change the recommendation is the exact size of the largest free UMB reported by MEM /C before adding the driver. Knowing that value lets you confirm whether the driver truly exceeds the available UMB or whether fragmentation is the cause.

Change in UMB allocation for DEVICEHIGH drivers when exceeding available upper memory in MS-DOS 6.22

1 answer

Confirmed behavior

Likely influencing factors

Practical steps to obtain consistent placement

Your perspective belongs here.

1 question comment