Take the 2-minute tour ×

I have a section of C++ code in MSVC2010 that creates a DLL wrapper. The section of code looks something like this...

extern "C" __declspec(dllexport) DWORD myDllExportFunction()
    return (DWORD)SomeFunction(SomeParameter);


_declspec(dllexport) int64 _stdcall myDllExportFunction2(<someType> someParameter){
    return new (DWORD)SomeExternalFunction(SomeParameter);

I would expect my exports section from doing a dumpbin on this dll to contain just the fully qualified function name however it looks more like this.

 _myDllExportFunction@12 = _myDllExportFunction@12

I have no idea why this equal sign is there or what it means. I have a strong feeling that the function is not accessible by programs which import the dll as it is not doing what it is supposed to.

for sake of providing enough information I have included some of my compiler and linker switches

Compiler Options:

/Zi /nologo /Wall /WX- /O2 /Ob2 /Oi /Oy- /D "_WINDLL" /D "_MBCS" /D "_AFXDLL" /Gm- /EHsc /GS /fp:precise /Zc:wchar_t /Zc

Linker Options:

/MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"C:\....\MyProj.pdb" /SUBSYSTEM:CONSOLE /OPT:REF /OPT:ICF /PGD:"C:\....\MyProj.pgd" /TLBID:1 /DYNAMICBASE:NO /NXCOMPAT:NO /IMPLIB:"MyProj.lib" /MACHINE:X86 /ERRORREPORT:QUEUE 

Note: /IMPLIB:"MyProj.lib" -> This import library has all of the exports that I want to have in my DLL in the format that I want them to be in the dll.

Is there any setting in my projects options that would cause this? Was there any changes to dllexport in the past years that I might have missed? Is there any information that I could provide you that would help you understand my problem?

share|improve this question
Delete the .pdb file to get less confuzzling output. –  Hans Passant Sep 30 '11 at 17:43

4 Answers 4

up vote 3 down vote accepted

Try turning off debug information generation.

enter image description here

share|improve this answer
This does NOT affect the names of exported functions. –  Ben Voigt Sep 30 '11 at 17:43
@BenVoigt This was actually the error that I was describing in the problem. +1, but not enough rep to :*( –  Satyrn Sep 30 '11 at 18:18

You have mangled the name by declaring it __stdcall, presumably in a separate declaration. You must give it the __cdecl calling convention to avoid name mangling.

share|improve this answer
__cdecl doesn't avoid name mangling, it just changes the rules. –  Ben Voigt Sep 30 '11 at 17:43
@BenVoigt This actually appeared to remove the mangling when I tried this, however I did not ask to remove the mangling (I still wanted to see). –  Satyrn Sep 30 '11 at 18:25
@Ben: It can effect name mangling: msdn.microsoft.com/en-us/library/x7kb4e2f.aspx –  John Dibling Sep 30 '11 at 19:04
I mean, im looking right at a project that I've been building minute after minute, and it does for me. I think that's proof enough. It seems that it only removes name mangling if it is defined extern "C" __declspec(dllexport) <Type> __cdecl functionName(functionParams) not possitive but I think extern "C" combined with this is what is removing the mangling. –  Satyrn Sep 30 '11 at 19:11
It changes the mangling rules. With extern "C" __cdecl, the only mangling is adding a leading underscore. On x86, anyway. –  Ben Voigt Sep 30 '11 at 19:47

If you want to control the names of exported functions (for example, to remove mangling), you'll need to use a linker module definition (.def) file.

share|improve this answer
I dont need to remove name mangling, however I have tried this and I get linker errors which makes me thing that it is not finding these methods in my C classes. Here is an example of the def file... [code]LIBRARY myProjectname EXPORTS "myDllExportFunction@12"[/code] –  Satyrn Sep 30 '11 at 17:54
@Satyrn: Just put the function name into the .def file, like LIBRARY myProjectname EXPORTS myDllExportFunction. No quotes, no stack size annotation. You might possibly need EXPORTS myDllExportFunction = _myDllExportFunction@12, but usually the linker figures that out. Do pay attention to leading underscores. –  Ben Voigt Sep 30 '11 at 18:08
I found the solution in another persons answer, however just simply trying to use a def file gives me LNK2001 errors "unresolved external symbol" and I dont particularly know why. I removed the name mangling in the def files for each of my functions. –  Satyrn Sep 30 '11 at 18:15

There are a few different options to prevent name mangling.

  • Change the declaration specifier for the exported function from __stdcall to __cdecl. So the function signature should look like this

    extern "C" DWORD __declspec(dllexport) __cdecl myDllExportFunction()

If you must use the __stdcall calling convention use one of the following two methods to get around name mangling. In both cases you do not need to add __declspec(dllexport) to the function definition (but it's OK if you do).

  • Add a .def file to the project containing the lines

LIBRARY YourLibraryName

  • In the project properties, go to Linker -> Command Line and in the edit box for Additional Options add /export:myDllExportFunction
share|improve this answer
I think the list of exported functions goes under the EXPORTS keyword, not on the same line. And __cdecl function names will still be mangled with a leading underscore. –  Ben Voigt Sep 30 '11 at 18:11
@BenVoigt Thanks, you're right about the def file syntax. But __cdecl function names are not mangled with a leading underscore, I've got a working project open in front of me that proves otherwise. –  Praetorian Sep 30 '11 at 18:16
x86 or x64. That changes the rules too. en.wikipedia.org/wiki/… –  Ben Voigt Sep 30 '11 at 19:48
@BenVoigt It's an x86 C project compiled with VS2005. No mangling happens unless I change the calling convention to __stdcall; I don't know why Wikipedia is saying what it is. –  Praetorian Sep 30 '11 at 20:20
What tool are you using to check for mangling? –  Ben Voigt Sep 30 '11 at 20:40

Your Answer


