I'm trying to write a program which executes make.exe from MinGW distribution in the current directory and makes use of its STDOUT data and exit code. I have a handle to process STDOUT where I fetch data from, created with CreatePipe. When I get an ERROR_HANDLE_EOF on that pipe I assume the pro开发者_StackOverflow中文版cess has exited and try to get its exit code:
if(session->pid == 0) return;
HANDLE hp = OpenProcess(PROCESS_QUERY_INFORMATION |
PROCESS_TERMINATE, TRUE, session->pid);
if(hp == NULL) {
printf("OpenProcess(%i) failed, error: %i\n",
session->pid, (int)GetLastError());
return;
}
My code works on all other MinGW utilities I tested (like pwd, ls, etc.), I get the STDOUT and the exit code with no problem. But when I try it on make, the above code displays the following message:
"OpenProcess(2032) failed, error: 87"
I googled for error code 87, and it says "Invalid parameter". I don't see what could be invalid about a positive process id like 2032. Any ideas?
You should use the handle from CreateProcess
instead of using OpenProcess
on the PID.
OpenProcess
only works if the process object still exists. By the time you call OpenProcess
if the process object is gone - the result is a call with invalid parameter.
The success you got with other utilities is either due to a race condition (which may fail some times) or you kept the original handle to the child process open.
Leaving a tip for someone else's purpose. I managed to reach the ERROR_INVALID_PARAMETER (87)
by trying to open:
- a System process (0)
- an ID which belonged to a thread, not the process (reference to YatoDev's post).
The second case may be a problem when you e.g. claim a result from GetWindowThreadProcessId
directly, which is an identifier of the thread that created the window
, instead of its pointer parameter (which gives you requested PID).
Although the post is old: I noticed that I got ERROR_INVALID_PARAMETER
when the process existed, but owned by different user and/or Windows desktop and/or terminal server session.
Strange enough, the WTSEnumerateProcess()
function does not suffer from this error, but is much more expensive, especially on a system that is already under heavy load with many processes (and a call my even exhaust windows kernel resources).
So, it is not possible to make a 'real' invalid parameter provided and access errors. I would have expected ERROR_ACCESS_DENIED
instead (but a task manager invoked as regular/non-elevated user still shows all processes).
Look like some inconsistencies in Windows?
精彩评论