views:

105

answers:

1

I currently have my project running two separate threads (one for MFC operations, like views/formviews, application window, etc., and one for an infinite while loop in its main function). However, for certain situations, when I run my program in debug mode, I have noticed that one of the threads' exit status was a 1 (in other words, it returned a non-zero number to the operating system). While running the application in Visual Studio 2005, what would be easiest way of finding out which thread is responsible for the return value so that I can troubleshoot what's going on? Thanks in advance.

Incorporating Steve Gilham's suggestion:

After investigating which thread is responsible for the error by looking at Spy++, I have pinned down to the single line of hdlUninitDevice() call from Novint Falcon SDK being responsible for this return message. Returning a failure status from this call doesn't make an error message pop up. However, I don't know if this is a major deal that is essential to deal with on a larger context. It would be great to listen to more suggestions. Thanks.

A: 

How is the subordinate thread being terminated? My first thought is that if it is being shut down in a non-graceful fashion by the main thread exiting, that might cause the non-zero status.

At the very least, if you can decouple the time when the two threads finish, it might help tell which is returning which status.

Steve Gilham
The subordinate thread was suspended, then terminated, then the parent thread itself terminates. However, at times, I have noticed that there are other subordinate threads created without my knowledge (perhaps created by usage of timers). How would I tell which subordinate thread is being terminated with a non-zero status based on its win32 thread number?
stanigator
That I don't know, nor is it immediately obvious via Google; however the MSDN article on terminating a process might be a starting point for tackling the wider issue. http://msdn.microsoft.com/en-us/library/ms686722%28VS.85%29.aspx
Steve Gilham
Thanks. I'll take a look at the article.
stanigator