Run as Administrator no longer works

[DJackman123]

With the latest build I am no longer able to launch Terminal as administrator. This isn't the same as #1872 because I only get the UAC prompt once and I'm not seeing the other message box as is reported there.

I was able to determine that this problem was introduced with commit 8ffff8e (#1948).

Environment

Windows build number: 10.0.18362.10005
Windows Terminal version (if applicable): 0.2.1991.0

Any other software?

Steps to reproduce

Try to launch the app as administrator

Expected behavior

UAC prompt appears then the elevated Terminal runs

Actual behavior

UAC prompt appears and the border of a window is displayed but the process hangs at that point. I have to kill the process with Task Manager.

[metathinker]

I've also been able to reproduce this problem on my own build of Terminal master (dca0ffe) and was about to file my own bug!

the border of a window is displayed but the process hangs at that point

I've found that:

• the application only freezes in the debug build; the release build crashes quickly
• after some time, the app will unfreeze and you'll get a Microsoft CRT dialog warning you that abort() was called, which you can use to kill the app.

From my debugging, it appears that Terminal crashes when trying to activate the Windows Runtime class TerminalApp.TitlebarControl; RoGetActivationFactory() returns "Class not registered" (HRESULT REGDB_E_CLASSNOTREG == 0x80040154).

This class was introduced yesterday as part of the faulty change 8ffff8e (PR #1948) noted above. I verified that rebuilding Terminal after going back to the immediately previous commit makes the problem disappear.

[metathinker]

I can reproduce the problem reliably when I run my own build of Terminal master after deploying the loose-file app package folder with PowerShell.

As a (possibly misleading!) point of interest, when I run the WindowsTerminal.exe "directly" from the loose-file package folder, rather than doing so by the Start menu or another UWP app activation path, a crash occurs at the same place regardless of whether the app is elevated or not.

[DHowett-MSFT]

This is a silly and complicated issue. At the heart of it:

Centennial applications that depend on WinRT classes cannot be launched as Administrator. Period. This is a bug, and one that's not likely to be fixed for a while. I'll go into details if somebody wants. 😄

EXCEPT: in 19H1, the app platform team introduced "side-by-side" registration-free WinRT. It's the same thing that makes double-click activation work for Windows Terminal! @metathinker correctly identified this, and it's not misleading at all.

We just have to keep a completely separate list of all activatable runtime classes in sync with the one in the AppX manifest.

This was difficult until 18362, when the manifest tool mt sprouted the ability to generate a manifest fragment from a WinMD file. Suddenly, life became worth living again.

The pull request #2043 finally lands some work that's been on my dev branch for three months. It should fix this entire class of issues, possibly forever.

[DHowett-MSFT]

And just to call out: 8ffff8e was not faulty; the existence of a split parallel universe manifest is what was faulty.

[fjpmota]

I had roughly the same problem - when I tried to run the application as an administrator I was getting 2 UAC prompts and then gave an error message. I managed to overcome the problem by installing the app in the administrator user profile. After that I can already launch the app as an administrator from my profile.