Skip to content
FreeDOSFix Published Updated 3 min readViews unavailable

Fixing DPMI and Protected-Mode Memory Errors on FreeDOS

A diagnostic path for missing DPMI hosts, linear-memory exhaustion, page faults, invalid selectors, swap files, extenders, TSR conflicts, and bad RAM.

“No DPMI,” “insufficient memory,” “page fault,” and “invalid selector” describe different failure classes. Loading another memory manager or increasing a swap file can repair a missing resource, but it cannot repair an application that dereferences an invalid pointer. Preserve the exact message and register dump before changing the environment.

Identify the executable’s runtime

Determine whether the program uses DJGPP/CWSDPMI, DOS/4GW, DOS/32A, CauseWay, Windows DPMI, or another extender. Look for an embedded stub, adjacent host executable, documentation, and version strings. Do not place several hosts in PATH and hope the correct one wins.

DJGPP’s documented message Load error: no DPMI - Get csdpmi*.zip means it did not find a DPMI server. On plain FreeDOS, place the compatible CWSDPMI.EXE where the DJGPP stub expects it—commonly beside the program or in a clean PATH—and use the version recommended by the application/toolchain.

PATH C:\DJGPP\BIN;C:\FREEDOS\BIN
CWSDPMI -?

The exact options differ by release. Do not manually start a host if the program’s stub loads it automatically unless its documentation requires that mode.

Separate conventional, XMS, and DPMI linear memory

MEM /C /P

Conventional-memory shortages affect DOS buffers, stubs, environment, and real-mode callbacks. XMS supplies extended memory to many hosts. DPMI linear memory can include physical RAM and host backing store. A large “free XMS” number does not guarantee the host can allocate descriptors, contiguous DOS blocks, locked memory, or swap space.

Test a clean profile with one XMS manager, no EMM386 unless required, no disk cache, and no unrelated TSRs. Then reintroduce components one at a time. Some applications require VCPI/EMS; others conflict with it. The application’s manual, not a universal memory recipe, decides.

Treat DPMI error codes literally

DPMI 1.0 defines codes such as descriptor unavailable (8011h), linear memory unavailable (8012h), backing store unavailable (8014h), invalid selector (8022h), invalid handle (8023h), and invalid linear address (8025h). A 0.9 host may only reliably signal failure with Carry and not provide a meaningful standardized code.

Resource errors justify checking host limits, disk free space for swap, file permissions, descriptor leaks, and competing clients. Invalid selector/handle/address points first to application misuse, corruption, version mismatch, or bad memory—not to an arbitrary larger swap setting.

Preserve page-fault evidence

CWSDPMI/DJGPP can print exception type, EIP, error, registers, and stack information. Save it exactly. For a program you build, keep the matching unstripped executable/map/symbols and use the toolchain’s SYMIFY or debugger workflow. Symbols from a different build can name the wrong function.

A page fault reading or writing a null/uninitialized pointer is an application bug. The DJGPP FAQ explains that CWSDPMI can expose invalid accesses that another host happens not to catch. Disabling null protection may hide the symptom and corrupt data; fix the program or obtain an updated build.

Check swap and storage without sacrificing the disk

Some DPMI hosts use a swap file. Confirm its configured path, free space, FAT file-size limit, and writable directory. Put it on a healthy local disk, not a nearly full floppy or removable media. A failed write, fragmented/damaged filesystem, or 4-GiB FAT limit can look like virtual-memory exhaustion.

Do not run filesystem repair against the only disk during diagnosis. Image it first if corruption is suspected.

Rule out hardware and emulator differences

Run a trusted memory test outside FreeDOS when crashes move between addresses. Disable CPU overclock/cache experiments. In a VM, record CPU core, memory size, DPMI/EMS settings, and emulator version; protected-mode edge cases vary.

Acceptance means the same executable survives repeated representative workloads, reports stable memory use, exits cleanly, and leaves no host/TSR state behind. Keep the clean profile and exact working runtime beside the application. A protected-mode crash becomes fixable when its host, resource class, and fault address are known.

Related:

Sources:

Comments