There is a neat command line tool called UNDNAME.EXE to un-decorate a name, but what if you need the opposite? I.e., given a function header, how do you get its decorated name?

Well, you could reconstruct it manually. The decoration scheme is intentionally undocumented, but at least 2 efforts were made to reverse engineer it.

If the name you’re after is of a function from your source, you can momentarily plant a FUNCDNAME inside it to get access to the decorated name from your code, and then, say, OutputDebugString it.

In the general case, there are two documented ways to obtain the decoration:

(1) Using DUMPBIN,

(2) Using a Listing File.

Using a listing file is superior in at least two ways: (a) it is one stage shorter – you don’t need to perform extra-analysis on compilation outputs, and (b) the step you save requires a command shell, which I personally avoid like the plague. Seriously, it is 2009. You shouldn’t work like they did in 1980 unless you have absolutely no choice.

In a recent StackOverflow discussion, two other options came up: using map files, and using dependency walker. These seemed like valid, even creative, solutions – and I wondered why MS didn’t document them as valid ways to observe decorations.

Well, MS chose so for a reason. Both suggestions have a fundamental flaw: map files, as well as dependency-walker display, contain only decorated names. This can be a serious problem if you need to isolate the decorated name to one of several function overloads. Your map file can, for example, include the following two names:

?ExtractElement@@YAHV?$_com_ptr_t@V?$_com_IIID@UIDCXOBJ@@$1?_GUID_5a54cea3_94aa_11d6_bdc8_00c04f03ca8b@@3U__s_GUID@@B@@@@KAAV?$CStringT@DV?$StrTraitMFC_DLL@DV?$ChTraitsCRT@D@ATL@@@@@ATL@@@Z
?ExtractElement@@YAHV?$_com_ptr_t@V?$_com_IIID@UIDCXOBJ@@$1?_GUID_5a54cea3_94aa_11d6_bdc8_00c04f03ca8b@@3U__s_GUID@@B@@@@K@Z

Have fun deciding which of the two matches –

BOOL ExtractElement( IDCXOBJPtr pObj, CONST DWORD Tag , CString& strOut)