[feature request] Add extra information for known error codes from WSL

[vadimkantorov]

Original message: #12360 (comment)

Sometimes WSL backend crashes and I get messages [process exited with code 3221225786]. It would be useful for Terminal to print extra information about known error codes (at least from WSLv1 and other Microsoft backends). It would also be good to propose the user to restart the tab by hitting Enter.

[zadjii-msft]

This is where we print the error message:

terminal/src/cascadia/TerminalConnection/ConptyConnection.cpp

Lines 387 to 397 in 7734cd7

	void ConptyConnection::_indicateExitWithStatus(unsigned int status) noexcept
	{
	try
	{
	// GH#11556 - make sure to format the error code to this string as an UNSIGNED int
	winrt::hstring exitText{ fmt::format(std::wstring_view{ RS_(L"ProcessExited") }, fmt::format(_errorFormat, status)) };
	_TerminalOutputHandlers(L"\r\n");
	_TerminalOutputHandlers(exitText);
	}
	CATCH_LOG();
	}

This is somewhere similar in ConPTY connection where we print a specific message for a specific error,

terminal/src/cascadia/TerminalConnection/ConptyConnection.cpp

Lines 369 to 375 in 7734cd7

	if (hr == HRESULT_FROM_WIN32(ERROR_DIRECTORY))
	{
	winrt::hstring badPathText{ fmt::format(std::wstring_view{ RS_(L"BadPathText") },
	_startingDirectory) };
	_TerminalOutputHandlers(L"\r\n");
	_TerminalOutputHandlers(badPathText);
	}

https://stackoverflow.com/a/17387176/1481137 might be useful, but I don't think that works for HRESULTS

[eryksun]

STATUS_CONTROL_C_EXIT (0xC000013A, 3221225786) is an NTSTATUS code. The default console control handler exits with this status code, whether it's due to Ctrl+C, Ctrl+Break, or closing the console window/tab.

Usually if the exit status of a normal Windows process is an NTSTATUS code, it means the process either failed early during initialization or failed due to an unhandled OS exception such as STATUS_ACCESS_VIOLATION (0xC0000005), STATUS_STACK_OVERFLOW (0xC00000FD), or STATUS_STACK_BUFFER_OVERRUN (0xC0000409). The latter is also used by the __fastfail() intrinsic, with which the C runtime implements abort().

Functions that return HRESULT values can return the bitwise OR of an NTSTATUS code with FACILITY_NT_BIT (0x10000000). For example, return HRESULT_FROM_NT(STATUS_CONTROL_C_EXIT) or (HRESULT) (STATUS_CONTROL_C_EXIT | FACILITY_NT_BIT)

Error messages for most NTSTATUS codes are sourced from "ntdll.dll", after masking out FACILITY_NT_BIT of course. For example, in Python:

>>> flags = win32con.FORMAT_MESSAGE_FROM_HMODULE | win32con.FORMAT_MESSAGE_IGNORE_INSERTS
>>> hmod = win32api.GetModuleHandle('ntdll')
>>> langid = win32api.MAKELANGID(win32con.LANG_NEUTRAL, win32con.SUBLANG_DEFAULT)
>>> win32api.FormatMessage(flags, hmod, 0xC000013A, langid, None)
'{Application Exit by CTRL+C}\r\nThe application terminated as a result of a CTRL+C.\r\n'

There are some HRESULT values that mistakenly use the reserved "R" bit, which makes them look like NTSTATUS values, e.g. ERROR_AUDITING_DISABLED (0xC0090001). So if you're expecting an HRESULT and get what appears to be an NTSTATUS value, first try to handle it as a Windows (system) error code. For example:

>>> flags = win32con.FORMAT_MESSAGE_FROM_SYSTEM | win32con.FORMAT_MESSAGE_IGNORE_INSERTS
>>> win32api.FormatMessage(flags, 0, 0xC0090001, langid, None)
'The specified event is currently not being audited.\r\n'

[vadimkantorov]

For me. these WSL crashes happen sometimes during normal work, not at initialization without me hitting Ctrl+C. In any case, these crashes are likely linked to insufficient available RAM or to hard disk being too slow to respond / failing (especially during RAM paging process) - maybe the OS oom-kills the WSL process somehow. But in any case, extra textual info (+maybe a website link explaining more?) would be very helpful

[eryksun]

The error message for the exit status code isn't likely to help, especially if it's just STATUS_CONTROL_C_EXIT (0xC000013A). For WSL, capturing an event log as shown on this page would likely provide useful diagnostic information.

[vadimkantorov]

Hmm, my slow laptop also started to have keyboard failing. Now I get this WSL crash whenever I hit the key "b". I wonder if my keyboard somehow turned itself into the mode where it sends Ctrl+Break.

Indeed, the faulty key B now produces KeyboardEvent {isTrusted: true, key: '\x03', code: 'Pause', location: 0, ctrlKey: true, …}

[vadimkantorov]

So maybe if Ctrl+Break is hit and this causes WSL process to terminate, should this lead to the tab being closed?

A similar case happens when one hits Ctrl+D to exit a terminal (this would be the outcome on Gnome Terminal), Terminal executes logout, but then the tab is not closed and instead [process exited with code 255] is printed on a cleared screen

[eryksun]

So maybe if Ctrl+Break is hit and this causes WSL process to terminate, should this lead to the tab being closed?

You can configure the termination behavior in the settings for a profile or the default profile to one of the following options: close always; close on successful exit (0); or never close.

A similar case happens when one hits Ctrl+D to exit a terminal (this would be the outcome on Gnome Terminal), Terminal executes logout, but then the tab is not closed and instead [process exited with code 255] is printed on a cleared screen

The exit status for Ctrl+D should be 0, not 255.

In Unix, the closest to Windows Ctrl+Break is the terminal quit signal, which for me in Linux (not WSL) is Ctrl+\ (check stty -a). This sends SIGQUIT to the foreground process group. In Windows, Ctrl+Break sends CTRL_BREAK_EVENT to all processes in the console session. Shells such as CMD and PowerShell ignore the break event when waiting for a child process. When CMD is active in the foreground, Ctrl+Break cancels the current line, which is more to do with the console itself since the read gets canceled on the console side. For PowerShell in the foreground, Ctrl+Break enters a debugging mode.

I don't know why WSL doesn't map the break event to the pty quit signal instead of letting the default handler exit with STATUS_CONTROL_C_EXIT. But there's a lot I don't know about WSL.

[vadimkantorov]

Most of time it's indeed 0, and Ctrl+D closes the tab automatically, but sometimes I evidence code 255, not sure why :/

[vadimkantorov]

I also got a nice one:

The I/O operation has been aborted because of either a thread exit or an application request.

[process exited with code 4294967295]

A tab was hung for a while, and during this time all other tabs were not responsive. Then I got this message and other tabs got unhung. It's as if Terminal performed some IO to WSL backend via a single thread that can be hung

[vadimkantorov]

Maybe also Terminal could print sth like "Press Ctrl + Shift + W to close this tab " for better keystroke discoverability

[zadjii-msft]

Hey look at that, we were already tracking this in /dup #7186. Thanks!

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

[vadimkantorov]

Currently, WSLv1 session just died at me with: [process exited with code 3221225786 (0xc000013a)]. Still no text description for HRESULTs / NTSTATUS / WinAPI error codes or whatever these are

[zadjii]

Yep, the issue that this was duped too is in fact, still open.

[vadimkantorov]

Also, may be clearer if that issue name is also expanded to reflect more than just errors on connection to conpty

[vadimkantorov]

When Terminal fails to connect to WSLv1 service, a new tab just times out and then prints an error code 1. It would be good if it showed a proper error message if it fails to connect to WSL (and maybe offers either to exit the tab on pressing a key or retrying to connect to WSL).

[zadjii-msft]

@vadimkantorov That sounds like something that should be reported to https://github.com/microsoft/wsl. We can only surface the information given to us - and an error code of 1 is not terribly informative.

(and maybe offers either to exit the tab on pressing a key or retrying to connect to WSL).

That's in a PR that you've commented on 😉

[vadimkantorov]

Mainly I'm concerned here to have a good error message. I'm not understanding deep enough to understand what exactly is failing here and at what level, so I thought maybe it's some special tool that Terminal is invoking to create a WSL session.

If it's just calling wsl.exe, it might be worth it to solve crash / return code of wsl.exe at the Terminal level and have a generic "WSL session failed" at least. Of course a more specific message may be shown if WSL returns a more specific error code

[vadimkantorov]

@zadjii-msft

Btw, when typing exit in Command Prompt (running in Terminal), it currently does not exit the tab right away (I think it should!)

Instead it prints:

[process exited with code 9009 (0x00002331)]
You can now close this terminal with Ctrl+D, or press Enter to restart.

9009 looks like some special error code, I think the Terminal should indeed close the tab if it receives a known exit code from cmd.exe like this - or at least print a better suited message. The current message is a bit too cryptic, for the very non-surprising tab's end of life

Interestingly, for WSLv1 tab, typing exit seems to produce first some similar message, but then the tab closes automatically without forcing to stroke Ctrl+D

When I typed exit the second time, the Terminal closed the tab, which makes me think that the existing tab auto-closing isn't very reliable

[zadjii-msft]

I mean, you could also just set closeOnExit: always.

9009 is MSG_DIR_BAD_COMMAND_OR_FILE, which is the error code for "'%1' is not recognized as an internal or external command, operable program or batch file"

You may also be seeing #16068. Not sure how far back we backported that.

[vadimkantorov]

Well, what was strange that it did not work once, but then worked. So maybe this mechanism just is not 100% reliable

[vadimkantorov]

Yeah, it happened again. Two times auto-closing did not work, but then worked again. And when it works, it first prints this error message [process exited with code 9009 (0x00002331)] You can now close this terminal with Ctrl+D, or press Enter to restart. and closes only after.

So it seems this autoclose is enabled by default but is certainly random/not reliable

[DHowett]

It's a lot less random than it seems!

Most shells project their last subprocess' exit code when they themselves exit. It also so happens that 9009 is the code CMD uses to indicate that a command was not found.

You can see this behavior consistently in cmd, bash and zsh, but not with PowerShell.

cmd

bash

zsh

pwsh

The "graceful" close-on-exit policy explicitly prefers keeping a tab open when it exits with an error. This includes expected errors like 9009 when you've just run a command that doesn't exist or pressed Ctrl+C in cmd.
If you don't like how the "graceful" close-on-exit policy works, you can always set it to "always" 😄

[vadimkantorov]

I think che current behavior that terminal's tab should close-on-exit or not close-on-exit, depending in fact on behavior of previously run command is very unintuitive, especially as default behavior.

So I would propose to switch to "always" close-on-exit.

If this is absolutely not possible, I guess my a ask would be to add this information (+ some info on this close-on-exit and mode differences, reason of this show exit code and how to change it) to the printed message next to [process exited with code 9009 (0x00002331)] You can now close this terminal with Ctrl+D, or press Enter to restart., as typing some incorrect command (e.g. typing rm some_file_name in cmd.exe session by mistake instead of a WSL tab, then exiting it and starting a proper WSL tab) and then quitting with exit is fairly common.

• in general, adding info on some known error codes of some standard Windows programs/utils would be nice

[vadimkantorov]

Another extra proposed solution:
Make Ctrl+D shortcut to always close the tab uniformly across frequent profiles (cmd.exe/powershell/wslv1/wslv2), regardless of current exit code. And make cmd/powershell support Ctrl+D as well

Now, it's super funny, as stroking Ctrl+D in WSLv1 tab after command-not-found still prints 127 error code and invites to stroke Ctrl+D one more time :) sudo Ctrl+D as in xkcd comic strip

vadimkantorov@delldevadim:/mnt/c/Users/vadim$ asdsd
asdsd: command not found
vadimkantorov@delldevadim:/mnt/c/Users/vadim$
logout

[process exited with code 127 (0x0000007f)]
You can now close this terminal with Ctrl+D, or press Enter to restart.

so currently Ctrl+D sends logout to terminal, which invites to press Ctrl+D one more time :)

[vadimkantorov]

Just received the following:

Error: 0xd00002fe
Error code: Wsl/Service/0xd00002fe
Press any key to continue...

and after hitting Enter:

[process exited with code 4294967295 (0xffffffff)]
You can now close this terminal with Ctrl+D, or press Enter to restart.

Seems to be printed by the Terminal? If 0xd00002fe is an error code from the WSL service, it would be nice to have some text explanation of the error

[DHowett]

Terminal produced the "process exited" and "You can now close this terminal" messages. wsl.exe produced the Error code: Wsl/Service... and Press any key... messages.

Terminal is only aware of the exit code 0xffffffff.
It is not aware of 0xd00002fe, which was printed by wsl.exe.

You should file a request for better error messages on the WSL repository.