Fix 0X000009C6: NERR_BadDosFunction on Old DOS Apps

You're trying to run some ancient DOS-based inventory program your client refuses to retire. It connects to a network share just fine for a while, then bam—error 0X000009C6, "NERR_BadDosFunction." The program calls an MS-DOS function that Windows 10 or 11 simply doesn't support anymore. I saw this last month at a plumbing supply warehouse—their 1998-era parts lookup tool started throwing this every time the user tried to print a pick list.

The root cause is straightforward: DOS programs use a set of interrupt-based network calls (INT 21h functions) that were designed for Windows 95/98 and earlier. Modern Windows dropped support for most of those legacy DOS network APIs. So when your old app tries to do something like get the current directory or rename a file on a mapped drive using a DOS function, Windows just says "no." The error code 0X000009C6 maps to NERR_BadDosFunction, which literally means "the DOS function is not supported." It's not your network being down, it's not a permissions problem—it's a compatibility gap.

What Actually Triggers It

Typically you'll see this when the DOS app does any of these:

• Opens or reads a file over a mapped network drive
• Uses NET USE or a UNC path directly
• Prints to a network share via a DOS print command
• Calls INT 21h function 0x44 (IOCTL) on a network handle

Most often it hits when the app runs from a mapped drive letter, like F:\, and tries to do something that requires a specific DOS network redirector. Windows 10 1809 and later are especially bad about this because they removed the old NetBios-over-TCP/IP redirector that DOS apps depended on.

The Fix, Step by Step

There's no single magic bullet, but I've had good luck with these steps. Try them in order—first one that works, stop there.

Step 1: Force the app to use a local drive

The easiest fix: copy the DOS program and its data files to the local machine. Run it from C:\DOSAPP instead of a mapped drive. That eliminates the network calls entirely. If the app needs to write to a server, set up a local folder and sync it manually or with a scheduled task. Not glamorous, but it works for single-user apps.

Step 2: Map the drive with the old NetBios protocol

If you must use a network drive, you can enable the legacy redirector. Open Control Panel > Programs > Turn Windows features on or off, then check:

SMB 1.0/CIFS File Sharing Support
   - SMB 1.0/CIFS Client
   - SMB 1.0/CIFS Server

Reboot, then map the drive again. This re-enables the old NetBios redirector that DOS apps actually understand. It's not great for security, but for a locked-down internal network, it's fine.

Step 3: Use a 32-bit DOS emulator

If steps 1 and 2 don't cut it, run the program inside DOSBox-X or vDOS. These emulators provide a full DOS environment with network support for old functions. You'll need to configure the network share in the emulator's config file. For DOSBox-X, add this to dosbox-x.conf:

[autoexec]
mount f: \\server\share
f:

That mounts a network share as drive F: inside the emulator, and the DOS functions work because the emulator translates them.

Step 4: Run in a Windows XP VM

Sometimes the DOS app uses a custom network driver that even emulators can't handle. Then the nuclear option: create a Windows XP VM in VirtualBox or Hyper-V. Install the app there, map the network drive, and let it communicate with your modern network via SMB 1.0 (which XP supports by default). I've had to do this for one customer's custom shipping label generator—worked perfectly after that.

What to Check If It Still Fails

If you've tried all that and still get 0X000009C6, check these:

• Permissions on the share: The DOS app might need write access to the root of the share. Give it full control temporarily to test.
• Firewall on the file server: Make sure ports 139 and 445 are open for SMB traffic.
• DNS resolution: If you're using a UNC path, ensure the server name resolves. Try ping servername from the client.
• Alternative: use a different protocol. Some DOS apps support IPX instead of NetBios. Install the IPX protocol on the client and server—but that's a long shot for modern hardware.

Honestly, the local-copy trick solves 80% of these cases. The rest need a VM or emulator. Don't waste hours chasing the perfect network fix—your client just wants their program to work. Pick the pragmatic route.