If undecorated names are given in the DLL export table, why does link /dump /exports show me decorated names?

If you run the link /dump /exports command on a DLL which exports only undecorated names, you may find that in addition to showing those undecorated names, it also shows the fully-decorated names.

We're building a DLL and for some functions, we have chosen to suppress the names from the export table by using the NONAME keyword. When we dump the exports, we still see the names. And the functions which we did want to export by name are showing up with their decorated names even though we list them in the DEF file with undecorated names. Where is the decorated name coming from? Is it being stored in the DLL after all?

        1        00004F1D [NONAME] _Function1@4
        2        000078EF [NONAME] _Function2@12
        3        00009063 [NONAME] _Function3@8

The original decorated names are not stored in the DLL. The link /dump /exports command is sneaky and looks for a matching PDB file and, if finds one, extracts the decorated names from there.

(How did I know this? I didn't, but I traced each file accessed by the link /dump /exports command and observed that it went looking for the PDB.)

Comments (11)
  1. Adam Rosenfield says:

    Process Monitor is super-useful like that.  I once discovered that the index and search panes had completely disappeared from whenever I tried to open a particular .chm help file.  The timestamp on the CHM hadn't changed, and it was identical to a known good copy.

    After looking through the file and registry accesses of hh.exe with Process Monitor and comparing it with another .chm file, I discovered that it was looking for but not finding a similarly named .chi file.  After restoring the .chi file (I have no idea how it disappeared), the index and search panes were restored.

  2. 640k says:

    Or use "grep text *" to find the string of a decorated name. It's stored somewhere after all.

  3. Adrian says:

    I'm confused.  I don't see a /dump linker option listed in MSDN.  Do you mean dumpbin?

  4. John says:

    @Adrian:  Seems like the same thing.  Type link /dump into a VS shell and it'll show you the dumpbin help page.

  5. Crescens2k says:

    It is a (not very) well known fact that lib.exe, editbin.exe and dumpbin.exe are all stubs to link.exe. If you check the file description, all 3 have Microsoft Linker Stub. The hidden switches for all of them are link /edit for editbin, link /lib for lib and link /dump for dumpbin.

  6. David Walker says:

    Hidden/undocumented switches?  I hate that.  Even XCopy.exe in Windows 7 has some undocumented switches.  

  7. Nick says:


    Undocumented, or does link support truncated options?  I've found several Microsoft tools that let you shorten options as long as they're still unambiguous (a la Powershell).

  8. Gabe says:

    David: I just ran xcopy/? on Win7 and it has documented switches for all 26 letters of the alphabet plus /EXCLUDE. If you know of other switches, I'd love to know.

  9. David Walker says:

    Somewhere I thought I saw a switch that wasn't documented in XCopy /?.  Oh well, maybe my alphabet is larger than yours!

  10. mikeb says:

    I'm not sure I like that behavior – it should be enabled only by a switch.  I usually use `dumpbin` (aka link /dump) to try and figure out what's going on when things are going wrong.  I'd really rather it didn't mislead me about what's in a file.

    But – thanks for the heads up (please don't take this post as trying to assign some sort of blame – I'm not).

    [It's not actually lying. The entry is reported as [NONAME]. It's just that the linker offers a little "extra info", but if you don't know about it, you might confuse the "extra info" with the "main info". -Raymond]
  11. mikeb says:

    >> you might confuse the "extra info" with the "main info"

    Yeah – after thinking about a bit, the real problem is that there's a *lot* of stuff that dumpbin shows or can show, and I understand maybe 9% of it (if I'm being generous with myself).

Comments are closed.

Skip to main content