in reply to ***Warning! The above post is wrong in almost every possible way***
in thread Kill a process in perl windows and proceed only if it killed the process
Sundial is somewhat correct. On all OSes, there are voluntary closes, and forced closes. On unix there are different signals and different kill -* numbers. On Windows there is WM_CLOSE message, or SetConsoleCtrlHandler (which under the hood is a csrss.exe getting a WM_CLOSE or a control C message), these 2 are voluntary. Then there is TerminateProcess which is forced.
TerminateProcess I know is privilage checked (not sure about how windows messages work). Also on NT Kernel, if a process did certain syscalls, (my specific experience is with NtCreateFile/CreateFile), a driver can freeze a thread, and absolutely nothing can terminate that process since NT Kernel runs a kernel mode APC (think unix signal) in each thread to terminate each thread and the process/PID disappears when the last thread is removed from the process, but the thread is stuck in a blocking synchronous IO call in a driver, the kernel can not preempt most kernel mode code (google IRQL) executing in a thread to schedule an APC. Basically, CreateFile is synchronous, the path driver UNC/My Network Places driver which implements "\\188.8.131.52\someshare" paths on NT is crap. This driver is called MUP, which is one of many MS schemes at user mode drivers. MUP connects to Workstation/COmputer Browser services, which does the actual socket IO from user mode. Why? Either MS decided kernel socket interface in the kernel is so difficult to use, or MS's My Network Places/Samba/CIFS implementation still uses DOS/16 bit code that was ported to 32 bits, but still has to be run in user mode. NT 6/Vista introduced a a couple new calls to cancel sync I/O in any thread from any thread, so perhaps this unterminatable process problems doesn't exist anymore in NT 6. When Explorer freezes for many seconds or file open freezes for many seconds when browsing network shares, blame CreateFile and MUP.