Question

I have the following error:

LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup

There are a lot of threads relating to this error, but none of those solutions worked for me. And, none explained why this error is here.

I tried:

• wWinMainCRTStartup as entry point in the linker properties (thread)
• set the linker to "Windows" (same thread as above)
• Right click on solution name->Add->Existing Item->file with main (same thread as above)
• #include <tchar.h> (error LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup)
• try Project + properties, C/C++, Code generation, Buffer security check = No (thread)
• Options: C/C++, Code generation, Runtime library=/MTd; C/C++, Code generation, Basic Runtime Checks=default; C/C++, Code generation, Buffer security check=No; Linker, Advanced, Entry Point=main (thread)
• commented out headers in main.cpp except using namespace std and #include <iostream> – results in cascading and snowballing error from functions that referencing those headers
• I deleted everything in main.cpp except test code, and excluded all source files except main.cpp; as expected it worked, so a small step in the right direction. The problem must be with one of the header files.
• create new project with Win32 Windows application template (thread and thread)

Have not tried and suspect that these also will not work:

• use int main() (not sure what they mean, file name or main function name) (thread)
• using cmake to build on Windows 7 x64 (thread)

Why am I getting this error, and what is the solution?

Answer 1

What is your project type? If it’s a “Win32 project”, your entry point should be (w)WinMain. If it’s a “Win32 Console Project”, then it should be (w)main. The name _tmain is #defined to be either main or wmain depending on whether UNICODE is defined or not.

If it’s a DLL, then DllMain.

The project type can be seen under project properties, Linker, System, Subsystem. It would say either “Console” or “Windows”.

Note that the entry point name varies depending on whether UNICODE is defined or not. In VS2008, it’s defined by default.

The proper prototype for main is either

int _tmain(int argc, _TCHAR* argv[])

or

int _tmain()

Make sure it’s one of those.

EDIT:

If you’re getting an error on _TCHAR, place an

#include <tchar.h>

If you think the issue is with one of the headers, go to the properties of the file with main(), and under Preprocessor, enable generating of the preprocessed file. Then compile. You’ll get a file with the same name a .i extension. Open it, and see if anything unsavory happened to the main() function. There can be rogue #defines in theory…

EDIT2:

With UNICODE defined (which is the default), the linker expects the entry point to be wmain(), not main(). _tmain has the advantage of being UNICODE-agnostic – it translates to either main or wmain.

Some time ago, there was a reason to maintain both an ANSI build and a Unicode build. Unicode support was sorely incomplete in Windows 95/98/Me. The primary APIs were ANSI, and Unicode versions existed here and there, but not pervasively. Also, the VS debugger had trouble displaying Unicode strings. In the NT kernel OSes (that’s Windows 2000/XP/Vista/7/8/10), Unicode support is primary, and ANSI functions are added on top. So ever since VS2005, the default upon project creation is Unicode. That means – wmain. They could not keep the same entry point name because the parameter types are different. _TCHAR is #defined to be either char or wchar_t. So _tmain is either main(int argc, char **argv) or wmain(int argc, wchar_t **argv).

The reason you were getting an error at _tmain at some point was probably because you did not change the type of argv to _TCHAR**.

If you’re not planning to ever support ANSI (probably not), you can reformulate your entry point as

int wmain(int argc, wchar_t *argv[])

and remove the tchar.h include line.