INT 21h function 48h allocation failure (AH=4B) leaves allocated block unfreed after abnormal termination

Question

When a DOS program uses INT 21h AH=48h to allocate a conventional memory block and then terminates abnormally (e.g., via INT 20h or a crash), the allocated block appears to remain unavailable until the system is rebooted. The DOS memory manager does not keep per‑program allocation records, and there is no documented API to query or release memory that was allocated by a previous call to function 48h. The goal is to understand whether any documented behavior or undocumented mechanism exists to reclaim such leaked blocks without a full reboot, and under which termination conditions the leak occurs.

Considering the constraints of the original DOS memory model and the lack of a release function for INT 21h 48h, what options, if any, are available to developers or system administrators to recover the lost memory? Are there specific DOS versions, memory managers, or utilities that can detect and free orphaned blocks? Finally, does invoking INT 21h AH=4Ch instead of INT 20h guarantee the release of allocations made with function 48h across all compliant DOS implementations?

Tasadduq Burney · Answer

Memory Recovery for INT 21h AH=48h
There is no documented DOS API or built-in mechanism to reclaim memory allocated via INT 21h AH=48h once the allocating program has terminated. Because the DOS kernel does not maintain a per-process allocation table for conventional memory, these blocks remain marked as "occupied" in the system memory map until the machine is rebooted.

Termination Behavior and Leaks
Neither INT 20h nor INT 21h AH=4Ch (Terminate with Return Code) provide automatic cleanup for blocks allocated with function 48h. While AH=4Ch handles the closing of open file handles and the release of internal DOS buffers, it does not track or free conventional memory blocks. Consequently, any program that terminates abnormally or fails to call INT 21h AH=4Ah (Free Memory) will cause a permanent leak for the duration of the system session.

Recovery Options
For developers and administrators, the options for recovery without a reboot are extremely limited:

Manual Memory Map Manipulation: Some low-level system utilities can modify the DOS memory map to mark blocks as free. However, this is dangerous; if a block is incorrectly marked as free while still being used by a resident program (TSR), the system will likely crash.
  Memory Managers: Advanced memory managers (like QEMM or EMM386) manage extended and expanded memory, but they generally do not track the ownership of conventional memory blocks allocated via standard DOS interrupts.
  Preventative Coding: The only reliable solution is to implement strict exception handling or use a "wrapper" that ensures AH=4Ah is called before any exit path.

Verification Method
To verify a leak in a specific environment, you can use the following test pattern:

Run MEM /C (or a similar memory monitor) to record the current available conventional memory.
  Execute a program that calls INT 21h AH=48h and terminates via INT 21h AH=4Ch without calling AH=4Ah.
  Run MEM /C again. A decrease in available memory confirms the leak.

Diagnostic Note: Please specify if you are using a specific DOS extender (like DOS4GW) or a protected-mode environment, as these may implement their own memory tracking that overrides standard DOS behavior.

INT 21h function 48h allocation failure (AH=4B) leaves allocated block unfreed after abnormal termination

1 answer

Memory Recovery for INT 21h AH=48h

Termination Behavior and Leaks

Recovery Options

Verification Method

Your perspective belongs here.

0 question comments