how do I handle a dll function that does not return?

Hi,

I am using visual C++ ver 8.

I have written a application that calls a third party dll function that communicates to a connected embedded device via TCP/IP. This routine is ran around 14 times a second.

Two/three weeks or so in, my application stops working due to a non return in the dll and appears to get stuck in a internal loop in the third party dll. The application does not crash, but I do need to perform a manual closedown and a restart to gets things going again.

What is the best way to handle this? I know if I was using VB, I could maybe use a multi-threaded timer function to see if processing has stopped? However, I dont know how to do this in c++ or is is there a simpler method I could use?

As its a third party dll I cant debug their issue, but I should be able to handle it within my app..

I would appreciate your assistance?

VisionMan

Quote:

---

...get stuck in a internal loop in the third party dll.

---

Contact the vendor of the DLL and notify them of the problem. If you do not have the solution to re-build the DLL then you really cannot debug it, re-base it, or fix it.

Even if the problem is your usage of the DLL I would still contact them since no DLL should ever get stuck in an infinite loop under any error conditions. At best it is not correctly handling an error condition.

Hi Bubba,

Yes your correct. The dll should not be in an infinite loop in the first place. However, what is the manufacturers problem is now my problem.

It seems to take a few days before it gets lost internally. So I should be able to use a handler to find the delay which will keep my application running smoothly.

What I need to do is to find and handle the infinite loop. I would appreciate guidance or suggestions to how this can be done.

This is just a random guess from a C programmer who does NOT work with DLLs very much.

Is the DLL always loaded into memory?
If yes, it might have a slow memory leak that causes a crash.

If yes, It might be possible that using delayed loading or Explicit run-time linking of the DLL combined with unloading the DLL every few days might prevent the problem from happening.

http://en.wikipedia.org/wiki/Dynamic...n-time_linking

Tim S.

It is possible to do this, but it isn't a good solution.
You can create a separate thread for which to run the DLL function. Then wait for the thread to complete with a timeout with WaitForSingleObject. The return from the function indicates if the thread timed out or if it exited normally. If it timed out, you can kill the thread (eg TerminateThread). This will leak the stack for the thread, though, so it's not a really good solution.