Why is DNS apparently involved in issuing "dir" on Windows 10?

The second cmd.exe fails to locate and subsequently load the localized strings from the cmd.exe.mui satellite resource library.

Here is what it really attempts to say, taken from a 10.0.18362.1 (160101.0800):

• 0x235F: "Volume in drive %1 is %2"
• 0x235B: "Volume Serial Number is %1"
• 0x2339: "Directory of %1"

This is actually the first three lines of a plain dir command output.

This is a funny one. There are no entries for messages numbers 0x235F and 0x235B in the default system message table. So for the first two outputs, you get that cryptic message as shown in @harrymc's console screenshot.

But for 0x2339, there is an entry in the default system message table, physically stored in KernelBase.dll.mui pointing to the text "DNS bad key":

It just so happens to share the number of the "Directory of %1" line of the command processor's resources: a fallback not anticipated by the developers of cmd.exe. So the DNS reference is just a coincidence, it could be anything.

Note that the proper message contains a variable argument (the directory name), while the DNS message doesn't. I guess that's why there is no more output after that - it might just terminate.

I have managed to duplicate the problem:

(I agree that the messages are not very informative.)

The problem is that starting from Vista all the text messages are compiled into a separate file, so Windows would search for a message file with your new CMD name and would not be able to find it.

It is not enough to copy cmd.exe to cmd-2.exe. You also need to copy in the folder %WinDir%\System32\en-US (or your language) the file cmd.exe.mui to cmd-2.exe.mui, otherwise you will get these crazy messages anytime that cmd-2.exe needs to issue a message.

Note : "DNS" here does not refer to the internet Domain Name System. This is just a coincidence.