Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Default Terminal" mysteriously doesn't work at all - boots up the vintage console instead #11529

Closed
BajajAditya123 opened this issue Oct 18, 2021 · 44 comments · Fixed by #11610
Assignees
Labels
Area-DefApp Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Attention The core contributors need to come back around and look at this ASAP. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Priority-1 A description (P1) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Milestone

Comments

@BajajAditya123
Copy link

Windows Terminal version (or Windows build number)

1.11.2731.0

Other Software

No response

Steps to reproduce

When I made the MS terminal preview the default terminal then I clicked on the Save button and then opened Run and typed cmd. It opened the original Command Prompt window

Expected Behavior

I expected that it would open the MS Terminal Preview

Actual Behavior

It opens the original cmd

@BajajAditya123

This comment has been minimized.

@zadjii-msft
Copy link
Member

  • What OS build are you using?
  • can you share what's in HKEY_CURRENT_USER\Console\%%Startup?
  • What architecture is your machine? (AMD64? x86? ARM?)

#11524 might be related, #10594 (comment) may ne as well

@zadjii-msft zadjii-msft added Area-DefApp Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something Product-Terminal The new Windows Terminal. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Oct 18, 2021
@BajajAditya123
Copy link
Author

OS Bulid - 22000.258
image
x64

@ghost ghost added Needs-Attention The core contributors need to come back around and look at this ASAP. and removed Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something labels Oct 19, 2021
@BajajAditya123

This comment has been minimized.

@zadjii-msft
Copy link
Member

That all seems on the up-and-up.... I think at the moment we're at a but of an impasse as far as trying to debug this one. However, we'll hopefully be shipping 1.12 later this week. When that lands, I'm gonna try following up with you to see if you can follow some other repro steps with 1.12. That should include a bunch more diagnostics which should help to figure out what's going on here.

Couple other questions off the dome while thinking about this:

  • Are you trying to run cmd.exe elevated / as an admin? (this includes anything that might autoelevate cmd.exe, like this checkbox:
    image
  • Does your machine have UAC disabled?

@BajajAditya123
Copy link
Author

Are you trying to run cmd.exe elevated / as an admin? (this includes anything that might autoelevate cmd.exe, like this - No
Does your machine have UAC disabled? - It is enabled

PankajBhojwani pushed a commit that referenced this issue Oct 19, 2021
Considering the number of reports of "defterm isn't working (mysteriously)", I figured more logging current hurt. I also added a wprp profile for the defterm logging as well, which should capture conhost side things as well. 

From an elevated conhost:
```
wpr -start path\to\Terminal.wprp!Defterm.Verbose
wpr -stop %USERPROFILE%\defterm-trace.etl
```

* [x] I work here
* [x] relevant to: #10594, #11529, #11524.
PankajBhojwani pushed a commit that referenced this issue Oct 19, 2021
Considering the number of reports of "defterm isn't working (mysteriously)", I figured more logging current hurt. I also added a wprp profile for the defterm logging as well, which should capture conhost side things as well.

From an elevated conhost:
```
wpr -start path\to\Terminal.wprp!Defterm.Verbose
wpr -stop %USERPROFILE%\defterm-trace.etl
```

* [x] I work here
* [x] relevant to: #10594, #11529, #11524.

(cherry picked from commit 284257a)
PankajBhojwani pushed a commit that referenced this issue Oct 20, 2021
Considering the number of reports of "defterm isn't working (mysteriously)", I figured more logging current hurt. I also added a wprp profile for the defterm logging as well, which should capture conhost side things as well. 

From an elevated conhost:
```
wpr -start path\to\Terminal.wprp!Defterm.Verbose
wpr -stop %USERPROFILE%\defterm-trace.etl
```

* [x] I work here
* [x] relevant to: #10594, #11529, #11524.
@BajajAditya123

This comment has been minimized.

@happybear88
Copy link

Same here with v1.11.2921.0 on two pretty much clean install VMs (Home, Pro) with 22000.258
Repro with powershell 5.1 and cmd when launched from Start, win+r. Neither is elevated in any way.
FWIW, the same issue is repro with the Terminal Preview.
terminal

@BajajAditya123
Copy link
Author

Same here with v1.11.2921.0 on two pretty much clean install VMs (Home, Pro) with 22000.258 Repro with powershell 5.1 and cmd when launched from Start, win+r. Neither is elevated in any way. FWIW, the same issue is repro with the Terminal Preview. terminal

It is in Stable version of Windows Terminal no preview. Good to know

@BajajAditya123
Copy link
Author

Same here with v1.11.2921.0 on two pretty much clean install VMs (Home, Pro) with 22000.258 Repro with powershell 5.1 and cmd when launched from Start, win+r. Neither is elevated in any way. FWIW, the same issue is repro with the Terminal Preview. terminal

It is in Stable version of Windows Terminal no preview. Good to know

It is not working with Start Menu also

@BajajAditya123

This comment has been minimized.

@happybear88
Copy link

happybear88 commented Oct 21, 2021 via email

@zadjii-msft
Copy link
Member

Hokay, so while we don't think this was fixed in 1.12, there should be some additional logging that might be useful. To get these logs, I'm gonna need you to follow a couple steps:

  1. Download the Terminal.wprp file from our repo somewhere on your PC. For example, let's put the file at C:\path\to\Terminal.wprp
  2. Setup Windows Terminal Preview as the default terminal application. You can do this in the Console Property sheet, the Settings app, the Terminal Settings UI, anywhere, doesn't matter. It just needs to be set to Windows Terminal Preview, so we get the diagnostics from 1.12.
  3. (Preferably, close all other Terminal & console windows. That'll make the logging less noisy).
  4. From an elevated commandline, run:
wpr -start C:\path\to\Terminal.wprp!Defterm.Verbose
  1. Try launching powershell.exe or cmd.exe. Could be from the Start Menu, the Run Dialog, anywhere. Doesn't matter. (It'll pop up in the vintage console window, but that's fine. We want to find out why that happened.)
  2. Go back to the elevated commandline window and run:
wpr -stop defterm-trace.etl
  1. Take the defterm-trace.etl file, and send it to me (my email is on my GH profile).

HOPEFULLY, the logging we added in #11537 should help clue us in as to why this is failing.

@zadjii-msft zadjii-msft added Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something and removed Needs-Attention The core contributors need to come back around and look at this ASAP. labels Oct 21, 2021
@BajajAditya123

This comment has been minimized.

@ghost ghost added Needs-Attention The core contributors need to come back around and look at this ASAP. and removed Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something labels Oct 21, 2021
@zadjii-msft zadjii-msft added Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something and removed Needs-Attention The core contributors need to come back around and look at this ASAP. labels Oct 21, 2021
@zadjii-msft zadjii-msft added Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-1 A description (P1) labels Oct 25, 2021
@zadjii-msft zadjii-msft added this to the Terminal v2.0 milestone Oct 25, 2021
@zadjii-msft zadjii-msft changed the title Default Terminal Bug "Default Terminal" mysteriously doesn't work at all - boots up the vintage console instead Oct 25, 2021
@BajajAditya123
Copy link
Author

I think it affects after a restart

@zadjii-msft
Copy link
Member

@happybear88 CRAZY question - Do you have Visual Studio installed? (same to @BajajAditya123)

@BajajAditya123
Copy link
Author

I have Visual Studio Code

@zadjii-msft
Copy link
Member

We're thinking there's some dependent c runtime dll that might not necessarily be installed by default, but does get installed with VS. @BajajAditya123 Any chance if you remember if you installed something between the Terminal not working 4 days ago and starting to work 2 days ago?

@happybear88
Copy link

happybear88 commented Oct 25, 2021

Hi @zadjii-msft,
You don't have to look for external factors. You should be able to repro with these steps, I just did. And that's the third time out of three I repro this with Windows 11 home and pro editions out of the box.

  1. D/l the Windows 11 ISO from https://www.microsoft.com/en-us/software-download/windows11 (I used EN)
  2. Install the OS [on Hyper-V VM] with networking off.
  3. Enable the network adapter and make sure you get the App Installer installed from the Store.
  4. Run winget upgrade "windows terminal" and ensure you have 1.11
  5. Set WT as the default terminal in its settings and Save.
  6. Run CMD or powershell
    AR: both open separately, not inside the WT

P.S. I install w/o the network simply to speed things up. Takes under 10 minutes. Installing the latest updates and rebooting have no effect on the issue, still repro.

@ghost ghost added the In-PR This issue has a related PR label Oct 25, 2021
@miniksa
Copy link
Member

miniksa commented Oct 25, 2021

@lhecker and I are testing the CRT theory with advice about our proxy stub from @brialmsft.

@miniksa miniksa assigned lhecker and miniksa and unassigned lhecker Oct 25, 2021
@ghost ghost closed this as completed in #11610 Oct 26, 2021
@ghost ghost added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed In-PR This issue has a related PR labels Oct 26, 2021
ghost pushed a commit that referenced this issue Oct 26, 2021
After this commit OpenConsoleProxy will be built without a CRT.
This cuts down its binary size and DLL dependency bloat.
We hope that this fixes a COM server activation bug if the
user doesn't have a CRT installed globally on their system.

Fixes #11529
@eryksun
Copy link

eryksun commented Oct 30, 2021

We're thinking there's some dependent c runtime dll that might not necessarily be installed by default

This was an easy fix for my vanilla test VM. I just had to install the Visual C++ Redistributable, which installed the required "vcruntime140.dll" file to the system directory. This C runtime DLL is actually beside "OpenConsoleProxy.dll" in the Windows Terminal Preview directory in "%ProgramFiles%\WindowsApps", but I suppose the COM host doesn't load "OpenConsoleProxy.dll" using the flag LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR.

@brialmsft
Copy link

brialmsft commented Nov 1, 2021

COM uses LOAD_WITH_ALTERED_SEARCH_PATH, which should be able to resolve dependencies on DLLs adjacent to the main DLL being loaded by LoadLibraryEx. See https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#alternate-search-order-for-desktop-applications

@brialmsft
Copy link

Oh right, this was failing in the context of proxy/stub creation, wasn't it? In that case, the issue is likely the fact that proxy/stub DLLs exposed by MSIX packages aren't actually loaded from the real location within the package root, they're copied to an alternate location. This is because the security configuration on package roots doesn't necessarily let processes outside of the package execute the package's binaries. So we copy the proxy/stub DLLs to a location with more appropriate security configuration, without their dependencies, which is what causes the dependencies to not resolve.

Bottom-line: it is virtuous to make sure MSIX proxy/stub DLLs have minimal dependencies.

DHowett pushed a commit that referenced this issue Dec 13, 2021
After this commit OpenConsoleProxy will be built without a CRT.
This cuts down its binary size and DLL dependency bloat.
We hope that this fixes a COM server activation bug if the
user doesn't have a CRT installed globally on their system.

Fixes #11529

(cherry picked from commit def1bdd)
DHowett pushed a commit that referenced this issue Dec 13, 2021
After this commit OpenConsoleProxy will be built without a CRT.
This cuts down its binary size and DLL dependency bloat.
We hope that this fixes a COM server activation bug if the
user doesn't have a CRT installed globally on their system.

Fixes #11529

(cherry picked from commit def1bdd)
@ghost
Copy link

ghost commented Dec 14, 2021

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

Handy links:

@ghost
Copy link

ghost commented Dec 14, 2021

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

Handy links:

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-DefApp Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Attention The core contributors need to come back around and look at this ASAP. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Priority-1 A description (P1) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants