Targeting current instance with "-w 0" command line doesn't work if running as administrator

Windows Terminal version (or Windows build number)

1.7.572.0

Other Software

No response

Steps to reproduce

Launch Windows Terminal as administrator
Run the command line: wt -w 0 nt

Expected Behavior

This should open a new tab in the current window

Actual Behavior

Launches a new instance of Windows Terminal

It would make sense that I wouldn't be able to send commands to other WT windows that were running as admin, but running a command specifically targeting the current window should still work (as a special case if necessary).

Michael Niksa (@miniksa)

Weird, because I definitely can't repro this locally. Michael Niksa (@miniksa) Do you know if there's a way I could have David Jackman (@DJackman123) here collect the events emitted to a particular tracelogging GUID and send them to me? That is what all that logging is for after all

Right, this is when you run wt -w 0 from an application hosted in the admin wt?

Michael Niksa (@miniksa)

Weird, because I definitely can't repro this locally. Michael Niksa (@miniksa) Do you know if there's a way I could have David Jackman (@DJackman123) here collect the events emitted to a particular tracelogging GUID and send them to me? That is what all that logging is for after all

Mike Griese (@zadjii-msft), you could ensure that the GUID you're thinking about is listed in src/ConsolePerf.wprp and then have David Jackman (@DJackman123) load that into Windows Performance Recorder with the Add Profiles... button in the bottom left, start the trace, repro the thing, then send you the recorded ETL file.

I've got a version of that file laying around that has Terminal GUIDs in it... Just a sec 😄

Here is a version of the WPR profile that has all the Terminal GUIDs.

Here is a version of the WPR profile that has all the Terminal GUIDs.

Dude. Put that in a PR and check that in.

Playing around with this a bit more, I'm seeing this behavior: 1. Start WT from the Start menu as administrator 2. Run: wt -w 0 nt 3. This opens a new instance of WT. It is also running elevated. 4. In the new instance, run: wt -w 0 nt 5. This does not open a new instance of WT, but correctly creates a new tab in the current instance (opened in step 3). So it's not the fact that it's elevated that is causing the problem. It's something else around how it's launched from the Start menu? But when I launch WT non-elevated from the Start menu it works correctly in the first instance.

huh. I don't love the implications that has on our activation stack.

Hey, are you getting a different config file when you run from the Run dialog?

What specifically do you mean by "different config file"?

Huh. Nothing is throwing any errors in this trace. Nothing is obviously wrong (other than the second window being established as the monarch).

PID 56056 starts
- Registers as the COM server for the Monarch class
- Creates a monarch (its own process)
- Starts up totally normally.
PID 121072 starts
- Registers as the COM server for the Monarch class
- Creates a monarch IN ITS OWN PROCESS (here, winrt::create_instance should have used the one that PID 56056 had already registered
- Starts up normally as if it was the monarch
PID 120788 starts
- Registers as the COM server for the Monarch class
- Creates a monarch in PID 121072
- Everything proceeds normally from here on out

Because that second process effectively sniped the Monarch registration, it's performed a coup. Now the first window thinks it's the king but every other window doesn't, so the first window is totally isolated. I'm gonna need to reach out to the COM folks on this one. I did not think that it was possible for one process to snipe the CoRegisterClassObject of another process.

idly: maybe the alias is pointing at a different version of the Terminal? Or like, a different exe? So the first one opens the ....

Nah that doesn't make sense. The Monarch is separated by "SKU", so Dev always talks to the same GUID, Preview always talks on a second GUID, and Release always on a third GUID, and those haven't changed. So if you did run Stable from the Start Menu, and wt.exe was pointing at Preview, then those windows would have wholly different settings. So that's not it.

Presumably, when you're in this state, running the "Identify Window" command gives "Window: 1" for both the windows.

Filed MSFT:39320463 to track. From the mail thread, this doesn't seem like our fault, but we should still figure it out.

Presumably, when you're in this state, running the "Identify Window" command gives "Window: 1" for both the windows.

Confirmed. Actually, I have 3 windows open. Two are elevated, and one is not. ALL THREE indicate "Window: 1" in response to the Identify Window command from the command palette.

I can confirm that the trick of running wt -w 0 nt again in the window that was launched (but shouldn't have launched) by a wt -w 0 nt command indeed does work, and it launches a new tab in this new window.

So, I guess the workaround will be to immediately issue a wt -w 0 nt command after launching an elevated wt.exe instance, and then close the first window. Things seem to work as expected after that.

Interestingly, I see that doing a wt -w 0 nt in EITHER of the elevated windows will result in a new tab appearing in the second window.

edit: I just reproduced this on a second machine.

Jeff Whiteside (@jsidewhite)

Okay we got some heavy investigative help on this on. From the internal bug notes:

Flow is,

User launches WindowsTerminal.exe as admin. Has Token A.

WindowsTerminal.exe also launches an OOP COM server with Token A.

Inside, OpenConsole.exe launches

Inside, Powershell.exe launches, but .NET changes the token to add SeDebugPrivilege (for reasons). Token B!

So now user has a normal looking terminal, but the tokens are already in a weird state between window process and shell process.

User tries to open new tab with "wt.exe -w 0 nt" in terminal.

wt.exe launches. With Token B (SeDebugPrivilege)!

It then launches (the same) OOP COM. This should just fetch the existing instance from earlier, but,

COM tries to find existing server

Finds earlier instance

Matches tokens Token A (first WindowsTerminal.exe instance) and Token B (new wt.exe instance).

Tokens are different, so it makes a new OOP server. i.e. new window.

now, if you change your default shell from powershell.exe -> cmd.exe, then the bug goes away!

First. This doesn't repro on Desktop, but does on Centennial because there is an appmodel policy that changes COM's token matching function to be stricter for Centennial than Desktop, AppModelPolicy_ComTokenMatchingForAAAServers_UseNtCompareTokens.

Second. Supposedly the stricter token matching policy is only used because there is no classInfo (IComClassInfo) retrieved for your COM class.
    wil::com_ptr_nothrow<IComClassInfo> classInfo;
    RETURN_IF_FAILED(TryGetClassInfoForActivation(*pActParams, &classInfo));
because there's a bug in COM where they calculate the right thing for packages, but then clobber it by immediately recalculating that thing for Desktop. (I'm fuzzy on this part.)

There's an upstream bug, MSFT:39730477 that this was now duped to.

Major thanks to Jeff Whiteside (@jsidewhite) and Brian Alker (@brialmsft) for digging in on the COM side of things

Navigation Menu

Repository navigation

Targeting current instance with "-w 0" command line doesn't work if running as administrator #9628

Windows Terminal version (or Windows build number)

Other Software

Steps to reproduce

Expected Behavior

Actual Behavior

19 remaining items

now, if you change your default shell from powershell.exe -> cmd.exe, then the bug goes away!

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Targeting current instance with "-w 0" command line doesn't work if running as administrator #9628

Description

Windows Terminal version (or Windows build number)

Other Software

Steps to reproduce

Expected Behavior

Actual Behavior

Activity

zadjii-msft commented on Mar 26, 2021

DHowett commented on Mar 26, 2021

miniksa commented on Mar 26, 2021

DHowett commented on Mar 26, 2021

DHowett commented on Mar 26, 2021

miniksa commented on Mar 26, 2021

DJackman123 commented on Mar 26, 2021

DHowett commented on Mar 26, 2021

DJackman123 commented on Mar 26, 2021

19 remaining items

zadjii-msft commented on Mar 16, 2022

zadjii-msft commented on Mar 17, 2022

zadjii-msft commented on Apr 28, 2022

AltitudeApps commented on May 29, 2022

zadjii-msft commented on Jul 17, 2023

now, if you change your default shell from powershell.exe -> cmd.exe, then the bug goes away!

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions