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

startOnUserLogin isn't working anymore (on 1.12, Windows 10) #12384

Closed
MS-Manikandan opened this issue Feb 5, 2022 · 11 comments · Fixed by #12491
Closed

startOnUserLogin isn't working anymore (on 1.12, Windows 10) #12384

MS-Manikandan opened this issue Feb 5, 2022 · 11 comments · Fixed by #12491
Assignees
Labels
Area-User Interface Issues pertaining to the user interface of the Console or Terminal Issue-Bug It either shouldn't be doing this or needs an investigation. 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. zPreview-Service-Queued-1.13 A floating label that tracks the current Preview version for servicing purposes. zStable-Service-Queued-1.12 A floating label that tracks the current Stable version for servicing purposes.

Comments

@MS-Manikandan
Copy link

Windows Terminal version

1.12.10334.0

Windows build number

10.0.19044 .0

Other Software

No

Steps to reproduce

I have recently upgraded windows terminal Version: 1.12.10334.0

Expected Behavior

If startOnUserLogin key was set to true in settings.json file and Launch on machine startup was toggled on in windows terminal/terminal settings, it should launch on startup.

Actual Behavior

After updating to windows terminal latest Version: 1.12.10334.0, it doesn't launches on startup, windows terminal wasn't found on taskmanager startup programs and windows settings startup apps, even though startOnUserLogin set to true, in the settings.json file.
image
image

@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Feb 5, 2022
@BrianHo888
Copy link

My mRemoteNG startup with a blank screen after Windows Update to 21H2. I tried to open confCons.xml but it won't load the configuration. Does anyone experience this issue and have solved this problem?

@lino-man

This comment was marked as off-topic.

@zadjii-msft
Copy link
Member

I suspect this has to do with the name change, but I have yet to understand why...

@zadjii-msft zadjii-msft added Product-Terminal The new Windows Terminal. zPreview-Service-Queued-1.13 A floating label that tracks the current Preview version for servicing purposes. zStable-Service-Queued-1.12 A floating label that tracks the current Stable version for servicing purposes. Issue-Bug It either shouldn't be doing this or needs an investigation. labels Feb 6, 2022
@zadjii-msft zadjii-msft added this to the Terminal v1.14 milestone Feb 8, 2022
@zadjii-msft zadjii-msft changed the title Windows Terminal Version: 1.12.10334.0 doesn't startup on a Win10 21H2 system startOnUserLogin isn't working anymore (on 1.12, Windows 10) Feb 10, 2022
@zadjii-msft zadjii-msft added Priority-1 A description (P1) Area-User Interface Issues pertaining to the user interface of the Console or Terminal and removed Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Feb 10, 2022
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Feb 10, 2022
@zadjii-msft
Copy link
Member

onecore\base\AppModel\Runtime\Src\PackagePath.hpp(144)\kernelbase.dll!00007FFFC94D6FD1: (caller: 00007FFFC94D6AEE) ReturnHr(5) tid(7458) 80073D5B The package does not have a mutable directory.
TerminalApp.dll!00007FFEE024B371: LogHr(1) tid(7458) 80070057 The parameter is incorrect.
Exception thrown at 0x00007FFFC94B230C (KernelBase.dll) in WindowsTerminal.exe: WinRT originate error - 0x80070057 : 'The parameter is incorrect.'.
Exception thrown at 0x00007FFFC94B230C in WindowsTerminal.exe: Microsoft C++ exception: winrt::hresult_invalid_argument at memory location 0x000000FEEB51D890.
Exception thrown at 0x00007FFFC94B230C in WindowsTerminal.exe: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000.
D:\dev\private\OpenConsole\src\cascadia\TerminalApp\AppLogic.cpp(1023)\TerminalApp.dll!00007FFEE0919A86: (caller: 00007FFEE030BDED) LogHr(2) tid(7458) 80070057 The parameter is incorrect.
    Msg:[winrt::hresult_error: The parameter is incorrect.] [winrt::TerminalApp::implementation::AppLogic::_ApplyStartupTaskStateChange]

@zadjii-msft
Copy link
Member

Well, my theory is definitely right. Definitely regressed in #12264. Just changing the DisplayName to Foo fixes this. There may be a bug in the platform for how it handles nested resources like this. I've got mail out. We'll see where that goes.

If it is a platform bug, we're in a pretty bad spot. We won't be able to localize that string in all the rest of the languages the Terminal is localized in. We could maybe move the context menu strings into the appx's resources... maybe? I'm not even sure that would work.

Hopefully it isn't.

@zadjii-msft zadjii-msft self-assigned this Feb 11, 2022
@zadjii-msft zadjii-msft added the In-PR This issue has a related PR label Feb 15, 2022
@ghost ghost closed this as completed in #12491 Feb 15, 2022
@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 Feb 15, 2022
ghost pushed a commit that referenced this issue Feb 15, 2022
We chose to use the "ContextMenu" resource compartment when we
changed the package name to Terminal in #12264 because it was more
broadly localized than the rest of the application.

It appears as though some platform features have trouble with the
"more qualified" resource paths that #12264 required.

To fix this, we will:

1. Copy all of the ContextMenu localizations into CascadiaPackage's
   resource root
2. Switch all manifest resource paths to use resources from the package
   root.

Regressed in #12264
Closes #12384
Closes #12406 (tracked in microsoft/PowerToys#16118)
@J-HS-L
Copy link

J-HS-L commented Feb 16, 2022

Is this & #12480 resolved? Apologies in advance if I've completely missed it but;
Where is the detail outlining; [1] What the prob. was, & [2] What the fix was?

TY.

@zadjii-msft
Copy link
Member

We just recently had to move them from being in the packages root resources file to another one elsewhere in the tree. When we made that move (from ms-resource:AppNameDev to ms-resource:TerminalApp/ContextMenu/AppNameDev, now the startup task doesn't work anymore. But everywhere else that resource (ms-resource:TerminalApp/ContextMenu/AppNameDev) is used seems to work just fine. Turns out there's a platform bug that prevents this from working as expected.

The fix in #12491 was to copy our localized resources in TerminalApp/ContextMenu up into the root resources, so we could refer to them as just ms-resource:AppNameDev again. That's a viable workaround while we work on the platform fix.

DHowett added a commit that referenced this issue Feb 16, 2022
We chose to use the "ContextMenu" resource compartment when we
changed the package name to Terminal in #12264 because it was more
broadly localized than the rest of the application.

It appears as though some platform features have trouble with the
"more qualified" resource paths that #12264 required.

To fix this, we will:

1. Copy all of the ContextMenu localizations into CascadiaPackage's
   resource root
2. Switch all manifest resource paths to use resources from the package
   root.

Regressed in #12264
Closes #12384
Closes #12406 (tracked in microsoft/PowerToys#16118)

(cherry picked from commit 9501b23)
DHowett added a commit that referenced this issue Feb 16, 2022
We chose to use the "ContextMenu" resource compartment when we
changed the package name to Terminal in #12264 because it was more
broadly localized than the rest of the application.

It appears as though some platform features have trouble with the
"more qualified" resource paths that #12264 required.

To fix this, we will:

1. Copy all of the ContextMenu localizations into CascadiaPackage's
   resource root
2. Switch all manifest resource paths to use resources from the package
   root.

Regressed in #12264
Closes #12384
Closes #12406 (tracked in microsoft/PowerToys#16118)

(cherry picked from commit 9501b23)
@MS-Manikandan
Copy link
Author

Hi, could you let us know Is this issue is fixed?, I updated to v1.12.10393.0 but still I couldn't find Terminal under startup apps on windows 10.

@zadjii-msft
Copy link
Member

This is fixed in #12491 but that hasn't shipped yet unfortunately. The team's been dealing with some unexpected absence over the last few weeks. We appreciate your patience while we work on pushing that out.

@ghost
Copy link

ghost commented Mar 25, 2022

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

Handy links:

@ghost
Copy link

ghost commented Mar 25, 2022

🎉This issue was addressed in #12491, which has now been successfully released as Windows Terminal Preview v1.13.1073.: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-User Interface Issues pertaining to the user interface of the Console or Terminal Issue-Bug It either shouldn't be doing this or needs an investigation. 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. zPreview-Service-Queued-1.13 A floating label that tracks the current Preview version for servicing purposes. zStable-Service-Queued-1.12 A floating label that tracks the current Stable version for servicing purposes.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants