Fixing ERROR_INVALID_STARTING_CODESEG (0x000000BC)

When you see this error

You double-click an old executable — maybe a DOS game from 1992 or a custom accounting tool from Windows 3.1 — and instead of running, Windows spits out a dialog: "The operating system cannot run %1. ERROR_INVALID_STARTING_CODESEG (0x000000BC)." The number sign %1 is a placeholder that should show the program name, but often it's blank because the loader couldn't even read the file header properly.

This error shows up on 64-bit Windows 10 and 11. It does not happen on 32-bit Windows versions — those still have the NTVDM (NT Virtual DOS Machine) subsystem that translates 16-bit code to run under 32-bit Windows. On 64-bit Windows, that subsystem is gone. Period.

What's actually happening

Every Windows executable starts with an MZ header (the bytes "MZ" at offset 0). For 16-bit, 32-bit, and 64-bit PE files, the MZ header is followed by a DOS stub that prints "This program cannot be run in DOS mode" — but the real entry point is elsewhere. The loader looks at the MZ header's last two bytes (the e_cparhdr field, offset 0x3C) to find the actual PE header offset.

What's happening here is that the PE header either:

• Points to a 16-bit NE (New Executable) header, which Windows 64-bit doesn't support
• Is missing or corrupted — maybe the file got truncated during download
• Belongs to a DOS MZ executable that's not a Windows program at all

The error code 0x000000BC maps to ERROR_INVALID_STARTING_CODESEG. The internal Windows loader uses this when it detects the code segment descriptor in the executable header is invalid for the current architecture. On 64-bit Windows, the only valid starting code segment is 32-bit or 64-bit. A 16-bit code segment descriptor triggers this exact error.

The fix

There's no way to "enable" 16-bit support on 64-bit Windows — it's a hardware and kernel limitation. The CPU itself in long mode (64-bit) cannot switch to virtual 8086 mode that 16-bit code needs. So the real fix is one of these:

1. Check if the file is actually a 16-bit program. Right-click the EXE, open Properties, look at the "Details" tab. If it says "16-bit" under "Target Platform" or shows a file version like "1.0.0" (very old), it's 16-bit. Use a hex editor: open the file and look at offset 0x18. If the bytes are 40 00 (little-endian = 0x0040), that's a 16-bit NE header flag. No fix — you need the next step.
2. Use a 32-bit Windows VM or an emulator. The clean option: install Windows XP or Windows 7 32-bit in a virtual machine (VirtualBox, VMware). The 16-bit program runs there because NTVDM is present. I've done this for old Lotus 1-2-3 macros. Works perfectly.
3. Try a DOSBox emulator for DOS programs. If the file is a straight DOS EXE (no Windows header), use DOSBox. It emulates the entire DOS environment including 16-bit code segments. Download DOSBox from dosbox.com, mount your program's folder with mount c c:\oldstuff, and run the EXE.
4. For 16-bit Windows programs, use WineVDM. WineVDM is a third-party implementation of the Windows 16-bit subsystem for 64-bit Windows. Download it from GitHub (otya128/winevdm). Extract the files, then run otvdm.exe and point it to your old EXE. It translates 16-bit calls to 32-bit ones. I've tested it with Windows 3.1 programs — works for most, not all. Some that do direct hardware access will crash.
5. Repair a corrupted file. If the error happens on a file you know should work (e.g., a 32-bit installer that's been corrupted), the fix is replacing it. Re-download from a trusted source. If it's from an old CD, copy it again using xcopy /c to skip bad sectors. Open the file in a hex editor — if the first 64 bytes look like garbage (no "MZ" at offset 0), the file is toast. Get a clean copy.

If it still fails

Check these three things:

• Are you on 32-bit Windows? Open System Information. If it says "x64-based PC" or "64-bit operating system", you're on 64-bit and none of the registry hacks will help. If it says "x86-based PC", you're on 32-bit — then the error means the file is actually a pure DOS MZ executable with no Windows header, not a 16-bit Windows program. Try DOSBox.
• Is the program protected? Some old programs used copy protection that modifies the header. If you got the file from a disk image (IMG, IMA), the header might be intentionally scrambled. Use a proper mount tool like WinImage to extract the file cleanly.
• Does the program rely on a DLL from Windows 9x? Even if you get the EXE running via WineVDM, it might crash later looking for krnl386.exe or vmm32.vxd — these don't exist on NT-based Windows. Your only option then is a full 32-bit Windows VM with the original OS version.

The bottom line: 64-bit Windows killed 16-bit support. Don't waste time looking for a toggle — there isn't one. Use the right tool for the job: DOSBox for DOS programs, WineVDM for 16-bit Windows apps, and a VM for everything else.