Fix STATUS_NO_UNICODE_TRANSLATION 0xC0000717 on Windows

This error appears when a program tries to write a Unicode character to a file or output that uses a non-Unicode (ANSI/MBCS) code page that doesn't support that character.

When this error hits

You're running an older Windows program — something compiled with MBCS (Multi-Byte Character Set) instead of Unicode. Maybe it's a Japanese business app from 2005, or a file manager that handles filenames with Chinese characters. The program tries to write a filename or string containing a character outside its active code page — say, a Chinese character while the system is set to Japanese Shift-JIS. Windows then throws STATUS_NO_UNICODE_TRANSLATION (0xC0000717).

I've seen this most often with:

Legacy database export tools that create files with Unicode filenames.
Old C++ apps compiled with MBCS that call WideCharToMultiByte without the WC_NO_BEST_FIT_CHARS flag.
Scripts that pipe Unicode output through a non-Unicode console.

What's actually happening

At the kernel level, Windows uses UTF-16 for all internal string handling. But older programs, especially those written before Windows 2000, use the A (ANSI) versions of API functions like CreateFileA or WriteFile. These A functions internally convert the Unicode strings to the system's active code page using WideCharToMultiByte. If that code page — say, codepage 932 for Japanese — doesn't have a mapping for a particular Unicode code point, the conversion fails with STATUS_NO_UNICODE_TRANSLATION.

Strictly speaking, the error is correct behavior. The system can't map that character to the target code page, so it refuses to proceed with data loss. The fix involves either changing the program to use Unicode, or switching your system's active code page to one that includes those characters — like UTF-8 (codepage 65001).

The fix: three steps

Step 1: Check what code page your program is using

Open a Command Prompt and run:

chcp

This prints something like Active code page: 932. If it's 437 (US English), 932 (Japanese Shift-JIS), or 936 (Simplified Chinese), you're on a legacy code page that only supports a limited character set.

The better approach: switch the system locale to UTF-8. This tells Windows to use codepage 65001 for ANSI-to-Unicode conversions, which can handle any character.

Step 2: Enable UTF-8 system-wide (Windows 10/11 only)

Go to Settings → Time & Language → Language & region.
Click Administrative language settings (under Related settings).
In the Region dialog, go to the Administrative tab.
Click Change system locale...
Check the box: Beta: Use Unicode UTF-8 for worldwide language support.
Restart your computer.

Why this works: That checkbox sets the system ANSI code page to 65001. Now when WideCharToMultiByte runs, it uses UTF-8, which can encode every Unicode character. The error disappears because there's no longer a character that can't be mapped.

Warning: Some very old DOS-era or 16-bit programs might break with UTF-8 enabled. I've seen old accounting software that expects codepage 437 and corrupts output. If you run ancient software, test thoroughly first.

Step 3: If you can't enable UTF-8 globally

Maybe you're on an older Windows version (7, 8, Server 2012) that doesn't have the UTF-8 option. Or maybe your app breaks with it. Then your only real fix is to change the system locale to a code page that does include the characters you need.

For example, if you're hitting this error with Chinese characters while your system is set to Japanese, change the system locale to Chinese (Simplified) instead:

Same steps as above — Region dialog, Administrative tab.
Under Current system locale, pick the target language.
Restart.

This changes the active code page to match the character set you're using. The trade-off: other characters (like Japanese kana) might now fail to translate.

What to check if it still fails

Is the program using a hard-coded code page? Some apps bypass the system locale and call SetFileApisToOEM or GetACP directly to force a specific code page. In that case, global settings won't help. You'd need to patch the program or contact the vendor.
Check the registry: Look at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage\ACP. If it's not 65001, your system wasn't switched to UTF-8. Verify step 2 took effect.
Test with a different program: Write a small test script that creates a file with a Unicode filename using Python or PowerShell. If it works but your app still fails, the problem is inside the app, not the system.
Last resort: Recompile the app with Unicode support (if you have source code). Change the project character set from MBCS to Unicode in Visual Studio. That bypasses the A-to-W conversion entirely.