FreeDOS STACKS: Sizing the Hardware-Interrupt Stack Pool
Learn what FreeDOS STACKS and STACKSHIGH configure, how interrupt-stack exhaustion differs from an application stack bug, and how to test safely.
FreeDOS STACKS= is a kernel startup setting for extra stacks used while handling hardware interrupts. It is not a request to enlarge every program’s stack, and it is not a generic cure for any crash containing the word “stack.” Increasing it without first identifying the failure can spend scarce conventional memory while leaving the real defect untouched. The FreeDOS help says standard installations do not normally need an explicit STACKS command, so treat it as a compatibility control for a demonstrated workload rather than a routine optimization.
The documented form is STACKS=nn,mmm, where nn is a count in the range 8 through 64 or zero, and mmm is a per-stack size in bytes in the range 32 through 512. FreeDOS also documents STACKSHIGH as an attempt to place these stacks in high memory first, falling back to conventional memory when necessary. The exact pool behavior belongs to the installed kernel build; record that build when diagnosing a machine.
Interrupt stacks and program stacks are different resources
An application has a CPU stack used for return addresses, local data, and interrupt call frames. A TSR may maintain its own stack for callbacks. DOS and its device/interrupt pathways also need stack space while responding to hardware events. A hardware interrupt can arrive while a program is executing, and the operating system may need to switch to a controlled stack context to service it safely. STACKS= configures the DOS-side interrupt stack supply described by the FreeDOS directive documentation; it does not resize the application’s SS:SP region or repair a corrupted return address.
This distinction changes the diagnosis. If only one executable overflows during deep recursion, inspect its compiler model, stack reservation, and call depth. If the system reports an internal DOS stack overflow during disk or serial activity across multiple programs, investigate interrupt-stack pressure, driver behavior, nesting, and the machine’s configuration. A bad device driver can corrupt memory even when more stacks make the crash less frequent. A larger pool is not proof that the root cause is fixed.
Do not infer a universal one-interrupt/one-stack mapping. Interrupt entry, stack switching, nested events, and driver behavior are implementation details that can vary across DOS kernels and hardware configurations. The directive’s count is an allocation limit, not a measured number of simultaneously active devices. Avoid unsupported calculations based only on the number of loaded drivers.
Also distinguish capacity from corruption. A larger pool can provide room for additional supported interrupt-handling contexts, but it cannot repair a handler that returns with the wrong stack pointer, fails to restore registers, writes beyond a buffer, or calls non-reentrant DOS services at an unsafe time. A repeatable failure after the stack change still needs a driver-level investigation. A failure that becomes rarer may indicate nesting pressure, but it can also be a timing-sensitive overwrite whose trigger moved.
Read the directive contract before changing it
The FreeDOS help provides this syntax:
STACKS=16,256The values above are a documented example, not a recommendation. The directive belongs in CONFIG.SYS or FreeDOS’s FDCONFIG.SYS; changing it requires a boot so the kernel can build its startup data. The help states that STACKS is internal to KERNEL.SYS and does not require another executable. STACKSHIGH is the high-memory alternative and requires a compatible high-memory manager, such as a supported HIMEM/JEMM configuration, to make high memory available.
FreeDOS documentation notes that STACKS=0,0 may be used in some cases to rely on standard stacks rather than allocating extra hardware-interrupt stacks. Do not use that as a generic memory-saving setting. The phrase “in some cases” is an important caveat: first identify the target kernel, boot path, and interrupt workload, and preserve a fallback configuration. If the machine currently boots and operates reliably, a marginal memory gain does not justify removing the safety margin without a measured requirement.
Establish evidence before tuning
Capture a baseline before changing the boot file. Record the exact kernel version and hash, CPU or VM configuration, memory manager, device drivers and load order, STACKS directives, and the workload that triggers the failure. Preserve the full error text and whether the event coincides with disk, serial, sound, timer, or network activity. A single reboot after a configuration edit is not an adequate test of an interrupt-sensitive fault.
Use two boot-menu entries: a known-good baseline and a test entry with one stack-related change. Keep the original FDCONFIG.SYS/CONFIG.SYS copied to a recovery path. Change either the count or size in a controlled way, not both plus several driver order changes at once. The memory cost of the pool is roughly related to the number and size of allocations, but alignment and kernel implementation can affect the actual footprint; measure with FreeDOS MEM rather than presenting the simple product as an exact byte cost.
Choose the first test value from a target driver’s or application’s documented requirement when one exists. Otherwise, make a modest, reversible adjustment and evaluate it under repeatable stress. Do not copy a value from a forum post because the CPU class or sound card appears similar. BIOS revisions, bus timing, memory managers, TSR order, and emulator behavior can change the workload. Record why the value changed so a future kernel upgrade does not preserve an obsolete workaround without review.
When a boot menu has multiple configurations, confirm the test entry actually reads the edited file. FreeDOS can use FDCONFIG.SYS and alternate startup-file behavior; a successful boot may be from a different configuration than the one being edited. Confirm the selected menu branch, inspect echoed startup lines if available, and retain a recovery entry that bypasses the test driver or stack setting. A controlled change must be reversible without relying on the device driver being investigated.
Exercise the operations that generate the relevant hardware interrupts. If the failure appears during disk transfer, run the same read/write workload and verify file contents afterward. For a serial issue, perform sustained two-way transfer and check framing, overrun, and application results. For sound or network drivers, repeat the real workload long enough to exercise callbacks and nested activity. Do not use destructive media or valuable data during this test.
Test both peak and recovery behavior. Include idle periods, bursts of activity, a deliberate device disconnect where safe, and clean shutdown/reboot. Some failures occur only when one interrupt arrives while another service is active; a short demonstration that plays a sound or copies a tiny file may never reach that state. Run the same sequence several times and compare logs, checksums, and error messages rather than accepting one lucky pass.
Distinguish a stack shortage from a driver defect
If the failure disappears after adding stacks, retain that result as a clue, not a final diagnosis. Repeat the test from a clean reboot, then compare the same profile with one driver omitted or replaced. Check whether the failure follows a particular driver, hardware device, interrupt-sharing arrangement, or timing condition. Review the driver source/manual when available and verify that interrupt handlers preserve the registers and stack state their calling convention requires.
If a failure persists at a larger setting, return to the saved baseline and investigate memory corruption, incorrect interrupt-vector ownership, incompatible TSR interactions, and application stack sizing. Do not continue raising the count to chase a non-deterministic crash. If only an emulator reproduces the issue, verify its virtual device model and interrupt behavior before blaming FreeDOS itself.
For a production-like installation, accept a STACKS change only when the target workload completes repeatedly, data and device output validate, the memory cost is understood, and the fallback boot option remains usable. Record the configuration delta and the exact test result. STACKS is a narrow kernel resource control: it can supply more interrupt-stack capacity when evidence supports that need, but it cannot guarantee a misbehaving driver is safe or cure every application stack overflow.
Related:
- Device Drivers on FreeDOS: How .SYS Files Extend the Kernel
- Recovering a FreeDOS System That Won’t Boot After a Bad CONFIG.SYS Edit
Sources: