MFC in Max External

Jul 30, 2013 at 9:10am

MFC in Max External

I’m trying to implement some existing code into a Max external which uses MFC. I know that ‘windows.h’ is already included in the Max SDK, and these two aren’t supposed to be used together.

Basically, am I wasting my time on this? I’m including ‘stdafx.h’ first to avoid errors due to use of ‘windows.h’, but am now getting the following error:

error LNK2005:_DllMain@12 already defined in dllmain_win.obj

Is there a fix for this? Will this ever work?

Jul 31, 2013 at 7:19am

I’m not an MFC expert, but I understand that it provides some kind of default application framework. And any application framework is going to have a main(). But your external also has a main(). You can’t have two functions named main() (which is what your linker is complaining about).

You may be able to avoid this by carefully selecting what libraries are linked in. Dunno.

Using MFC is likely to kill any chance of cross-platform compatibility, but you presumably don’t care about that.

Jul 31, 2013 at 8:49am

MFC provides its own DllMain. The max externals in the SDK also provide their own DllMain. Hence, your external has two and you are getting this error.

The good news is that the DllMain provided in the max sdk samples doesn’t actually do anything except for a small optimization that you probably don’t even want if you are using MFC. So to fix this problem you can probably just remove dllmain_win.c from your project.

Hope that helps,

Jul 31, 2013 at 9:02am

Thanks Rob. I’ve removed dllmain_win.c.

Unfortunately I’m now getting:

error LNK2005: _DllMain@12 already defined in MSVCRTD.lib(dllmain.obj)

Jul 31, 2013 at 9:12am

Interestingly for a release build I instead get:

error LNK2005: _DllMain@12 already defined in maxcrt.lib(dllmain.obj)

Jul 31, 2013 at 9:18am

Sounds like the link order is not correct so there is a conflict between MFC and the MS CRT.

Googling the above error brings up plenty of articles that may be helpful for you including this MS KB article:;en-us;q148652

But one page suggests this simple fix:

In most cases it its sufficent to place the #include as the first header file that is included in the stdafx.h.

And, once you go to get your release build working I suggest you add this preprocessor flag to your project settings:


This will cause your object to link to the standard microsoft CRT rather than the shared maxcrt.dll that we ship with max. You can see what that switch does by looking in ext_prefix.h.


Jul 31, 2013 at 9:20am

Our posts crossed in the air. You said:

Interestingly for a release build I instead get:

error LNK2005: _DllMain@12 already defined in maxcrt.lib(dllmain.obj)

Yes, my prior post anticipated this. :) Once you add MAXAPI_USE_MSCRT to your project you will get an error more similar to the debug one.


Jul 31, 2013 at 9:51am

OK, this seems like a non-Max related error now. Currently I am including stdafx.h first, so will have to investigate…

Jul 31, 2013 at 10:09am

Found a solution on

Suppress default library for the offending .obj file. Use /Zl for the .cpp file: C/C++ Advanced | Omit Default Library Name – Yes (/Zl). The results in the .obj file without any default library records. Therefore, linker would follow default libraries and their order from other .obj files, and hopefully they are correct in the sense of an MFC application. If the offending .cpp file relies on other default libraries for its own right, if /Zl is used on it, we have to add back explicitly those libraries to linker options.


You must be logged in to reply to this topic.