.NET Runtime Uninstall Registry Inconsistency on Some Systems

Question

.NET Runtime Uninstall Registry Inconsistency on Some Systems

ZOHO CORPORATION PRIVATE LIMITED 20

Hi Microsoft Support Team,

We are observing inconsistent behavior while uninstalling .NET Core components (ASP.NET Core Runtime, .NET Desktop Runtime, .NET Runtime, and .NET SDK) through Programs and Features (Control Panel) on a subset of Windows systems.

Issue Description

When uninstalling the .NET components from Control Panel, we observed the following behavior on only some systems:

The application is removed from Programs and Features.
However, the corresponding registry entry under:

  HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{GUID}

remains present.

This results in an inconsistent state where the application no longer appears in Control Panel, but the uninstall registry key is still retained.

Additional Observation

We also observed the reverse scenario:

If we manually delete the corresponding Uninstall registry key, the application is immediately removed from Programs and Features.

This indicates that the Control Panel entry is directly associated with the uninstall registry information. However, in the affected systems, uninstalling through Control Panel does not consistently remove the registry entry. It only removed "UninstallString" from the registry path.

Questions

We would appreciate your guidance on the following:

Why does the uninstall process leave the Uninstall registry entry behind on only some systems?
Is this a known issue with Windows Installer or the .NET uninstall process?
What conditions can cause the registry cleanup to fail while the product is removed from Control Panel?
Are there any known issues specific to .NET Runtime, ASP.NET Core Runtime, Desktop Runtime, or SDK uninstall that could result in this behavior?
Is there a Microsoft-recommended method to repair or clean up these orphaned uninstall registry entries?

This issue has been observed only on a subset of systems, while the uninstall process works as expected on other machines.

We would appreciate any guidance regarding the root cause and the recommended resolution.

Kind regards,
Haritha D

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Hello,

What you're describing isn't expected behavior. During a successful uninstall, the corresponding entry under:

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall{GUID}

(or the 64-bit equivalent) should normally be removed by the installer.

If the registry key remains while only the UninstallString value is removed, it generally indicates that the uninstall completed only partially or that the installer encountered an issue during its cleanup phase. A few things to investigate are:

Compare the affected and unaffected systems for differences in the installed .NET version, installation source (offline installer, Visual Studio, Windows Update, Winget, etc.), and Windows build.
Check the Windows Installer logs and Event Viewer (Application and Setup logs) for MSI or installer-related errors during the uninstall.
If verbose MSI logging is available (msiexec /x {ProductCode} /L*V uninstall.log), review the log to determine whether the registry removal actions completed successfully.
Verify that no endpoint security, application control, or registry protection software is preventing modification of the uninstall registry key.
Confirm that the account performing the uninstall has sufficient administrative privileges and that no Group Policy or registry permissions differ between affected and unaffected machines.

If this behavior is reproducible only with specific .NET Runtime or SDK versions, it would also be helpful to identify the exact version (for example, .NET 8 or .NET 9) and whether it was installed via the standalone installer, Visual Studio, or another deployment mechanism.

If you can provide the .NET version, Windows build, and whether the affected components were installed via MSI, Visual Studio, Windows Update, or another deployment method, it may help narrow down whether this is a product-specific issue or an environmental one.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.

ZOHO CORPORATION PRIVATE LIMITED 20 Reputation points

2026-07-29T01:23:19.3166667+00:00

Hi Allan Solomon Mejia,

Thank you for the details. We are experiencing a similar issue, but in our case the environment is Windows Server 2016 with ASP.NET Core 5.0 and .Net runtime 5.0.

We would like to know whether Microsoft is aware of any similar runtime registration inconsistencies affecting Server 2016 and .NET Core 5.0.
Allan Solomon Mejia 9,000 Reputation points

2026-07-29T01:35:09.3633333+00:00

Thanks for sharing your environment. At this time, I'm not aware of any documented Microsoft issue that specifically affects Windows Server 2016 with ASP.NET Core 5.0/.NET 5 and causes runtime registration inconsistencies.

Since .NET 5 reached end of support on May 10, 2022, it's possible you're encountering an environment-specific issue rather than a known product defect. If you haven't already, I'd recommend verifying:

The output of dotnet --info and dotnet --list-runtimes

Whether the ASP.NET Core Hosting Bundle is correctly installed or repaired

The registry entries under HKLM\SOFTWARE\dotnet\Setup\InstalledVersions

Any recent Windows updates or deployment changes preceding the issue

If multiple customers continue to report the same behavior, a Microsoft engineer or moderator may be able to confirm whether there's an emerging pattern. In the meantime, if your application supports it, testing on a supported LTS release such as .NET 8 can help determine whether the issue is specific to the unsupported .NET 5 runtime.