Call kernel32.dll "TerminateProcess" without effect

[Bluegraf]

Hi all,

I'm calling kernel32.dll "TerminateProcess" with the call Library function in LV2012 (Run in any thread, stdcall, void  TerminateProcess(uint32_t hProcess, uint32_t uExitCode);, maximum error checking) with hProcess retrieved from Store Process Handle in TestStand (this gives a Windows-Handle so I guess it should work in any Windows Task).

I get no error message but also no functionality. The program I want to close stays happily open. Previously I called the same kernel32 function from TestStand where it worked as expected. But I need the funtionality in a VI, not in TS.

Tests with different parameter representations and by value/by ref didn't have any effect.

Any Ideas what else I could try?

[rolfk]

hProcess [in]

A handle to the process to be terminated.

The handle must have the PROCESS_TERMINATE access right. For more information, see Process Security and Access Rights.

You can't just go and randomly kill processes in a multi user environment like Windows. The process handle must have been opened with above mentioned access right, but many access rights are restricted from normal users, so it may be also a question under which credentials the process runs in which you want to open the process handle. And no, a handle opened in one process (here TestStand) does not automatically give another process (LabVIEW) the same rights to use it. You should open the process handle explicitly in LabVIEW when you want to use it there.

Besides, a HANDLE should be always configured as Pointer Sized Integer, in this case passed as value.

[Bluegraf]

I'm only killing in self defense 😉
> You should open the process handle explicitly in LabVIEW when you want to use it there.

Unfortunately "System Exec.vi"doesn't provide me with a handle. I'll try and use Kernel32.dll CreateProcessA. Then the handle is created by LabView as well.

Or I might go back to the old method and start with System Exec.vi and use

taskkill /IM "MyProgram.exe" /T /F

to axe-murder it again.

[rolfk · Accepted solution]

TerminateProcess() is just as much an axe-murder as taskkill. Basically taskkill simply is a command line tool that eventually calls TerminateProcess() so nothing really gained by going the direct WinAPI route, except that calling one or two WinAPIs is several ms faster than creating the taskkill process.

But hey, how many thousand times per second do you plan to kill a task?

[Bluegraf]

I read through the CreateProcess description in MSDN and decided to stay with the old fashioned axe. CreateProcess has way to many parameters I don't really understand to find it enjoyable to play around with it just to learn the details.

Besides... after axe-murdering the task I expect the computer to be shut down soon anyway in most cases. That will dispose of any messy leftovers.

Thanks for the help!

[zou]

It's a lot easier to use .net framework to create and PROPERLY end a process, than to terminate a process.

[rolfk]

---

@zou wrote:

It's a lot easier to use .net framework to create and PROPERLY end a process, than to terminate a process.

---

As far as terminating a process from anywhere else than itself, I doubt that .Net has any advantage over any of the other approaches in terms of properly shutting down. .Net at least on non-Windows RT platforms does not reinvent the Windows kernel and its process model. This means that in order to to deal with processes, it has to use the same Win32 API interfaces that anyone else does, and that would mean to call ultimately TerminateProcess() too when you want get rid of a different process.

[zou]

With .net framework, you can get the handle of the main window of the process.  So you don't have to call terminateProcess, just close the main window will do most of time.

[rolfk]

Well retrieving the window handle of a top level window through WinAPI isn't really difficult either and sending it a WM_QUIT through PostMessage() even easier. However that assumes that your external program is a GUI process and not a CLI and also that it properly implements the WM_QUIT functionality, although if it doesn't it is really broken.