Setting startingDirectory to WSL path causes indefinite application hang

[zaxbux]

Environment

Windows build number: 19041.867
Windows Terminal version (if applicable): 1.6.10571.0

Steps to reproduce

Add the following startingDirectory to a profile like so:

{
  "guid": "{07b52e3e-de2c-5db4-bd2d-ba144ed6c273}",
  "hidden": false,
  "name": "Ubuntu-20.04",
  "source": "Windows.Terminal.Wsl",
  "startingDirectory": "\\\\wsl$\\Ubuntu-20.04\\home\\zach"
}

Expected behavior

Terminal launches profile in starting directory. This has worked for awhile, issue started occuring after some recent updates (either Windows or Terminal).

Actual behavior

Terminal hangs forever when starting profile from new tab dropdown, jumplist, etc.

Note: this screenshot was taken after the startingDirectory was added in my settings.json while application was running. Terminal crashes as soon as the updated profile was clicked. Terminal launched fine and profile worked before adding line.

[DHowett]

Sorry -- all we do is pass that path off to CreateProcess. If the WSL interop implementation is hanging, it'll be bad...

I wonder if Terminal can/should have a process startup watchdog? "[process failed to start in 10 seconds; you likely don't want to try to continue]"

[Nacimota]

I wonder if Terminal can/should have a process startup watchdog? "[process failed to start in 10 seconds; you likely don't want to try to continue]"

Separate but related: WSL2 takes about 5 seconds to start up cold on my system, and I notice the terminal UI hangs for the duration.

[zadjii-msft]

Oh that's why my "Good Morning" script seems to hang. Not because it's asking the Terminal to do too much, but because the launch of WSL is slow.

I wonder if we can start the process maybe on a background thread? Or if we're waiting for the connection to actually start before doing UI work, could we just, not?

[DHowett]

@zadjii-msft not without risking the WSL profiles (and if one is set as default, a pop-up dialog saying "lol you messed up somehow").

This is, in part, why I keep talking about caching generated profiles 😉

[zaxbux]

@DHowet I ended up nuking my WSL distros, and the issue went away. Watchdog of some sort would be nice, since the only way I could kill the terminal process was though Terminal's PC Settings "Terminate" button.

[DHowett]

Oh, I realize now @zadjii-msft that you're talking about spawning the connection in the background, not launching WSL to scan for things.

We also evaluate the starting directory for validity (!) during settings load.

[zadjii-msft]

Ohkay good, I thought there must have been a miscommunication.

We also evaluate the starting directory for validity (!) during settings load.

Oh well that's probably what's doing it. Maybe we should just ditch that 🤔

[zadjii-msft]

I'm bumping this to 1.8 - we might want to preemptively fix this, esp. before pushing OSC9;9 to stable

[zadjii-msft]

Oh no, this isn't what I thought it was. I thought we had some quick path validation if a path existed for the OSC9;9 case. But we actually don't...

• in Implement ConEmu's OSC 9;9 to set the CWD #8330, the only validation is: during duplicate(Tab|Pane), if the control has a path, use that. Doesn't matter what it is, no checking if it's good, just use it.
• Improve OSC 9;9 parsing logic & add tests #8934 did not add any other validation, it just mde the list of paths we accept bigger.
• Fix TermControl initialization to pre-seed working dir #9397 furthermore additionally did not add any extra validation.
• Add support for running a commandline in another WT window #8898 & Add support for the windowingBehavior setting #9118 did add a step where wt will switch it's CWD when spawning a new commandline. This is my only theory right now.

            std::wstring cwdString{ wil::GetCurrentDirectoryW<std::wstring>() };
            std::filesystem::path cwd{ cwdString };
            cwd /= settings.StartingDirectory().c_str();

  If we do a auto p = std::filesystem::path{L"C:\Windows"} / std::filesystem::path{L"\\wsl$\home\zadjii"}, does that need to hit the filesystem to resolve the path? That would be ultra annoying.

EDIT:

Ah no, the line in question is in TerminalSettings::_ApplyProfileSettings

        _StartingDirectory = profile.EvaluatedStartingDirectory();

std::wstring Profile::EvaluateStartingDirectory(const std::wstring& directory)
{
    // First expand path
    DWORD numCharsInput = ExpandEnvironmentStrings(directory.c_str(), nullptr, 0);
    std::unique_ptr<wchar_t[]> evaluatedPath = std::make_unique<wchar_t[]>(numCharsInput);
    THROW_LAST_ERROR_IF(0 == ExpandEnvironmentStrings(directory.c_str(), evaluatedPath.get(), numCharsInput));

    // Validate that the resulting path is legitimate
    const DWORD dwFileAttributes = GetFileAttributes(evaluatedPath.get());
    ...

WHICH HAS LITERALLY ALWAYS EXISTED:
https://github.com/microsoft/terminal/blame/ed1cd32f1fb0c681b05998efdee124d6c314a07d/src/cascadia/TerminalSettingsModel/Profile.cpp#L407

LITERALLY SINCE d4d59fa

So I'm punting this back out of 1.8.

[stevenbrix]

for the record, i'm not seeing this issue with it hanging, i used the path:

\\wsl.localhost\Ubuntu\home\stevenki

windows ver: 21364.1
terminal ver: 1.7.1033.0

[ghost]

🎉This issue was addressed in #10045, which has now been successfully released as Windows Terminal v1.8.1444.0.:tada:

Handy links:

• Release Notes
• Store Download

[ghost]

🎉This issue was addressed in #10045, which has now been successfully released as Windows Terminal Preview v1.9.1445.0.:tada:

Handy links:

• Release Notes
• Store Download