-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Comments
This comment has been minimized.
This comment has been minimized.
#11524 might be related, #10594 (comment) may ne as well |
This comment has been minimized.
This comment has been minimized.
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 - No |
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.
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)
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.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Please stop spamming the thread. I guess posting here was a mistake. Unsubscribed. If dev needs my input, reach out otherwise.
|
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:
HOPEFULLY, the logging we added in #11537 should help clue us in as to why this is failing. |
This comment has been minimized.
This comment has been minimized.
I think it affects after a restart |
@happybear88 CRAZY question - Do you have Visual Studio installed? (same to @BajajAditya123) |
I have Visual Studio Code |
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? |
Hi @zadjii-msft,
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. |
@lhecker and I are testing the CRT theory with advice about our proxy stub from @brialmsft. |
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
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 |
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 |
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. |
🎉This issue was addressed in #11610, which has now been successfully released as Handy links: |
🎉This issue was addressed in #11610, which has now been successfully released as Handy links: |
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
The text was updated successfully, but these errors were encountered: