Visual Studio /analyze build warns me that I'm leaking PROCESS_INFORMATION.hProcess after starting a background process with CreateProcessA. I don't need to wait for that process, and it will exit on its own when it is time. Is there something I should do with hProcess in that case?
This is /analyze result C6335
All you have to do is call CloseHandle once you no longer care about it, which, in your case, sounds like right after you create the process.
You might be worried that this would prematurely terminate the process, but it won't. The process also holds a handle to itself. The OS won't destroy the process object until the last handle to it is closed.
Related
Related to a question I asked here -- I have a process that I launched which is in a "suspended" state. I cannot kill or resume this process through any of the normal means (process explorer, task manager, WinDbg).
Logging-out of my session DOES kill this process though. How? What mechanism is the OS using when I log out that is somehow different to what Process Explorer is trying to do?
Edit: To clarify - I am assuming that Process Explorer is calling the TerminateProcess API function when it tries to kill a process. Something in the process state is stopping this from working though. Logging out obviously invokes some different behaviour and Windows ignores whatever was blocking TerminateProcess, and kills the process due to my session ending.
As a user, is there any different way to try and terminate a process other than calling the TerminateProcess API?
Process Explorer can't kill a process itself; it can only ask the OS to do so. The OS itself doesn't have to play by its own rules.
Remember, it's the OS itself which defines what a process is. It might very well define a process as part of a logon session. This would imply that if you clean up the whole session then you don't need to clean up individual processes. Just like you don't need to bother with CloseHandle before ExitProcess either.
I'm working with CreateProcess to run a process/application of mine.
The purpose is to run it, do something, wait for some indication, and close it (Using TerminateProcess).
What I noticed is that this application/process creates sub-processes.
Additionally, when terminating the created process, the sub-processes do not terminate, and still remain for a period of time.
I wanted to ask if there's an option to somehow kill all the sub-processes with the main process.
It causes issues, since when I do CreateProcess again, there are leftovers from previous processes, and I think they're causing some issues.
I really appreciate your help!
Use Windows Job Objects. Jobs are like process groups; the operating system will take care of terminating all processes in the job once the job leader (your initial process) is terminated. This even works if the proess leader crashes.
When you create a process using CreateProcess you'll get a LPPROCESS_INFORMATION-pointer.
It contains the process handle. You'll need to close the processes manually, as there is no such thing as a process hierarchy as in Linux/Unix.
See here for CreateProcess and here for the PROCESS_INFORMATION-structure.
I've got a program that calls SetClipboardViewer at startup to register for clipboard change notifications. At shutdown time, it will call ChangeClipboardChain to remove itself from the chain correctly.
This is all great as long as the program runs normally. But that's got me wondering, what happens if the program gets aborted, either by me killing it under the debugger, by a crash, or by the user killing the process because something went wrong? Then the cleanup never happens. Can that cause trouble for the system somehow?
Specifically, I know Windows can remove my viewer without trouble because it's a handle and Windows can clean up all handles when a process terminates, but will this cause the next value downstream in the chain, that I was holding a reference to, to get lost somehow?
Yes, failure to remove yourself from the chain will break the chain. Deadly sin #2. Please read the whole list to be sure that you're following all of the rules.
http://www.clipboardextender.com/developing-clipboard-aware-programs-for-windows/6
Lots of apps suffer from this, including the Delphi IDE. i.e. if Delphi crashes in certain ways, it'll kill the clipboard chain (D2005 anyway).
Consider using Vista style notification on Vista/Windows7.
I am writing a C# application that, among other things, automatically closes the advertisement a certain game displays after the user exits the game. My program accomplishes this by killing the game process when it detects that the user has exited the game. My program is similar to an Autohotkey script written by someone else that does similar things but it adds some features and a GUI.
Naturally, I used the Process.Kill method. However, that would fail with an "Access is denied" exception. I noticed that the Autohotkey script uses an unusual method of killing the process. I asked the author about it, and he said that he too had trouble killing the process with normal methods.
We suspect the reason normal process termination methods do not work is the HackShield software the game uses to attempt to combat cheating.
Here is the Autohotkey code the other guy's script uses for killing a process:
; kills all process instances of a given executable name
; COM AutoHotkey library code omitted
KillProcessInstances(exe)
{
psvc := COM_GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")
pset := COM_Invoke(psvc, "ExecQuery", "Select * from Win32_Process Where Name = '" exe "'")
penm := COM_Invoke(pset, "_NewEnum")
Loop, % COM_Invoke(pset, "Count")
If COM_Enumerate(penm, pobj)=0
{
COM_Invoke(pobj, "Terminate")
COM_Release(pobj)
}
COM_Release(penm)
COM_Release(pset)
COM_Release(psvc)
}
I replaced the Process.KIll with the WMI calls in my program using the System.Management namespace and my program is now able to kill the process.
What I don't understand is what makes the WMI any different from Process.Kill. I would expect both to work or both to fail. In addition, Task Manager is able to kill the process just fine, but I would think it just uses a TerminateProcess win32 call just as Process.Kill surely does. Can anyone shed some light on the cause of the different behavior? If it matters, I'm running Windows XP.
Edit: wj32 explained why the WMI works, but can anyone explain why I can kill the process with Task Manager but not with my own program?
WMI calls are not performed within the security context of your process. They are handled in another process (I'm guessing the Winmgmt service). This service runs under the SYSTEM account, and HackShield may be allowing the termination continue due to this.
We've got issues with our program potentially hanging in certain situations, is there a way to search and destroy your own program with windows calls without using task manager. It probably wouldn't make sense to include this in the program itself, but as a bundled thing no one would see.
What's the best way to go about doing this, how deep do I need to dig to stop my program and how shallow should I keep to make sure I don't crash the OS?
You could create a .bat file and put a Taskkill command in it to forcefully terminate your application. The command would look something like this:
taskkill /f /im notepad.exe
Although you should probably fix the situation in which it hangs, one way you could have the program kill itself is to spawn a new thread when you launch the app, and have that thread poll the application and kill it if necessary.
Killing a thread in windows.
One option would be to write a Windows Service that serves as a Watchdog. You could find your program by it's .exename and then you need some way to determine if it hangs (for example some simple Inter-Process-Communication or even a Client/Server thing) and restart it if necessary.
That is hardly "no one would see" though.
You can terminate a process using TerminateProcess. You'll need to determine the target process id using EnumProcesses and then call OpenProcess to obtain a handle to the process in order to terminate it.
You can enumerate running processes using the EnumProcesses() function. This will let you search for the process name, and get the PID. With the PID, you can open a HANDLE to the process which you need in order to call TerminateProcess() to kill the hung process.
There's an example of how to use EnumProcesses on MSDN.
Some pseudo-code might look something like:
EnumProcesses(pidArray, sizeofArray, &bytesReturned);
for(int i=0; i < bytesReturned/sizeof(DWORD); i++) {
if(getProcessName(pidArray[i]) == "ourProcess"){
HANDLE hProc = OpenProcess(PROCESS_TERMINATE, FALSE, pidArray[i]);
TerminateProcess(hProc, 0);
}
}
What about implementing something from the pstools of sysinternals ?