Registry of HKEY_CLASS_ROOT when registering a custom scheme with uap:Protocol is not cleaned up after uninstall

[HO-COOH]

Describe the bug

I have a WinUI3 packaged app registered a custom scheme in package.appxmanifest using

        <Extensions>
            <uap:Extension Category="windows.protocol">
                <uap:Protocol Name="testapp">
                    <uap:DisplayName>TestApp</uap:DisplayName>
                </uap:Protocol>
            </uap:Extension>
        </Extensions>

I found out the corresponding registry key Computer\HKEY_CLASSES_ROOT\testapp is not deleted after uninstalling the app.

I don't know any ways (other than Launcher.FindUriSchemeHandlersAsync, because I have cross-platform concerns, so I can't pull in winrt) to detect such scheme exist and launch it, so I use the registry key.

Steps to reproduce the bug

As description. Create a new WinUI3 C++ packaged app, then do the above.

Expected behavior

The registry key should be cleaned up.

Screenshots

No response

NuGet package version

Windows App SDK 1.6.0: 1.6.240829007

Packaging type

Packaged (MSIX)

Windows version

Insider Build (xxxxx)
Windows 10 19045

IDE

Visual Studio 2022

Additional context

Repro

[DarranRowe]

Have you managed to test this on any other versions of Windows beside the insider build that you mention? Have you tested this without using the Windows App SDK? The Protocol extension is an extension that is provided by Windows itself.

Okay, so I modified a small manual packaging test application that I had, it doesn't reference the Windows App SDK. I see the same thing happening on Windows 11 23H2.
Also, since HKCR is a merged view of HKLM and HKCU, it is HKCU\Software\Classes<protocol> that is hanging around.

[HO-COOH]

Reproducible on Windows 10 19045 and I added it.
@DarranRowe What does "The Protocol extension is an extension that is provided by Windows itself." mean? And how does your manual packaging project use that? I think nonetheless, it should get cleaned up by msix with some ways?

[DarranRowe]

@DarranRowe What does "The Protocol extension is an extension that is provided by Windows itself." mean?

Basically, this is a Windows bug. MSIX is not some external component, it is basically a rebranding of appx. The behaviour to install these packages is part of Windows itself, and is the functionality also used by the Add-AppxPackage cmdlet and the PackageManager runtime class.

And how does your manual packaging project use that?

There is no difference to how you are using it.

<?xml version="1.0" encoding="utf-8"?>
<Package
	xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10"
	xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10"
	xmlns:uap10="http://schemas.microsoft.com/appx/manifest/uap/windows10/10"
	xmlns:mp="http://schemas.microsoft.com/appx/2014/phone/manifest"
	xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
	IgnorableNamespaces="mp uap uap10 rescap">
	<Identity Name="Untrusted.CompositionUITest" Publisher="CN=Darran" Version="1.0.0.0" ProcessorArchitecture="x64" />
	<mp:PhoneIdentity PhoneProductId="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" PhonePublisherId="00000000-0000-0000-0000-000000000000" />
	
	<Properties>
		<DisplayName>CompositionUITest</DisplayName>
		<PublisherDisplayName>Untrusted Software</PublisherDisplayName>
		<Description>CompositionUITest test application.</Description>
		<Logo>Images\PackageLogo.png</Logo>
	</Properties>
	<Dependencies>
		<TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.19041.0" MaxVersionTested="10.0.22621.0" />
		<TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.19041.0" MaxVersionTested="10.0.22621.0" />
		<PackageDependency Name="Microsoft.VCLibs.140.00.UWPDesktop" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" MinVersion="14.0.33728.0" />
	</Dependencies>
	<Applications>
		<Application Id="App" Executable="CompositionUITest.exe" uap10:RuntimeBehavior="packagedClassicApp" uap10:TrustLevel="mediumIL">
			<uap:VisualElements
				DisplayName="CompositionUITest"
				Description="Composition Test Application"
				BackgroundColor="transparent"
				Square150x150Logo="Images\Logo150x150.png" Square44x44Logo="Images\Logo44x44.png">
			</uap:VisualElements>
			<Extensions>
				<uap:Extension Category="windows.protocol">
					<uap:Protocol Name="compuitest">
						<uap:DisplayName>CompositionUITest</uap:DisplayName>
					</uap:Protocol>
				</uap:Extension>
			</Extensions>
		</Application>
	</Applications>
	<Capabilities>
		<rescap:Capability Name="runFullTrust" />
		<rescap:Capability Name="allowElevation" />
	</Capabilities>
</Package>

As a side note, even though I am using uap10 to identify the application type, this does behave the same as setting EntryPoint to windows.fullTrustApplication.

I think nonetheless, it should get cleaned up by msix with some ways?

I totally agree. I only responded because I felt that the scope of the problem was a little underspecified.

[DrusTheAxe]

This sounds like a bug in the protocol deregistration work in the deployment pipeline. I've passed along word to the protocol handling team => https://task.ms/54265091

Thanks for reporting this!