GenerateConsoleCtrlEvent() does not work on child process
Alex Oren
I have a problem sending a GenerateConsoleCtrlEvent() to a child process with a new
console. Doesn't matter if the CTRL_BREAK_EVENT or the CTRL_C_EVENT is sent, the process
just keeps running.
Here's the source of a test program:
int main()
{
BOOL rc;
STARTUPINFO si = { sizeof (STARTUPINFO) };
PROCESS_INFORMATION pi;
rc = CreateProcess(NULL, "loop.exe",
NULL, NULL, FALSE,
CREATE_NEW_CONSOLE | CREATE_NEW_PROCESS_GROUP,
NULL, NULL,
&si, &pi);
Sleep(2000);
rc = GenerateConsoleCtrlEvent(CTRL_BREAK_EVENT, pi.dwProcessId);
WaitForSingleObject(pi.hProcess, INFINITE);
CloseHandle(pi.hThread);
CloseHandle(pi.hProcess);
return 0;
}
loop.exe is a simple console program that outputs 10000 lines to the screen and
terminates.
Manually hitting Ctrl-Break on the console of loop.exe works OK.
Omitting the CREATE_NEW_CONSOLE flag from the CreateProcess() call works too but the
problem is that I *have* to use a separate console in the real app.
Suggestions please.
Thanxalot!
Have fun,
Alex.
--
My email address is intentionally mangled to foil spambots.
Please remove the "---filter---" from the address for replying.
Sorry for the inconvenience.
Tomas Restrepo
The docs clearly state:
"The GenerateConsoleCtrlEvent function sends a specified signal to a console
process group that shares the console associated with the calling process.
...The process group includes all processes that are descendants of the root
process. Only those processes in the group that share the same console as the
calling process receive the signal. In other words, if a process in the group
creates a new console, that process does not receive the signal, nor do its
descendants. "
which means it'll never work the way you want it to.
--
Tomas Restrepo
win...@bigfoot.com
http://members.xoom.com/trestrep/
Alex Oren <alexo@bigfoot---filter---.com> wrote in message
news:37066a9d....@news.netvision.net.il...
Alex Oren
} The docs clearly state:
} "The GenerateConsoleCtrlEvent function sends a specified signal to a console
} process group that shares the console associated with the calling process.
} ...The process group includes all processes that are descendants of the root
} process. Only those processes in the group that share the same console as the
} calling process receive the signal. In other words, if a process in the group
} creates a new console, that process does not receive the signal, nor do its
} descendants. "
}
} which means it'll never work the way you want it to.
Bummer. In that case how do I duplicate the functionality of an IDE (e.g., visual studio)
that runs tools in hidden console windows (with I/O redirected to pipes) but can stop them
while running (e.g., "stop build")?
Have fun,
Felix Kasza [MVP]
> In that case how do I duplicate the functionality of an IDE
> (e.g., visual studio) that runs tools in hidden console
> windows (with I/O redirected to pipes) but can stop them
> while running (e.g., "stop build")?
You remember their process handle and PID. Then, search for a window
owned by that PID and try sending WM_CLOSE. Or, if the process doesn't
have a window, you do a VirtualAllocEx(), WriteProcessMemory(),
CreateRemoteThread() to copy a thread function of yours into the process
and run it; that function would just call GenerateConsoleCtrlEvent(). If
that still doesn't convince the victim to surrender, you stand it up
against a wall and TerminateProcess(0 it.
--
Cheers,
Felix.
If you post a reply, kindly refrain from emailing it, too.
Note to spammers: fel...@mvps.org is my real email address.
No anti-spam address here. Just one comment: IN YOUR FACE!
Alex Oren
} Alex,
}
} > In that case how do I duplicate the functionality of an IDE
} > (e.g., visual studio) that runs tools in hidden console
} > windows (with I/O redirected to pipes) but can stop them
} > while running (e.g., "stop build")?
}
} You remember their process handle and PID. Then, search for a window
} owned by that PID and try sending WM_CLOSE.
The process only has a (hidden) console window.
I don't think it will work with, say, NMAKE.
} Or, if the process doesn't
} have a window, you do a VirtualAllocEx(), WriteProcessMemory(),
} CreateRemoteThread() to copy a thread function of yours into the process
} and run it; that function would just call GenerateConsoleCtrlEvent().
Sounds contrived. Is it safe?
} If that still doesn't convince the victim to surrender, you stand it up
} against a wall and TerminateProcess() it.
Yuck!
How about running an intermediatory console app that will do the actual CreateProcess()
and GenerateConsoleCtrlEvent() calls? Only thing left to decide is how to communicate
between the main and the intermediatory apps.
Thanx.
Felix Kasza [MVP]
> } Or, if the process doesn't
> } have a window, you do a VirtualAllocEx(), WriteProcessMemory(),
> } CreateRemoteThread() to copy a thread function of yours into the process
> } and run it; that function would just call GenerateConsoleCtrlEvent().
>
> Sounds contrived. Is it safe?
When NT decides to hand you a console ctrl event, it does so by calling
CreateRemoteThread() and calling your HandlerFunction(). What is sauce
for the goose, is sauce for the gander.
J Decker
> Alex.
> --
> My email address is intentionally mangled to foil spambots.
> Please remove the "---filter---" from the address for replying.
> Sorry for the inconvenience.
No CreateRemoteThreads required :)
J