{"id":111306,"date":"2025-06-25T07:00:00","date_gmt":"2025-06-25T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=111306"},"modified":"2025-06-25T07:33:27","modified_gmt":"2025-06-25T14:33:27","slug":"20250625-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20250625-00\/?p=111306","title":{"rendered":"Why do I get errors about some weird symbol called ?main@@YAHP$01E$AAV?$Array@PE$AAVString@Platform…, part 1"},"content":{"rendered":"

A colleague was writing a fuzz test and ran into a build error.<\/p>\n

vccorlib.lib(climain.obj) : error LNK2019: unresolved external symbol \"?main@@YAHP$01E$AAV?$Array@PE$AAVString@Platform@@$00@Platform@@@Z\" (?main@@YAHP$01E$AAV?$Array@PE$AAVString@Platform@@$00@Platform@@@Z) referenced in function \"int __cdecl _main(void)\" (?_main@@YAHXZ)\r\n<\/pre>\n
What does this mean?<\/p>\n
My colleague was writing a fuzz test in C++, but noted that other parts of the component are written in C++\/CX.<\/p>\n
I could have guessed that C++\/CX was involved because the missing symbol says that it’s a function named main<\/code> which takes parameters that involve things named Array<\/code>, String<\/code>, and Platform<\/code>.<\/p>\n
 The signature for the main<\/code> function in a C++\/CX program<\/a> is<\/p>\n
int main(Platform::Array<Platform::String^>^ args)\r\n<\/pre>\n
so that seems to match up with the words we picked out of the decorated name.<\/p>\n
(Amusingly, C++\/CX is such a black sheep that the linker’s decorated name decoder can’t even decode C++\/CX names.)<\/p>\n
The usage of this particular fuzz test library is similar to LLVM’s libFuzzer<\/a>: You define a fuzzing entrypoint that takes a memory block, and the library provides a main<\/code> function that calls your function repeatedly with different blocks of memory.<\/p>\n
We pulled in the Visual Studio team to help figure out why the wrong main<\/code> function was being requested.<\/p>\n
They suggested linking with the \/verbose<\/code> to get more insight into how the linker is working.<\/p>\n
      Found mainCRTStartup\r\n        Loaded libcmt.lib(exe_main.obj)\r\n\r\n      Found main\r\n        Referenced in LIBCMT.lib(exe_main.obj)\r\n        Loaded vccorlib.lib(main.obj)\r\n\r\n      Found \"int __cdecl _main(void)\" (?_main@@YAHXZ)\r\n        Referenced in vccorlib.lib(main.obj)\r\n        Loaded vccorlib.lib(climain.obj)\r\n\r\nvccorlib.lib(climain.obj) : error LNK2019: unresolved external symbol \"?main@@YAHP$01E$AAV?$Array@PE$AAVString@Platform@@$00@Platform@@@Z\" (?main@@YAHP$01E$AAV?$Array@PE$AAVString@Platform@@$00@Platform@@@Z) referenced in function \"int __cdecl _main(void)\" (?_main@@YAHXZ)\r\n<\/pre>\n
The error message says that vccorlib.lib<\/code>‘s climain.obj<\/code> has a reference to the weird version of main<\/code>. Working backward through the verbose output, we see that vccorlib.lib(climain.obj)<\/code> was in turn added to the binary because it satisfied a search for int __cdecl _main(void)<\/code> that was requested by vccorlib.lib(main.obj)<\/code>.<\/p>\n
The vccorlib.lib(main.obj)<\/code> was added to the binary because it satisfied a request for main<\/code> from libcmt.lib(exe_main.obj)<\/code>.<\/p>\n
And libcmt.lib(exe_main.obj)<\/code>. was added to the binary because it satisfied a request for mainCRTStartup<\/code>, which was presumably requested by the linker because this was linked as a console program.<\/p>\n
The problem is that the main<\/code> function was found in vccorlib.lib<\/code> rather than in the fuzzer library.<\/p>\n
The final piece of the puzzle is  the linker documentation on the finer points of how it resolves symbols<\/a>:<\/p>\n
Object files on the command line are processed in the order they appear on the command line. Libraries are searched in command line order as well, with the following caveat: Symbols that are unresolved when bringing in an object file from a library are searched for in that library first, and then the following libraries from the command line and \/DEFAULTLIB<\/tt> (Specify default library) directives, and then to any libraries at the beginning of the command line.<\/p><\/blockquote>\n
Okay, now we can piece the story together by working forward.<\/p>\n
The linker starts by looking for mainCRTStartup<\/code>, and that leads to the main<\/code>, which in turn leads to the wrong int __cdecl _main()<\/code>. We get the wrong one due to the “symbols that are unresolved when bringing in an object file from a library” rule: The linker got main<\/code> from vccorlib.lib<\/code>, so the search for _main<\/code> begins at vccorlib.lib<\/code>, and that’s why it finds the one in vccorlib.lib(climain.obj)<\/code> instead of the one in the fuzzer library.<\/p>\n
Now that we understand what happened, we can produce a minimal reproducible example.<\/p>\n
>lib.cpp echo void fuzzme(); int __cdecl main(int, char**) { fuzzme(); return 42; }\r\ncl \/c lib.cpp\r\nlib \/out:lib.lib lib.obj\r\n<\/pre>\n
This first step creates a library which provides a definition of main<\/code>. This is the minimal version of the fuzzer library.<\/p>\n
>fuzzer.cpp echo void fuzzme() {}\r\ncl \/c fuzzer.cpp\r\n<\/pre>\n
The next step creates the fuzzer client that the fuzzer library calls.<\/p>\n
And then we can try to link it and see what happens.<\/p>\n
link \/out:fuzzer.exe \/subsystem:console fuzzer.obj lib.lib\r\n\r\nrem succeeds!\r\n<\/pre>\n
Hm, our attempt to create a minimal reproduction failed. There must be something we are missing.<\/p>\n
We’ll continue the investigation next time.<\/p>\n","protected":false},"excerpt":{"rendered":"
Welcome to the world of C++\/CX. Is “welcome” the right word?<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-111306","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Welcome to the world of C++\/CX. Is “welcome” the right word?<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/111306","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=111306"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/111306\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=111306"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=111306"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=111306"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}