When this error shows up
You double-click a dusty old program from the mid-90s—maybe a DOS-based inventory tool or a legacy accounting app that came on floppy disks. Instead of the program loading, you get a pop-up with the text:
%hs is a 16-bit application. The exact error code is: 0xC0000414.
or the simpler version: "This program cannot be run in DOS mode." The app never opens. This happens on any 64-bit version of Windows—Windows 7, 8, 10, 11, and even Server editions. I see it most often with people trying to run custom-built MS-DOS programs or old 16-bit Windows apps written for Windows 3.1.
Why it happens
The short version: 64-bit Windows doesn't include the NT Virtual DOS Machine (NTVDM) subsystem. Without NTVDM, 16-bit code won't run. Period.
Longer version: Back in the 32-bit days (Windows XP, Vista, 32-bit Windows 10), Windows included a compatibility layer called WOW (Windows on Windows) that let 16-bit programs run inside a 32-bit environment. That layer relied on NTVDM.exe. Starting with 64-bit versions of Windows, Microsoft removed NTVDM entirely. The processor itself can't switch to virtual 8086 mode in x64 long mode. So no WOW layer, no 16-bit support. The error code 0xC0000414 literally means "the Virtual DOS Machine is disallowed." Microsoft is telling you: this can't happen here.
There's no registry hack or compatibility mode that will fix it. You need to either run the program in an environment that emulates the old system, or you need to install 32-bit Windows.
How to fix it — two real solutions
Option 1: Use DOSBox (best for DOS-based programs)
- Download DOSBox from dosbox.com. Get the latest stable version (current is 0.74-3).
- Install it. Accept the defaults. After install you'll see a DOSBox shortcut on your desktop.
- Open your 16-bit program's folder. Suppose it's at
C:\OldApp. - Double-click DOSBox. You'll see a tiny command prompt window with
Z:\>. - Type
mount c c:\OldAppand press Enter. DOSBox will say "Drive C is mounted as local directory c:\OldApp." - Type
c:and press Enter. The prompt changes toC:\>. - Type the name of your program, like
MYPROG.EXE, and press Enter. The program should start. - If your program needs a lot of conventional memory, create a DOSBox config file: click the DOSBox icon, choose "Options" > "Configuration." In
dosbox.conf, find the[dos]section and setxms=true,ems=true. Save and restart DOSBox.
What to expect: DOSBox emulates a full 16-bit environment. Most DOS-based apps work fine. Some very hardware-specific programs (like custom industrial controllers) might not. For those, use Option 2.
Option 2: Run 32-bit Windows in a virtual machine (for true 16-bit Windows apps)
If your app is a 16-bit Windows program (not DOS) — one that requires WIN.COM to start — DOSBox won't cut it. You need a real 32-bit Windows environment.
- Download and install VMware Workstation Player (free for personal use) or VirtualBox (also free).
- Get a copy of 32-bit Windows XP or 32-bit Windows 10. If you have an old install disc or an ISO file, use that. Microsoft doesn't sell Windows XP anymore, but you can use a trial or an MSDN ISO if you have one.
- Create a new virtual machine. In VMware Player, click "Create a New Virtual Machine." Choose the ISO file. Select "Microsoft Windows" and then "Windows XP" or "Windows 10 (32-bit)."
- Give the VM at least 1 GB RAM and a 20 GB virtual disk. More is fine but not needed for a single old app.
- Complete the install inside the VM. This takes 15–30 minutes. You'll have a full desktop.
- Copy your old program into the VM. The easiest way: create a shared folder. In VMware Player, go to VM > Settings > Options > Shared Folders. Enable it and point to your program's folder on the host.
- Inside the VM, browse to that shared folder (it's under My Computer > VMware Shared Folders). Copy the program to the desktop. Double-click to run.
- It should launch without the 0xC0000414 error because 32-bit Windows includes NTVDM.
What to expect: This method works for every 16-bit app I've ever thrown at it. The downside: it's heavy. You need a license for Windows (though XP SP3 can still be found second-hand), and the VM takes up disk space. But if your business depends on that old app, this is the right way.
What to check if it still fails
If you tried Option 1 and the program crashes inside DOSBox, check whether it's really a DOS program. Some 16-bit Windows apps (like old Visual Basic 3 programs) look like DOS but actually need Windows 3.1 or 95. Those won't run in DOSBox. Move to Option 2.
If Option 2 fails inside the VM, verify you installed a 32-bit version of Windows. A 64-bit Windows inside the VM has the same problem. Check System Properties in the VM—if it says "64-bit operating system," you need to reinstall with a 32-bit ISO.
Also check if the app needs a hardware dongle (like a parallel port key). USB dongles usually pass through fine. Parallel port dongles are trickier—they need a real parallel port on the host, or a USB-to-parallel adapter that the VM can see. I've seen people spend days on this. If you have a dongle, test it early.
One more thing: some antivirus software quarantines old executables because they look suspicious. Temporarily exclude your program's folder from real-time scanning, then try again. I've seen Norton and McAfee block 16-bit apps as "potentially unwanted."