Fix STATUS_INVALID_IDN_NORMALIZATION 0xC0000716

Quick answer: Replace non-ASCII characters in the hostname with their punycode (xn--) equivalent, or force ASCII-only DNS resolution — Windows is failing IDN normalization before it ever opens a socket.

I know this error is infuriating because it shows up at the worst possible moment, usually right after you typed a perfectly reasonable-looking URL. STATUS_INVALID_IDN_NORMALIZATION (0xC0000716) is an NTSTATUS code, not a Win32 error, which is why it doesn't show up in most "Windows error code" lists. It surfaces when the Windows networking stack tries to convert an Internationalized Domain Name (IDN) into ASCII form and the input fails validation — a bad character, a stray Unicode control code, a malformed punycode prefix, or a hostname that exceeds the 63-character label limit after encoding. The request dies before DNS even gets a packet. I've seen this triggered by a copy-pasted URL from a PDF that smuggled in a non-breaking space, and by enterprise apps passing Unicode hostnames into getaddrinfo() without setting AI_IDN flags. The application sees a generic network failure; the real cause is way lower in the stack.

Step-by-step fixes

Strip non-ASCII characters from the hostname. Open Notepad, paste the URL or hostname, and save it as UTF-8. Then check for zero-width spaces (U+200B), non-breaking spaces (U+00A0), and smart quotes. Any of these will break normalization. Retype the hostname by hand if you're not sure.
Convert the IDN to punycode. If the hostname genuinely contains non-ASCII letters (e.g., münchen.de), run it through a punycode converter and use the ASCII form. For münchen.de that's xn--mnchen-3ya.de. Python has this built in:
```
python -c "print('münchen.de'.encode('idna').decode())"
# xn--mnchen-3ya.de
```
Use that ASCII form anywhere the app is failing.
Check the label length. A single DNS label must be 63 bytes or fewer after punycode encoding. Unicode characters expand — a 40-character Chinese hostname can blow past 63 bytes easily. Shorten it or split into subdomains.
Verify the hosts file and DNS cache aren't feeding garbage. Open C:\Windows\System32\drivers\etc\hosts in an editor that shows Unicode. If you see a hostname with a BOM or non-ASCII bytes, delete the line. Then flush:
```
ipconfig /flushdns
nslookup hostname
```
Test with an ASCII-only hostname. If ping example.com works but ping münchen.de fails with 0xC0000716, the problem is IDN handling, not DNS. If both fail, the issue is upstream — check the network adapter, Winsock, or a proxy.
Reset Winsock and TCP/IP if things are really weird.
```
netsh winsock reset
netsh int ip reset
shutdown /r /t 0
```
Only do this after you've confirmed the hostname itself is valid. Resetting won't fix a malformed string.

If the main fixes don't work

Disable IDN in the application layer. Some apps let you toggle IDN support off in config. Firefox has network.IDN_show_punycode in about:config — setting it to true forces display of punycode and skips the normalization path that's failing.
Check the calling code. If you're a developer and this is your app, you're probably calling a socket API without setting AI_IDN in the addrinfo hints. The kernel then rejects the Unicode input. Set the flag on Windows 10 1809+ and Windows 11, or pre-encode the hostname yourself with IdnToAscii() from normaliz.dll.
Look at installed IDN TLD filters. Registry key HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\IdnFilter holds TLD policies. A corrupted or overly restrictive entry here causes normalization to fail on legitimate domains. Back up the key, then delete individual TLD values one at a time to isolate the offender.
Scan for a proxy or VPN injecting hostnames. Corporate SSL inspection tools sometimes rewrite SNI or HTTP Host headers with non-ASCII characters. Bypass the proxy for one test and see if the error vanishes.

Preventing it next time

Rule of thumb: never let a non-ASCII hostname travel unencoded through an API boundary, a proxy, or a config file. If you must use IDN, encode to punycode at the moment of input — not at the moment of the DNS call.

For developers, wrap hostname input with IdnToAscii(0, input, -1, output, length) and check the return value. For everyone else, keep a punycode converter bookmarked and treat any 0xC0000716 as a sign that somewhere a Unicode string slipped past the ASCII-only assumption baked into most Windows networking code. This tripped me up the first time too — I spent 20 minutes blaming DNS before I realized a PDF had inserted a zero-width space into the hostname. Once you know to look for it, the fix takes 30 seconds.