I don't know of any particular way to diagnose a problem like this "from a distance." Plainly, this program has some kind of dependency upon the user-interface, and it grinds to a halt because it's waiting for that resource.
One strategy that sometimes works is to spin the calculations off to a child-thread. This thread has no interaction whatsoever with the user interface: it is simply a computational loop.
But... if it "works fine on one workstation but not another," that is quite strange. Perhaps, though, the fact that "it works just fine over here" is, well, coincidence. Maybe the program's present design is vulnerable to this sort of problem, and "for some happy reason it doesn't happen over here."
If you can spin the calculations off to a purely CPU-bound child thread, then (any...) operating system dispatcher will quickly recognize it to be "a CPU-bound thread" that never waits on anything, and it ought to be given cycles no matter what the user-interface may be doing at any particular time.
Finally, I'm going to assume that the two workstations have a comparable amount of memory and so-forth ... that there are no "memory leaks," no resource-bugs of that sort ... that it is, in fact, "a good, clean program" that you can have confidence in.
Last edited by sundialsvcs; 03-20-2009 at 10:45 AM.