I have a program that launches a child process.
When the child process crashes I would like there not to be a debug message box. I would like to do this without writing anything in the child process.
I am running this on windows 7.
In the createProcess function, in the flags parameter I only put CREATE_NEW_CONSOLE.
During my attempts, I put SetErrorMode(SEM_FAILCRITICALERRORS|SEM_NOGPFAULTERRORBOX) in the child process and made it crash, there was no dialog box. Now I put the same function call in the parent program before I called create process, and made the child program crash, now the message box appeared.
What should I do differently?
have you set CREATE_DEFAULT_ERROR_MODE in process creation flags?
Related
We have an old MFC-based C++ gui app (Visual Studio 6.0) which often does not terminate correctly. So I would like to be able to use a instruction like "abort();" to immediately end it.
However, the abort() instruction causes a dialog box to pop up, rather than ending immediately. Using "exit(int)" doesn't work.
Is there a way to eliminate the abort dialog, or is there a better termination method?
One obvious way to abort without anything else happening ahead of time would be for it to call the Windows ExitProcess function:
ExitProcess(exitCode);
If you want to kill it from some external program, you'd do that with TerminateProcess. To do that, you'll need a handle to the process, which typically means getting its process ID. If you're doing this from a program that spawned the one you want to kill, you'll probably get a handle to it when you create it. Otherwise, you'll probably need to use something like FindWindow to find its window, then GetWindowThreadProcessId to find the ID of that window's process. Once you have that, you call OpenProcess to get a handle, and finally TerminateProcess to actually kill it.
If it is a dialog box based app, then you can use EndDialog(IDOK) method.
Using Visual Studio 2017.
I use
siStartInfo.dwFlags &= STARTF_USESHOWWINDOW;
siStartInfo.wShowWindow = SW_HIDE;
to create a child process (through CreateProcess()) with a hidden window. It works perfectly.
What I would like, if at all possible, is to be able to toggle the visibility status of the child process' window, post-creation, from the main program on demand (with a press of a button, for example). I want to control the child process' window visibility without relaunching it through CreateProcess().
Modifying the child process code is not an option - it can be many different programs with not necessarily available source code.
Thanks in advance.
If you know a unique window class or title of the child process, you can use FindWindow() to find that window.
For a more generic approach, use EnumWindows() to enumerate all top-level windows. For each window call GetWindowThreadProcessId() to check if it belongs to the child process.
Call ShowWindow() to toggle visibility.
I have written a simple win32 program say abc.exe.
I have added a button in it, clicking on which an external exe say xyz.exe should start.
But the original program i.e. abc.exe should be inaccessible while xyz.exe is running. (Same as in the case of message box where the parent window remains inactive unless message box is closed)
How can Ido it ?
It would be great if you could post an example code.
You can use WaitForSingleObject (IIRC) to wait for the new process to terminate. You can make your window not visible (e.g. via ShowWindow) before waiting. Check successful launch first.
When the button is pressed, create the 'xyz.exe' process using CreateProcess function and save the new process' handle (hProcess in the PROCESS_INFORMATION struct you passed in CreateProcess).
Then you can disable the 'abc.exe' window by calling EnableWindow with bEnable set to FALSE.
In the window procedure of 'abc.exe', where the WM_PAINT message is handled add a check to see if the 'xyz.exe' process is still running. You can do this by using GetExitCodeProcess function with the handle you saved earlier and checking if the return value is STILL_ACTIVE. If the 'xyz.exe' process is no longer active, you can then enable the 'abc.exe' window using EnableWindow again.
I have a windows application which invokes CreateProcess and then it exits. The process being invoked displays console and GUI windows at startup. I would like to hide the console window of the child process right when it starts.
More info:
Process is NOT started with DETACHED_PROCESS flag.
If injecting code with FreeConsole() to the remote process is the only way (I'm looking for a better one), is it not going to cause trouble with over-sensitive anti-viruses?
You can use the CREATE_NO_WINDOW flag to start a console application without a console window. It's not the same as it being hidden, but it sounds like it's what you want.
I've created a Windows/C++/WTL application that spawns a child process. The two processes communicate via anonymous pipes.
I'd like to be able to debug the child process.
Since both parent and child projects are in the same solution in Visual Studio 2008, is there any way to tell VS2008 that I'd like the debugger to debug both processes?
When I start the debugger with the parent process, the debugger won't break on any breakpoints in the child process code.
And since the child process is spawned by the parent process, I can't think of an easy way of attaching the child process (maybe via another instance of VS2008) when it's spawned.
Any insights greatly appreciated!
Plenty of options:
You can debug multiple .exes with one instance of the debugger by using Debug + Attach. I however always use two instances of Visual Studio, use Debug + Attach in the second one.
You could put a __debugbreak() in the child's code, the JIT debugger window will prompt you to select a debugger.
You can use the "Image File Execution Options" registry key to automatically launch a debugger as soon as the child .exe is started. Add a key named HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\YourApp.exe, set its "Debugger" value to "vsjitdebugger.exe"
There is a VS add-in that makes it easier yet, haven't tried it myself yet.
You can temporarily put in a call to DebugBreak() somewhere in the startup code of your child process. This will cause Windows to prompt you if you want to debug that process.
You could put a global named mutex around your CreateProcess call, and then try to grab the mutex in the child process. If you then put a breakpoint on the CreateProcess call, you should have time to attach to the child before it does anything substantial.
Note that you would miss anything that happens before main in the child process.
edit: As an example, something like this, untested:
// parent.cpp
HANDLE hMutex = ::CreateMutex(NULL, TRUE, "Global\\some_guid");
::CreateProcess(...);
::ReleaseMutex(hMutex); // breakpoint here
::CloseHandle(hMutex);
// child.cpp
int main(...)
{
HANDLE hMutex = ::OpenMutex(MUTEX_ALL_ACCESS, FALSE, "Global\\some_guid");
::WaitForSingleObject( hMutex, INFINITE );
::CloseHandle(hMutex);
...
}
You would probably want to wrap it with #if _DEBUG or environment variable checks.