1

I have this code that I need to use, but what holds me back is that here it says that TerminateThread Applies to: desktop apps only. I wonder if I can use this code inside azure Worker role, specifically inside waiishost.exe process that I use to run the Worker thread in?

[DllImport("Library.dll")]
public static extern void InfiniteLoop();

[DllImport("kernel32")]
private static extern int CreateThread(
   IntPtr lpThreadAttributes,
   UInt32 dwStackSize,
   IntPtr lpStartAddress,
   IntPtr param,
   UInt32 dwCreationFlags,
   UInt32 lpThreadId
 );

[DllImport("Kernel32.dll", CharSet = CharSet.Auto)]
public static extern int TerminateThread(int hThread);

[DllImport("Kernel32.dll", CharSet = CharSet.Auto)]
public static extern int GetLastError();

private delegate int InvokeInfiniteLoop(IntPtr args);

static void Main(string[] args)
{
      InvokeInfiniteLoop invokeInfiniteLoop = (args1) =>
                                                    {
                                                        InfiniteLoop();
                                                        return 0;
                                                    };
     IntPtr infiniteLoopPtr = Marshal.GetFunctionPointerForDelegate(invokeInfiniteLoop);
     int handle = CreateThread(IntPtr.Zero, 0, infiniteLoopPtr, IntPtr.Zero, 0, 0);
     Thread.Sleep(TimeSpan.FromSeconds(5));
     int terminated = TerminateThread(handle);
     Console.WriteLine(terminated);
}

EDIT:

After further research looks like(as I suspected from the beginning) that this workaround is completely wrong. Creating and Terminating the unmanaged code will leak the stack. I will have to create a separate executable that will be terminated by Process.Kill();

user1561202
  • 145
  • 1
  • 9
  • Let me quote the docs: "TerminateThread is a dangerous function that should only be used in the most extreme cases." The docs are right! Please research this issue. – usr Aug 20 '12 at 20:40
  • @usr This is an extreme case. For more info see this: http://stackoverflow.com/questions/12022993/how-to-control-the-execution-of-an-externl-native-dll – user1561202 Aug 20 '12 at 21:12
  • Ok, but you're still taking a risk: If the native lib has taken a lock, or temporarily violated other state invariants, it will not be able to restore itself. Your process is hosed then. Just be aware what might be the result. – usr Aug 20 '12 at 21:19
  • After further research looks like(as I suspected from the beginning) that this workaround is completely wrong. Creating and Terminating the unmanaged code will leak the stack. I will have to create a separate executable that will be terminated by Process.Kill(); – user1561202 Aug 21 '12 at 02:33

1 Answers1

3

The "Applies to: desktop apps only" refers to the difference between Windows 8 Desktop application and Windows 8 Metro applications.

jcopenha
  • 3,935
  • 1
  • 17
  • 15
  • OK, but this does not really answer the question. – user1561202 Aug 20 '12 at 20:01
  • It does: it means you can call thse APIs just fine. Or better, just use .NET threading APIs... – Jason Malinowski Aug 20 '12 at 20:41
  • @JasonMalinowski Thanks for the comment, but what about docs saying that "TerminateThread is a dangerous function that should only be used in the most extreme cases"? How dangerous is it to terminate a thread running inside waiishost.exe? – user1561202 Aug 20 '12 at 21:17
  • It is dangerous to Terminate a thread running anywhere, not just in waiishost.exe. The thread could be holding locks, holding memory, be half way through a multi-step process leaving data in an inconsistent state. – jcopenha Aug 20 '12 at 21:46
  • @jcopenha OK I understand, BUT what should I do if the native call entered into an infinite loop and never returns? See: http://stackoverflow.com/questions/12022993/how-to-control-the-execution-of-an-externl-native-dll – user1561202 Aug 20 '12 at 22:35
  • @JasonMalinowski Or in other words you have no answer how to handle the crapware that your employer has produced. – user1561202 Aug 21 '12 at 01:12
  • 1
    @user1561202: The industrial way to deal with such cases is to run the crapware in a separate process and terminate that process should anything go wrong. – sharptooth Aug 21 '12 at 07:54
  • @sharptooth Sure, didn't you read the EDIT to the OP from 8 hours ago? Thanks anyway, it took me some time to figure out. – user1561202 Aug 21 '12 at 10:54