This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 21%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EVD%3C/text%3E%3C/svg%3E)
A console created dynamically using AllocConsole() for a winmain entry point application vanishes if the parent GUI process terminates abruptly (e.g., via an unhandled exception or forced termination). This raises concern that stderr logs printed to the console may not be visible long enough for the user to read them—defeating the purpose of using console for error diagnostics.
Is it possible to save the state of the console or let it stay there and not get terminated along with the parent GUI process.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(246.4, 86%, 33%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDL%3C/text%3E%3C/svg%3E)
I wouldn't have expected such a console to behave differently if its owning process has died.
Well, you could print to the console and print to a file (fprintf) at the same time.. That way, you have a file to refer to if the process terminates unexpectedly. By the way, closing the allocated console will also terminate the application.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(262.40000000000003, 13%, 35%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDR%3C/text%3E%3C/svg%3E)
This happens with console applications too. What causes the output to stick around is that it is run through a terminal. If you just double click on the console executable in Explorer, then the console window only stick around for as long as the console application is running.
@Varun Dixit, Any update on this issue with respect to the two suggested approaches?
The docs say "A console is closed when the last process attached to it terminates or calls FreeConsole."
So an ugly way to have a console survive the unexpected termination of its creating process is to start a secondary process which is attached to it.
An orderly exit by the creating process would ensure that the secondary process also exits.
One method of keeping the console open after launch is to use a console application to launch the GUI application.
This serves two purposes. First, the console application is capable of waiting on the GUI process handle, and the GUI process is then able to use AttachConsole to just attach to the console application's console.
A better option is to use STARTUPINFO in CreateProcess to provide a set of handles to be used. One possible use could be to provide a set of anonymous pipes to the GUI process to monitor what is written. If the host console application detects that something is written to stderr, then the host console application can mirror the output to stderr, but then also keep the console alive when the GUI application exits. This allows you to have a pretty nice user experience.
It is possible to tune this a bit so that this could be used for debug builds or only trigger when launched through the host console application, but the end user experience will not see the console.