98

For complicated reasons, I have been forced to make an identical copy of cmd.exe and rename it to cmd-2.exe, which I put as a shortcut on the Taskbar to have them "grouped" in different taskbar groups.

Sometimes, I forget about this, and to open a new cmd.exe I middle-click that Taskbar icon to open a new cmd.exe. I then type a command such as dir and it spits out a bunch of nonsense, including: DNS bad key, which only happens if I accidentally use cmd-2.exe, not if I open the "real" cmd.exe, so it's not a "practical" problem.

However, I wonder why that message is ever printed at all. Is it apparently failing to do some kind of DNS lookup or something? Why is DNS involved at all with issuing dir to list files on my local computer? I have no network set up, no cloud drives, nothing like that whatsoever. It scares me that (apparently) there are DNS queries being made when I issue dir.

Maybe DNS bad key refers to something completely unrelated to the Domain Name System? I don't know what a "bad key" would even be in that context.

  • 42
    What other nonsense do those commands spit out? – user1686 Feb 10 at 11:41
  • 15
    Exactly how did you make the shortcut? – Moab Feb 10 at 11:41
  • 3
    not saying this is the case here, but these subsystems that call subsystems that call subsystems for no good reason, with some of them being known attack vectors, at least in some contexts, are not a recipe for security. 99.999% of the time, no issue, but the 0.001% is what helps crackers. – JL Peyret Feb 11 at 22:36
  • 8
    Why was my comment explaining my downvote reason, deleted? – Ian Kemp Feb 12 at 10:03
  • 6
    This looks like an XY problem, where a hack to solve the original problem causes this interesting problem. The answers are great, but I propose the OP also ask the original problem in a separate question. – Jonathan Feb 12 at 11:35
210

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":

screenshot taken from ResHacker

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.

| improve this answer | |
  • 6
    Reading how you got to the bottom of this is just so cool. I'm amazed such a cryptic event can be so easily traced. Thanks for a great and thorough answer! – Zimano Feb 12 at 15:55
  • @Zimano, where are you reading how they got to the bottom of it? – Pod Feb 12 at 16:05
  • 1
    @Pod In the answer we're commenting on. The answerer explains exactly how they found the cause of the symptoms OP is experiencing. Do you feel the question is still unanswered or..? I'm not sure I understand the reason behind your comment. – Zimano Feb 12 at 17:01
  • Sorry, perhaps it's a difference in language. Their answer didn't say "how" they came to this conclusion, it simply presented the conclusion. I thought there might be a blog post somewhere showing the "journey" they took to figuring it out :) – Pod Feb 12 at 17:05
  • @Pod Oh I understand :-) The answer indeed doesn't get to the 'bottom of it' completely. I guess it depends on the reader's prior knowledge of mui resource files. – Zimano Feb 12 at 17:16
112

I have managed to duplicate the problem:

enter image description here

(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.

| improve this answer | |
  • 6
    @ThorbjørnRavnAndersen Not CMD.exe, but Windows. CMD.exe simply asks the system for a string resource with a specified ID in the current user's language. It's Windows that does the searching and fallback handling. – Tom Lint Feb 11 at 16:27
  • So... what does it stand for? "Directory Name Search" maybe? – Darrel Hoffman Feb 13 at 18:06
  • @DarrelHoffman: Your guess is as good as mine. – harrymc Feb 13 at 18:19
  • 2
    I think the message does refer to DNS in the usual sense. @dlatikay's answer demonstrates it is essentially randomly picked from a list of kernel messages and the others nearby in the list look likely to refer to the Domain Name System. – Bob Sammers Feb 14 at 9:46
  • 2
    That depends on what you mean by "proper", I suppose. Windows supports DNSSEC (which uses keys). That is a standard, not just a Microsoft construct. It is speculation as to what these messages definitely refer to, of course, as well as going off-topic a little bit! – Bob Sammers Feb 14 at 10:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.