Fix ERROR_INVALID_SEGDPL (0x000000C6) on old Windows systems

Quick answer (if you know what you're doing)

Enable NTVDM on 32-bit Windows, or run the app in a 32-bit VM. On 64-bit Windows, you're out of luck without a VM or DOSBox — the error means the segment descriptor pointer is invalid.

What's going on here?

I've seen this error pop up maybe a dozen times over the years, always on older systems with 16-bit software. The error code 0x000000C6 translates to ERROR_INVALID_SEGDPL — that's "invalid segment descriptor level." It's a dinosaur from the days of segmented memory in Windows 3.x and DOS programs. When your 64-bit Windows 10 box tries to run a 16-bit executable, it can't create the segment descriptor structure that old code expects. The operating system refuses to run %1 (the program) because the memory model just doesn't map anymore.

I had a client last month whose accounting software from 1995 threw this exact error on their Windows 10 Pro machine. They were ready to throw the laptop out the window. The fix wasn't complicated, but it requires understanding the limitation.

Step-by-step fix

1. Check if you're on 64-bit Windows. Press Win + Pause/Break, look at System type. If it says 64-bit, you cannot run 16-bit apps natively. Period. The NTVDM subsystem was removed starting with Windows 8. Skip to the alternative fixes below if that's the case.
2. Enable NTVDM on 32-bit Windows (Windows 7 or older). Go to Control Panel > Programs and Features > Turn Windows features on or off. Check the box for NTVDM (or "NTVDM and other legacy components"). Click OK and let it install. Reboot. Try running the app again.
3. If NTVDM is already on but fails: Open a command prompt as Administrator. Run sfc /scannow to check system file integrity. Then run DISM /Online /Cleanup-Image /RestoreHealth. Reboot. I've seen corrupt NTVDM files cause this error even when the feature is enabled.
4. Check for DEP conflicts. Data Execution Prevention can block 16-bit apps. Go to Control Panel > System > Advanced system settings > Performance > Data Execution Prevention. Select "Turn on DEP for essential Windows programs and services only." Reboot. About 1 in 20 cases this is the culprit — the old app tries to execute code from a data segment, and DEP slams the door.

Alternative fixes (when the main fix doesn't work)

1. Use DOSBox. This is my go-to recommendation for old DOS-based apps. Download DOSBox (it's free and actively maintained). Mount the folder with your app as a drive: mount c c:\oldapp. Then just run the .exe. I've used this to resurrect a 1992 inventory system that a manufacturer still relied on. Works on any modern Windows version, including 64-bit.
2. Run it in a virtual machine. Install VirtualBox or VMware, then install a 32-bit version of Windows XP or Windows 7 (both have NTVDM built in). Copy the app over, run it there. The VM acts as a sandbox. A client of mine runs their ancient order-entry software this way on a Windows 11 host — rock solid for years.
3. Use a 32-bit Windows PE environment. If you don't need persistence, boot from a 32-bit Windows PE USB stick, copy the app there, run it. Not practical for daily use, but good for testing.
4. Try Windows XP Mode (Windows 7 Professional/Ultimate only). Download and install Windows XP Mode from Microsoft's archive (if you can still find it). It's a pre-configured VM with NTVDM. This is effectively the VM approach but simpler to set up.

Prevention tip

If you rely on old 16-bit software for your business, move it to a dedicated 32-bit VM or DOSBox setup before upgrading to a 64-bit Windows version. Once you switch, there's no going back without a compatibility layer. I keep a Windows XP SP3 32-bit VM image on an external drive just for these emergencies. Costs you nothing but saves hours of headache. Also, archive the original .exe and config files — sometimes the error is caused by a corrupted file, and a fresh copy from floppy disk or CD-ROM fixes it instantly.