"Attach to the most recently used window" not working in preview

[vefatica]

I have

If I'm running the non-preview version (D:\wt\WindowsTerminal.exe) and I issue D:\wt\WindowsTerminal.exe nt, I get a new tab in the current window (the desired behavior).

If I'm running the preview (D:\wtp\WindowsTerminal.exe) and I issue D:\wtp\WindowsTerminal.exe nt, I get a new window/instance (not the desired behavior).

What's up with that? In the second case above, "-w 0" makes no difference.

I'm using these.

Microsoft Windows 10 Pro for Workstations
10.0.19045.6216 (2009, 22H2)
WindowsTerminal 1.22.2507.30001 (1.22.2111.0)
WindowsTerminal 1.23.2507.29002 (preview) (1.23.2102.0)

[vefatica]

I failed to mention that the undesirable behavior (not respecting "Attach ..." or -w 0) happens when the preview is elevated (the norm here) and not when it is unevevated. The non-preview version does not have this dependence.

[carlos-zamora]

Thanks for filing! Just to confirm, you are running both WindowsTerminal.exe and WindowsTerminal.exe nt elevated/?

The source and the target of the calls both need to be running at the same IL 😉

[vefatica]

I spent a while yesterday trying to get this working and failed. To confirm ...

I have these, both unzip installs and neither tinkered with.

v:\> which wt
wt is an external (App Path HKLM): D:\wt\windowsterminal.exe

v:\> which wtp
wtp is an external (App Path HKLM): D:\wtp\windowsterminal.exe

Running WTP elevated and issuing wtp nt, I get a new instance (elevated) and a new window.

Running WT (elevated or not) and issuing WT nt, or WTP unelevated and issuing WTP nt, I get the desired new tab in the existing window.

-w 0 doesn't help.

My new instance setting is "Attach to the most recently used window". Versions are as stated in my first post (the latest I believe).

Are you able to reproduce the behavior?

[vefatica]

Any more on this?

[vefatica]

Any more on this? I can't get -w 0 to do anything at all in the preview running elevated.

[vefatica]

What about this? I upgraded to 1.23.2681.0 and 1.24.2682.0 yesterday. Still -w 0 works in an elevated release version and not in an elevated preview version.

[vefatica]

I know more about this and I have a workaround for my original problem. But I don't fully understand what's happening. Further comments will be welcomed.

Reminders: I have these.

TCC 35.00.21 x64 (d:\tc35\tcc.exe)
Microsoft Windows 10 Pro for Workstations
10.0.19045.6332 (2009, 22H2)
WindowsTerminal 1.23.2509.25001 (1.23.2681.0)
WindowsTerminal 1.24.2509.25002 (preview) (1.24.2682.0)

And I have a SHELLEX.EXE, a wrapper for ShellExecuteEx. It's used below in its simplest form, with the default verb and the name of an executable.

I usually start WTP with an AutoHotKey key alias which runs c:\windows\system32\schtasks.exe /run /tn wtelevated.

The wtelevated task is on-demand with highest privileges and has the action d:\wtp\windowsterminal.exe. This avoids the UAC prompt. Run this way, neither wtp -w 0 sp nor d:\wtp\windowsterminal.exe -w 0 sp works later; they cause a new instance/window.

Edit: When those -w 0 commands fail, they are issued to an elevated shell in an elavated WTP.

If I change the action of the task to u:\shellex.exe d:\wtp\windowsterminal.exe, both of those -w 0 commands work later.

This is different from the behavior when, instead of a scheduled task, I start wtp from the Run dialog (Win+R), elevated (Ctrl+Shift+Enter), specifying d:\wtp\windowsterminal.exe and dismissing the UAC prompt; neither -w 0 command works later. That difference (task vs. Run dialog) surprises me.

WT (non-preview) behaves the same.

As I said, I don't fully understand what's happening. A (wild) guess is that it has something to do with message filtering. When the -w 0 commands work, the 0 instance receives WM_USER messages; when the -w 0 commands don't work, it doesn't receive those messages.

Edit: Those failing -w 0 commands are issued in an elevated shell in an elevated WTP.

[DHowett]

I can't believe we didn't think of this! When we weren't able to reproduce your issue, we should have assumed that when you said "elevated" you meant "launched as admin in possibly the most cracked way possible¹." 🙂

Anyway.

It looks like task scheduler starts the original instance of Terminal inside a job object. I am not certain we can support that.

Footnotes

1. Just like the time you were setting environment variables by injecting a DLL into Explorer rather than writing them to the registry like a normal person... ↩

[vefatica]

... and the new instance can't communicate with the 0 instance because the 0 instance is inside the job object but if my SHELLEX.EXE (in a job object) starts WT, that new WT (not in a job object???) can communicate with the 0 instance?

I don't fully understand but my immediate problem is solved.

Is it a message filtering issue?

[DHowett]

I don't know why the one in the job can't receive WM_COPYDATA from the one outside it.

Yes, ShellExecute works around this issue by making the shell launch Terminal in whatever way the shell usually launches applications. It breaks away from the job by asking somebody else to do the heavy lifting. :)