I've experienced a strange problem calling my own DLL function from TeleFlow.

The DLL is developed using VC++ 6. During the development phase the DLL was compiled using Debug Build. TeleFlow can call the exported functions nicely without a glitch. But when the development is finished, I compiled the DLL using Release Build. Then TeleFlow starts giving me the following error from time to time. Sometime the function can be called successfully but sometime not. The odd is around 50%.

10F439B: EXCEPTION_ACCESS_VIOLATION attempting to read at location EF77AC.

I spent a while to figure out the offending setting in VC++ 6. In Release Build, if I change "Use run-time library" to "Debug Multithreaded DLL", no more errors from TeleFlow, just like the debug build. But as soon as I change it back to "Multithreaded DLL", the exception will come back.

I wrote a simple VC++ application to call the same DLL function in Release Build but found no similar issue. It seems only TeleFlow is affected.

Anyone has a clue?

Not really, but maybe we can sort this out with some investigation.

First of all, what version of TeleFlow are you using? Please run the TeleFlow Register program to get the build number (Start -> Programs -> TeleFlow -> Server Tools -> TeleFlow Register).

Secondly, which TeleFlow program are you using to test your DLL, TF Simulator? or TF Server?

The version is Build 2009.11.24 and I'm using TF Simulator. Really appreciate your assistance.

Seems like I've finally found a workaround for my problem. To isolate the problem, I've written a really simple DLL function using VC++ 6.0. The function simply return the string provided by the parameter.

__declspec(dllexport) LPSTR IVR_GetProfileString(LPCSTR szParam) {
LPSTR szReturn;
szReturn = new char[sizeof(szParam)];

lstrcpy(szReturn, szParam);
return szReturn;
}

The DLL was then compiled with the default release build options. I then use TeleFlow to call this function repeatedly in a loop. I got more than 50% crash rate with the EXCEPTION_ACCESS_VIOLATION.

However, if I modify the function slightly like this:

__declspec(dllexport) LPSTR IVR_GetProfileString(LPCSTR szParam) {
LPSTR szReturn = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX";

lstrcpy(szReturn, szParam);
return szReturn;
}

Then the TeleFlow loop runs with 100% success rate. The only difference is the method of allocating memory for the return string. Whenever I use dynamic allocation, TeleFlow will crash.

Actually according to the TeleFlow log, it can get the return value from the DLL function before it crashs. So it seems the crash is caused when TeleFlow tries to deallocate the memory of the return string. Of course, it's only my guess but I hope this can help you with your investigation.

Anyway, I'll stick with this method before there's a real alternative.

That's an interesting find! I believe it will help with our investigation. Thank-you.