gsudo hangs when run from Windows Terminal started with wt alias

[dafzor]

I'm trying out gsudo and from cmd, pwsh or Windows Terminal shortcut it works as expected.

However when starting Windows terminal by the wt alias gsudo will "hang" and never shows the elevation prompt.

Further details:

• Windows 10 2004
• Windows Terminal 1.0.1401.0 (Store version)
• gsudo 0.7 and 0.5 ?? [ https://ci.appveyor.com/project/gerardog/gsudo/builds/33404236/artifacts ]

[gerardog]

gsudo 0.5 ??

AppVeyor builds dont have the right version numbers, my bad. :(

when starting Windows terminal by the wt alias

Could you please describe this "wt alias". What is it? How do you installed it? Is wt running as your current user? Not sure why that alias made a windows service launch WT (instead of the usual explorer.exe).

Thanks for your capture of the thread call stack. Is really helpfull. Looks like it's on an infinite loop on this function. I will check further.

[dafzor]

wt alias is a standard feature of Windows store apps.

You can check the ones on your system by typing "Manage app execution aliases" in the start menu to open the corresponding control panel:

edit:
some additional info:

• Windows Terminal declaration of the alias
• Manifest property reference

As for why it's launched by service I believe it's likely due to how it alias where implemented by Microsoft, most UWP apps also tend to start trough services. I tried checking for differences with process explorer and didn't really find anything.

Also the sudo package in chocolatey can run a Start-Process pwsh -verb runAs from a wt started terminal so elevation itself is possible.

[gerardog]

I've replaced GetParentProcessId implementation to one based on the NtQueryInformationProcess Api. It does not loop thru the process list, so it shouldnt hang.
Nonetheless I wasn't able to reproduce the issue, so, could you please test this build for me?

https://ci.appveyor.com/project/gerardog/gsudo/builds/33450338/artifacts

Thank you

[dafzor]

The build you linked seems to work as expected. Thanks for the quick fix.

[gerardog]

Great!

This issue should auto-close when this is merged to master.

[dafzor]

Out of curiosity did it really not behave the same on your system?

[gerardog]

It did not. I tried running WT from the command line with MsStore aliases (C:\Users\Me\AppData\Local\Microsoft\WindowsApps\wt.exe) and still it was created with explorer.exe parent process. (not svchost/sihost).
I tried to force a hang in the older GetParentProcessId implementation (based on CreateToolhelp32Snapshot) but I couldn't either.
(I wonder if you can still reproduce this after a reboot, which is a not a fix, but stil curious).

Anyway... I didn't liked much to iterate O(n) all processes to get one PPID. The new implementation just looks better to me. (IMHO, even if it is flagged as deprecated, NtDll.dll is not going away for another decade, because there is no better alternative).

[dafzor]

Tried following the steps you described and saw the same behavior.

It seems it only happens with opening the start menu, typing wt and pressing enter. So I assume the service it starts under is the one responsible for running the Windows 10 start menu.

Video: https://streamable.com/al5xbv

[gerardog]

The fix was released in v0.7.1.
Let me know if this or any other problem ocurrs.
Thanks for reporting the problem.