http://blogs.msdn.com/yunjin/archive/2004/01/30/65386.aspxI've seen people calls OS's ExitThread in managed applications via PInvoke to exit a managed thread, like this: [DllImport( "Kernel32.dll")] public static extern void ExitThread(int exitCode); public static void Run () { ... // calling OS's ExitThreaden-USCommunityServer 2.1 SP1 (Build: 61025.2)http://blogs.msdn.com/yunjin/archive/2004/01/30/65386.aspx#65667Sat, 31 Jan 2004 23:28:00 GMT91d46819-8472-40ad-a661-2c78acb4018c:65667Justin RogersI'd say yes, it is almost always a mistake. However, there are circumstances where a managed thread becomes unusable or the Abort method doesn't work or takes a long time to actually clean up the thread. I know there are certain types of stack overflow conditions under V1 and V1.1 that caused this situation to occur and you have to use a PInvoke to kill the thread. Unfortunately managed threads aren't nearly as robust as native threads.http://blogs.msdn.com/yunjin/archive/2004/01/30/65386.aspx#69136Sat, 07 Feb 2004 06:27:00 GMT91d46819-8472-40ad-a661-2c78acb4018c:69136Yun JinVery interesting point. Indeed V1 and V1.1 ARE not reliable in face of OutOfMemoryException and StackOverflowException. I could imagine that you might have trouble to unwind a thread appropriately under such conditions. Improving robustness is an important goal for Whidbey. In Whidbey, big efforts are invested to handle OutOfMemoryException and StackOverflowException in every corner of CLR. Chris Brumme has several great posts about this topic in his blog. <br>When Whidbey is shipped, it's supposed to be reliable enough to run in SQL server. So I hope your problem would be solved then. :)http://blogs.msdn.com/yunjin/archive/2004/01/30/65386.aspx#6524854Mon, 26 Nov 2007 05:56:54 GMT91d46819-8472-40ad-a661-2c78acb4018c:6524854ExitThread() in managed program?<p>PingBack from <a rel="nofollow" target="_new" href="http://feeds.maxblog.eu/item_1082414.html">http://feeds.maxblog.eu/item_1082414.html</a></p>