Unable to pass std::wstring across DLL

Question

I've set up a project in Visual Studio 2010 to write unit tests against an existing MFC DLL. I'm using a single-header unit test framework, and linked to the MFC DLL's lib wrapper from the unit test project. I'm trying to construct a class that takes a std::wstring in it's constructor. Here's what my test looks like:

TEST_CASE("MyProject/MyTest", "Do the test.")
{
    MockDbService mockDbService;
    Foobar foo(L"{F00DFACE-FEED-DEAD-BEEF-C0FFEEDECADE}", mockDbService);

    foo.loadObject();

    REQUIRE(mockDbService.getMethodInvokeCount("query()") >= 1);
}

Where Foobar is the class exported from the MFC DLL under test. However, the test framework reports an unexpected exception. I tracked it down to std::wstring's copy constructor when copying the string to Foobar's constructor. The MSVC debugger reports the source string as <Bad Ptr>.

I created a dummy constructor, Foobar::Foobar(long num, IDbService& db) and all the values (including the IDbService&) come across just fine.

Both the MFC DLL and my unit test EXE are sharing a property sheet which should keep the compiler flags equivalent. I'm building and running the test in debug mode. Any ideas why the std::wstring can't copy across the DLL?

Answer 1

You should check that both the EXE and the DLL are dynamically linked with the same debug CRT (/MDd compiler option). Make sure that also other settings like _HAS_ITERATOR_DEBUGGING are the same for both the EXE and the DLL.

(A shortcut could be to just use const wchar_t* instead of std::wstring at the class interface, and just build a std::wstring from the raw pointer inside constructor's body).

EDIT: You confirmed that CRT mismatch (i.e. EXE built with /MD vs. DLL built with /MDd) was the problem. The fact is that the same class name std::wstring means two different classes in debug builds (/MDd) and in release builds (/MD). In fact, in debug builds there can be additional mechanics inside the class implementation to help debugging; this mechanics can introduce inefficiencies, so it's removed in release builds. So, the internal structure of debug build's std::wstring is different from release build's std::wstring (e.g. if you try to print the raw sizeof of std::wstring instances, you can find different numbers in release builds and debug builds). So, the EXE built with /MD was expecting release-build's std::wstring; instead the DLL built with /MDd was expecting debug-build's std::wstring: there is a mismatch between these two expectations (one module is expecting class X but the other module is giving class Y) and so you have a crash.