Question

I finished my small application and I am trying to make sure I have no memory leaks and no bugs. After looking at my Output I noticed that one of my functions is throwing a First-Chance exception, yet the function works great and does not crash.

The function calls another function in a CLR C++ DLL. I removed almost all code in the DLL function just for a test and the exception is still thrown so I know it is my EXE function that is the issue.

This is the code for the EXE function to call the DLL function.

LPCTSTR CHAXC0RDlg::Encrypt(LPCTSTR strValue)
{
    const char* Return;
    HINSTANCE hDLL = LoadLibrary(L"Library.dll");

    if(hDLL)
    {
        FARPROC hMethod = GetProcAddress(HMODULE (hDLL), "Encrypt");

        if(hMethod)
        {
            typedef const char* (*FunctionSig)(LPCTSTR);
            FunctionSig MethodCall = FunctionSig(hMethod);

            Return = MethodCall(strValue);
            FreeLibrary(hDLL);
        }
    }

    return _tcsdup(CString(Return));
}

This is the DLL function (as you can see I removed all code except for the code that generates a return value just as a test):

const char* Encrypt(LPCTSTR strPValue)
{ 
    String^ strValue = gcnew String(strPValue);
    string strReturn = (const char*)(Marshal::StringToHGlobalAnsi(strValue)).ToPointer();

    char* csValue = new char[strReturn.size()];
    strcpy(csValue, strReturn.c_str());
    return const_cast<const char*> (csValue);
}

The EXE function throws the exception on “const char* Return = MethodCall(strValue);” (I enabled breaking on this exception that is how I know).

Why exactly is this function throwing this exception?

Thank You!

EDIT

Update: My Character Set is UNICODE.

Update #2: From what I read in the suggestions and answers you are assuming this code does not work but it does. I enabled break on first-chance exceptions (and yes I do know what a first chance exception is) because I wanted this program to be good quality with all bugs gone. The code runs fine, I just wanted to figure out why the first-chance exception is being thrown because I like to be a better programmer. So I would like to fix this.

Update #3: I now have my code checking the values of hDLL and hMethod and both are not null when running this function. The problem seems to be in the call it self to the DLL. I am assuming the function signature is 100% correct for this code does work, it just throws a first-chance exception.

Update #4: I added the new changes to my function above as well added the DLL function code. The DLL function is a CLR C++ DLL. I removed all code in the DLL function as I stated already to make sure it was not my DLL.

Answer 1

It isn’t clear from the snippet but it looks like you used __declspec(dllexport) on a managed function written in C++/CLI. The String^ and the Marshal class make that unequivocal.

Running managed code in an application that’s otherwise entirely native is possible but it requires loading and initializing the CLR. There are a couple of ways to do that, I’m guessing you found the easiest way by chance. Using __declspec(dllexport) on a managed function forces the compiler to emit a stub that takes care of ensuring that the CLR is initialized and making the native-to-managed code transition.

So yes, the first time you call this exported function a wholeheckofalot of code executes behind your back. That’s the time that the stub needs to load and initialize the CLR and load the assembly that contains your managed code. Seeing this code throwing and handling an exception isn’t anything to worry about in general. There’s little you can do about it anyway, you don’t have the source code for this. You can make it less of an accidental event by hosting the CLR yourself. That takes a chunk of COM code, not so sure it is worth the cost.

From the clear evidence you provided that this doesn’t actually cause a problem, this is feature, not a bug. Do note that you can trigger a real, unhandled exception with this kind of code. If the managed code throws a managed exception, it is common in managed code, then you’ll get hammered by a Windows SEH exception with exception code 0xe0434f4d. That’s invariably bad, you can use the __try and __catch keywords to catch it but you can’t get a decent diagnostic for it since all the info about the managed exception is gonzo by the time the stack unwinds back to your code.