1

I know there is no WINAPI which would do it, but if a thread is hung and holds an open handle of file. how do we determine the thread id and Terminate it within our processes.

I'm not talking about releasing file locks in other processes but within my own process.

it could also be possible that thread has crashed / terminated without closing the handle.

AppDeveloper
  • 927
  • 11
  • 21
  • Does the thread block during file processing in certain circumstances or every time? – ChadNC Nov 10 '09 at 18:59
  • well its under certain circumstances, but in separate area I've to delete that file, but it gets access denied error since i know its my own process, if I can figure out the thread, I can terminate it or close handle or even figure out for debugging which thread and why.. – AppDeveloper Nov 10 '09 at 19:07
  • You should never call TerminateThread, see http://stackoverflow.com/questions/1004676/how-to-terminate-a-hanging-thread-inside-a-dll-correctly/1004684#1004684. – Michael Nov 10 '09 at 19:22
  • it depends. for example if you used mutexes the ownership transfers. although i agree its not generally safe but I don't think never is the right statement. – AppDeveloper Nov 10 '09 at 19:30
  • @SnapConfig - you can only safely kill a thread if you can guarantee it is executing in code you control and that its termination will have no side-effects. If it is inside any code provided by a library or the OS, you cannot reliably terminate it. The only clear safe case is if the thread is created suspended and hasn't started running yet. – Michael Nov 10 '09 at 19:55

4 Answers4

1

You cannot determine which thread holds an open handle to a file. Nearly all kernel handles, including file handles, are not associated with a thread but only with a process (mutexes are an exception - they have a concept of an owning thread.)

Suppose I have the following code. Which thread "owns" the file handle?

void FuncCalledOnThread1()
{
     HANDLE file = CreateFile(...);

     // Hand off to a background thread.
     PostWorkItemToOtherThread(FuncCalledOnThread2, file);
}

void FuncCalledOnThread2(HANDLE file)
{
       DoSomethingWithFile(file);
       CloseHandle(file);
}
Michael
  • 54,279
  • 5
  • 125
  • 144
  • Good point. though i did find some source for enumerating handles just for someone else's reference. http://forum.sysinternals.com/forum_posts.asp?TID=18892 – AppDeveloper Nov 11 '09 at 21:34
0

Use Process Explorer - http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx [edit, or Handle - http://technet.microsoft.com/en-us/sysinternals/bb896655.aspx ]

andrew cooke
  • 45,717
  • 10
  • 93
  • 143
0

You could attach to the process with the debugger when this happens, pause the program, search for the thread that caused this, and, traversing the stack, find out what it's doing, which code it executes, and which variables are on the stack.

If you used RAII for locking, this should be enough, as the lock must be on the stack.

sbi
  • 219,715
  • 46
  • 258
  • 445
  • I can't its on customer machine where they would not let us debug it. :(.. aaaah RAII its 1.5 mil lines of code written over 10 years :).. I"m just fixing it.. – AppDeveloper Nov 10 '09 at 19:10
  • You're a hero. I once worked in a several MLoC C++ project which, in its kernel, was ten years old, too. But that was decent C++ even in the oldest parts (and good in newer ones). Anyway, the only ways I have found out of MT bugs are logging, logging, and logging. – sbi Nov 10 '09 at 19:52
0

I haven't seen anything browsing MSDN, although there's certainly something perhaps undocumented out there that can give you the information you need.

If your threads are creating these resources, and there's an expectation that one of these threads might go out to lunch, would it make more sense for them to query resources from a utility thread who's sole job is to create and dispose of resources? Such a thread would be unlikely to crash, and you would always know, in case of a crash, that the resource thread is in fact the owner of these handles.

Doug T.
  • 64,223
  • 27
  • 138
  • 202