Fixing Missing DOS Drive Letters Caused by LASTDRIVE and Driver Ordering

DOS assigns letters through internal drive structures created at boot and extended by block drivers, CD redirectors, RAM disks, network mappings, and substitution tools. If a driver says no letter is available—or a new CD/USB/RAM disk never appears—the limit may be LASTDRIVE, but the same symptom can also mean the hardware driver did not load.

Inventory letters and layers

Record FDCONFIG.SYS/CONFIG.SYS and FDAUTO.BAT/AUTOEXEC.BAT before editing. List existing drive letters and use the FreeDOS DRIVES utility when installed:

DRIVES
MEM /C /P

Note physical partitions first, then CONFIG.SYS block drivers, CD-ROM hardware drivers, SHSUCDX/MSCDEX-style redirectors, RAM disks, network redirectors, SUBST, and ASSIGN. A device driver can load successfully yet its redirector fail later, so preserve both boot and command output.

Understand the CDS table

DOS maintains a Current Directory Structure entry for each available letter from A: through the configured last drive. Each valid block device also has a Drive Parameter Block describing media and filesystem details. The total CDS capacity is fixed during boot; it cannot be enlarged interactively afterward.

FreeDOS chooses a default high enough for detected floppies and hard-disk partitions plus an additional device, but it cannot predict every later CD, USB, RAM, or network drive. LASTDRIVE sets the final permitted letter:

LASTDRIVE=Z

LASTDRIVEHIGH attempts to place the table in upper memory and requires an appropriate memory manager. Setting the value higher consumes a small amount of memory per extra entry, so Z is convenient but not free on an extremely constrained 8086 setup.

Prove the hardware driver loaded

For a CD-ROM, the CONFIG.SYS driver publishes a device name such as MSCD000; SHSUCDX or MSCDEX later maps that exact name to a drive letter. A spelling mismatch is not LASTDRIVE exhaustion.

DEVICE=C:\FREEDOS\BIN\GCDROM.SYS /D:MSCD000

SHSUCDX /D:MSCD000

Capture driver errorlevels and messages. For USB storage, confirm the USB host/controller and disk driver detected the device before expecting a letter. For a RAM disk, verify enough XMS/EMS and a valid requested letter.

Check explicit collisions and ordering

A driver may request a fixed letter already used or above LASTDRIVE. Others take the next free letter at load time, so boot order changes assignments. Network login scripts and SUBST can consume letters after local devices start.

Create a written allocation plan, for example local disks first, optical drives next, RAM disk, then network mappings. Use each tool’s supported explicit-letter option where stable assignments matter. Do not use ASSIGN as a substitute for a missing block device; it remaps names and can make diagnosis more confusing.

Change one boot profile safely

Add a temporary menu profile with a higher LASTDRIVE and the minimum relevant drivers. Boot it, run DRIVES, and compare memory. If the device still does not appear, revert the limit and debug the driver/redirector path.

When upper memory is stable, test LASTDRIVEHIGH, but keep a conventional-memory fallback. Loading the table high before the UMB provider exists cannot work. The FreeDOS help also notes that driver order affects available upper memory.

Verify media before writing

When the letter appears, inspect it read-only first. Removable-media caching and stale DPB state can be dangerous if disks change. Confirm capacity, FAT type, volume label, and expected files. Never format a newly visible letter merely because DOS asks or reports unknown media.

Reboot twice and verify consistent letters, applications, CD access, RAM disk lifecycle, network mappings, and free conventional memory. The fix is complete when every driver and redirector has a documented letter and the clean recovery profile remains bootable—not simply when LASTDRIVE=Z masks an unknown ordering problem.

Related:

Sources: