Project Description
I wrote a plug-in for a CAD system that batch translates CAD files. I want to be able to run the plug-in unattended. While processing the CAD files, user interaction is sometimes requested from the CAD program itself. Another guy I am working with on this project wrote a program using AutoIt to respond to the message boxes, and this is working for a majority of the situations encountered.
The plug-in is written in C++ using Visual Studio 2010, and the script program using AutoIt. The operating system is Windows 7.
Problem
Some CAD files will cause the CAD program to lock up. We attempted to overcome this by using the AutoIt program to check for "Not Responding" in the window title, then kill and restart the CAD program and plug-in and pick up where it left off. This works for files that are actually locking up the CAD program. The problem is that the "Not Responding" sometimes appears in the window title when the CAD program is just taking a long time to complete, and not actually locked up.
Current Work-around
The work-around we have come up with right now is to set a delay in the AutoIt program after the "Not Responding" appears, then check again before restarting the program. The problem is that it is just guess work on how long to set the timer.
Question
Now for my question. Is there a Windows API I can use to distinguish between when a program is actually locked up or just taking a long time? Or do I just have to live with setting the timer high enough where I think it will be enough to cover this situation?
Unfortunately becoming unresponsive is neither a necessary nor sufficient condition to consider a process locked-up. A good programmer could easily keep the UI responsive, while the algorithm thread has descended into an infinite loop.
Things to try:
Start creating a log of CAD file size shown again time it took to complete the conversion. This will quickly allow you to estimate the wait time for a given input size. In case this is correlated. This way you do not have to wait for ages if the CAD program locks up frequently on small input.
Observe the behavior of the CAD program, when it is locked up. Is it spinning the CPU (infinite loop) or dead-locked at a low CPU utilization (probably mutexes waiting for each other)? How about during a successful conversion? Is the CPU always maxed out or going up and down because interleaved IO happens? If you find a pattern of differences, then this might help you to distinguish still running from dead-locked.
Send failing CAD files to your CAD vendor and let them fix their code (haha, I know).