It might save you some time to know that you can not safely directly
export a class that inherits from a WTL object (eg, CDialogImpl,
CWindowImpl, CWindowImpl). Instead, either (easy
options starred):

1*Export only certain members and not the whole class (sidestepping
the issue without losing the benefits of centralizing code in a DLL)
2.Use a virtual interface class
3.Encapsulate your class’s functionality in exported global function
calls
4.Turn your class into a COM or activex object
5*Inline your class’s implementation so that it is compiled by the
DLL client and does not reside in the DLL itself (This option requires
special management of resources that reside in the DLL, if there are
any. Typically, only dialogs need resources. Your class needs to
know that it must retrieve resources from the DLL module and not, as
it would by default, the DLL client’s module)
6.Don’t bother putting your code in a DLL

You are probably exporting your WTL-based class in the wrong way if
you two conditions are true: you see (lots of) warning C4251 while
compiling the DLL and its client, and in debug configuration, your DLL
client bombs out in _CrtIsValidHeapPointer or _RtlFreeHeap. C4251 can
safely be ignored in most other circumstances, particularly when it
refers to STL types.

The cause of this issue: WTL is an inline library; therefore, its
classes do not specify DLL linkage. When you export a class that
inherits from another class, if that other class does not specify DLL
linkage, you also automatically export that class, too. Most WTL
classes ultimately inherit from CWindow and if you import a CWindow
implementation from a DLL, you get its compiled member functions.
These functions refer to resources residing in the DLL’s module. When
your local WTL objects need to call these functions, they’ll get the
versions imported from the DLL which look for resources in the wrong
module. This is considered harmful.