Recommended Way to log to stderr in a wWinMain GUI app launched from a terminal, for diagnostics when GUI fails or app runs in background?

Question

Recommended Way to log to stderr in a wWinMain GUI app launched from a terminal, for diagnostics when GUI fails or app runs in background?

Varun Dixit 20

For int main() apps, writing to stderr works fine with shell redirection, but with wWinMain, the file is created but stays empty (tried to use 2> stderr_log.txt). I’d like to know if there’s any supported way to make stderr functional (e.g., dynamically attaching to a console, or another recommended mechanism) — without switching the app’s subsystem to console.

The motivation here is not to keep a terminal session running, but simply to allow diagnostic output (like failure reasons or even a “Success” message) to be logged when the app is started from a script or terminal — especially useful when the GUI or MessageBox fails or the app runs in the background. Is stderr redirection possible for GUI apps, and if not, what’s the best Microsoft-recommended alternative for logging low-level errors in such contexts?

Viorel 122.2K Reputation points

2025-06-04T12:01:26.85+00:00

Did you start your program from the Command Prompt console?
Varun Dixit 20 Reputation points

2025-06-04T12:16:49.47+00:00

Yes, I have tried with Command Prompt as well as Windows PowerShell.
Viorel 122.2K Reputation points

2025-06-04T14:59:31.6066667+00:00

Maybe it will work in PowerShell using this command: cmd /c .\MyProgram.exe 2> stderr_log.txt.
RLWA32 49,311 Reputation points

2025-06-04T16:25:31.4233333+00:00
@Viorel, It worked in my test. Apparently, stderr gets connected to an inherited pipe handle.The same concept worked directly from a cmd command prompt without powershell -

C:\Users\RLWA32\source\repos\RlwA32\Win32StderrTest\x64\Debug>cmd /c "Win32StderrTest.exe" 2> stderr2.txt
Darran Rowe 1,986 Reputation points

2025-06-04T16:40:57.13+00:00
It should just work.

This is with the code:

#include <Windows.h> #include <cstdio> #include <string> int WINAPI wWinMain(_In_ HINSTANCE, _In_opt_ HINSTANCE, _In_ LPWSTR, _In_ int) { HANDLE err = GetStdHandle(STD_ERROR_HANDLE); if (err) { std::wstring buffer(6, L'\0'); //Try writing to stderr; swprintf(buffer.data(), 6, L"StdErr"); fputws(buffer.data(), stderr); } return 0; }

If anything, the current directory is possibly the biggest issue. So potentially placing a path on the redirection file could help.

cmd /c C:\Users\Darran\source\repos\TestRedirect\x64\Debug\TestRedirect 2> C:\Users\Darran\source\repos\TestRedirect\x64\Debug\stderr.txt

But GetStdHandle will give a non 0 value if redirection has happened in a Windows subsystem application. For a console subsystem application, GetStdHandle will normally return the pseudo handles for stdin, stdout and stderr (0x08, 0x0cand 0x10 respectively). You know that redirection happened if you get a handle value other than these.

Accepted answer

2 additional answers

Your answer

Viorel 122.2K Reputation points

2025-06-04T12:01:26.85+00:00

Did you start your program from the Command Prompt console?
Varun Dixit 20 Reputation points

2025-06-04T12:16:49.47+00:00

Yes, I have tried with Command Prompt as well as Windows PowerShell.
Viorel 122.2K Reputation points

2025-06-04T14:59:31.6066667+00:00

Maybe it will work in PowerShell using this command: cmd /c .\MyProgram.exe 2> stderr_log.txt.
RLWA32 49,311 Reputation points

2025-06-04T16:25:31.4233333+00:00

@Viorel, It worked in my test. Apparently, stderr gets connected to an inherited pipe handle.The same concept worked directly from a cmd command prompt without powershell -

C:\Users\RLWA32\source\repos\RlwA32\Win32StderrTest\x64\Debug>cmd /c "Win32StderrTest.exe" 2> stderr2.txt
Darran Rowe 1,986 Reputation points

2025-06-04T16:40:57.13+00:00

It should just work.

This is with the code:

#include <Windows.h> #include <cstdio> #include <string> int WINAPI wWinMain(_In_ HINSTANCE, _In_opt_ HINSTANCE, _In_ LPWSTR, _In_ int) { HANDLE err = GetStdHandle(STD_ERROR_HANDLE); if (err) { std::wstring buffer(6, L'\0'); //Try writing to stderr; swprintf(buffer.data(), 6, L"StdErr"); fputws(buffer.data(), stderr); } return 0; }

If anything, the current directory is possibly the biggest issue. So potentially placing a path on the redirection file could help.

cmd /c C:\Users\Darran\source\repos\TestRedirect\x64\Debug\TestRedirect 2> C:\Users\Darran\source\repos\TestRedirect\x64\Debug\stderr.txt

But GetStdHandle will give a non 0 value if redirection has happened in a Windows subsystem application. For a console subsystem application, GetStdHandle will normally return the pseudo handles for stdin, stdout and stderr (0x08, 0x0cand 0x10 respectively). You know that redirection happened if you get a handle value other than these.

Answer 1

RLWA32 49,311

GUI applications are started without a console and stdin, stdout and stderr are not connected to anything.

A convenient way to see error messages from GUI applications is to use the Windows API function OutputDebugString. Messages written with this function will be visible when the application is run under a debugger and, when not debugging, can be viewed using Sysinternals DebugView utility.

A GUI application can allocate a console and connect the stdin, stdout and stderr streams so that console functions can be used. The console is obtained with AllocConsole and the handles are connected with freopen or the secure (_s) variants. For example,

Connect streams for console I/O -

FILE *fpstdin = stdin, *fpstdout = stdout, *fpstderr = stderr;

// Initialize for console i/o
freopen_s(&fpstdin, "CONIN$", "r", stdin);
freopen_s(&fpstdout, "CONOUT$", "w", stdout);
freopen_s(&fpstderr, "CONOUT$", "w", stderr);

Varun Dixit 20 Reputation points

2025-06-04T11:47:22.8033333+00:00

Thank you for the detailed response — really appreciate the insights!

I understand that wWinMain GUI apps lack a default console, so stderr isn't connected. Tools like OutputDebugString or AllocConsole help, but require internal setup.

However, my primary motivation here is to enable user-directed redirection of stderr — similar to what we can do on Linux:

Normal terminal execution: ./stderr_test → both stdout and stderr appear in the terminal.

Selective redirection: ./stderr_test 2> captured_stderr.txt → stderr goes to the file, while stdout stays in the terminal.

This gives users or shell scripts the flexibility to capture diagnostics without modifying the app or using a debugger.

What I’m really looking for is whether there’s a supported or idiomatic way on Windows to make stderr redirection work like this for GUI apps — from the user’s perspective — without switching to a console subsystem. It doesn’t have to be the default behavior, just a way to support redirection when the app is launched.

Thanks again!

Answer 2

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Comments have been turned off. Learn more

Answer 3

Varun Dixit 20

Thankyou for the response.

I am able to redirect the stderr to a file using both cmd and Windows PowerShell now (without the need of cmd \c also, just need to confirm if run the application with a backslash).

So, In a Windows GUI application using wWinMain, standard error output (stderr) behaves differently based on whether a console is attached. If AllocConsole() is not called, and the app is launched from a terminal, redirection like .\app.exe 2> file.txt works as expected because the process inherits the terminal's handles. However, if AllocConsole() is called, the app creates a new console window at runtime, and any prior redirection is ignored, which was in my case.

Thankyou again for your time and efforts, my issue has been resolved.

Darran Rowe 1,986

However, if AllocConsole() is called, the app creates a new console window at runtime, and any prior redirection is ignored, which was in my case.

This is incorrect. What happens is that most of the time, people blindly just reopen the streams. If you use GetStdHandle to check for redirected streams first, and only reopen the streams if there is no redirection then previous redirections keep working.

#include <Windows.h>
#include <cstdio>

int WINAPI wWinMain(_In_ HINSTANCE, _In_opt_ HINSTANCE, _In_ LPWSTR, _In_ int)
{
	auto stdin_handle = GetStdHandle(STD_INPUT_HANDLE);
	auto stdout_handle = GetStdHandle(STD_OUTPUT_HANDLE);
	auto stderr_handle = GetStdHandle(STD_ERROR_HANDLE);

	AllocConsole();

	//This will either be the 0x08 for
	//the default handle, or something else non 0 for
	//a redirected handle. If it is 0, then it isn't attached.
	if (!stdin_handle)
	{
		FILE *old{};
		_wfreopen_s(&old, L"CONIN$", L"r", stdin);
	}

	//This will either be the 0x0c for
	//the default handle, or something else non 0 for
	//a redirected handle. If it is 0, then it isn't attached.
	if (!stdout_handle)
	{
		FILE *old{};
		_wfreopen_s(&old, L"CONOUT$", L"w", stdout);
	}

	//This will either be the 0x0c for
	//the default handle, or something else non 0 for
	//a redirected handle. If it is 0, then it isn't attached.
	if (!stderr_handle)
	{
		FILE *old{};
		_wfreopen_s(&old, L"CONOUT$", L"w", stderr);
	}

	fwprintf(stdout, L"Hello World!\n");
	fwprintf(stderr, L"Hello World! In stderr!\n");

	return 0;
}

The above is an example of this. This code will only reopen the stream if the application isn't already attached to anything.

Share via

Recommended Way to log to stderr in a wWinMain GUI app launched from a terminal, for diagnostics when GUI fails or app runs in background?

2 additional answers

Your answer