Edge error 1714 / 1612: “The older version of Microsoft Edge cannot be removed”

You open Event Viewer on a Windows PC or server and the Application log has the same MsiInstaller error over and over, dated a few weeks apart:

Product: Microsoft Edge -- Error 1714. The older version of Microsoft Edge cannot be removed.
Contact your technical support group. System Error 1612.

It is logged as Event ID 11714, and it lines up with Edge’s update cycle: every time Edge moves to a new version, a fresh copy appears. Meanwhile Programs and Features shows a single, current Edge, and the browser works perfectly. Nothing is broken. It is log noise, but it is the kind of noise that hides real problems and trips monitoring alerts, so it is worth ten minutes to clear.

This article walks through the diagnosis the way it actually went on a real machine, because the fix depends on proving what the orphan is before you delete anything from the registry.

Applies to: every Windows version that runs Microsoft Edge (Chromium): Windows 10, Windows 11 and Windows Server. Every command below runs in an elevated PowerShell window (right-click, Run as administrator).

What is going on

Edge keeps itself up to date with its own updater, not Windows Installer. But long ago, many PCs got Edge from an MSI package, either pushed by a deployment tool such as Intune, SCCM or Ivanti, or installed by hand from the enterprise download. When that MSI install was later replaced, it did not always clean up after itself. It can leave a Windows Installer product registration behind: the registry still says “an Edge product exists here” but there is no installed package to go with it.

Every time the Edge updater runs a version bump it tries to reconcile that stale registration, asks Windows Installer to remove the “older version”, Windows Installer cannot find a source package for it, and you get error 1714 with system error 1612 (“the installation source for this product is not available”). Then it gives up until the next update.

Diagnosis

1. Rule out the easy case: a duplicate uninstall entry

First check what Windows thinks is installed. If there are two Edge entries in the Uninstall keys, one old and one current, that stale entry is your answer and you can skip to the fix.

Get-Package -Name "*Edge*" -ErrorAction SilentlyContinue | Select-Object Name, Version, ProviderName

Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall","HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall" |
  Get-ItemProperty | Where-Object { $_.DisplayName -like "*Edge*" } |
  Select-Object DisplayName, DisplayVersion, UninstallString, PSChildName

On the machine in question this returned one Edge entry, at the current version. No stale duplicate, so the easy case was out.

2. Look at the event itself

Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='MsiInstaller'; Id=11714} -MaxEvents 5 |
  Select-Object TimeCreated, @{n='Message';e={$_.Message}} | Format-List

The message text does not include a product code (GUID), which would have made this quick. What it does give you is the timing: the entries match Edge update cycles, not a daily schedule. That points at the updater, not at something a user is doing.

3. Find Windows Installer product registrations for Edge

Windows Installer keeps its own list of products, separate from Programs and Features. Search it for anything named Edge:

Get-ChildItem "HKLM:\SOFTWARE\Classes\Installer\Products" -Recurse -ErrorAction SilentlyContinue |
  Get-ItemProperty | Where-Object { $_.ProductName -like "*Edge*" } |
  Select-Object ProductName, ProductVersion, PSChildName

This is where the orphan showed up: a second Edge product with a blank ProductVersion, under a key named 5F860D974E0441636A383E15FD04EBDB. (That is a product GUID in Windows Installer’s reversed form. Yours will be different.) A blank version on a product registration is the signature of an incomplete or abandoned entry. A real install always has one.

4. Prove it is orphaned

Do not delete on a hunch. A genuine install has a matching InstallProperties key under the Installer UserData branch, with a LocalPackage that points at the cached MSI. An orphan does not. Check both, replacing the product code with the one you found:

Get-ItemProperty "HKLM:\SOFTWARE\Classes\Installer\Products\<product code>" -ErrorAction SilentlyContinue |
  Select-Object ProductName, ProductIcon, PackageCode

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\<product code>\InstallProperties" -ErrorAction SilentlyContinue |
  Select-Object DisplayName, DisplayVersion, LocalPackage

The first query returned a product name, icon and package code. The second returned nothing: no DisplayVersion, no LocalPackage. That is the proof. The registration is advertised but has no package behind it, so Windows Installer can never complete the removal Edge keeps asking for. Every update cycle it tries, fails, and logs 1714 / 1612.

Root cause

An orphaned Windows Installer product registration under HKLM:\SOFTWARE\Classes\Installer\Products\<product code>, left over from an old MSI-based Edge install that never fully cleaned up. It has product metadata but no InstallProperties or LocalPackage, so Windows Installer has no source to remove it from. The Edge you actually use is not involved and is not affected.

The fix

You are editing the registry. Export the key first, exactly as shown, so you can put it back with a double-click if anything looks wrong. Only remove a product code that failed step 4. If the InstallProperties query returned data, it is a real install: leave it alone.

# Back up the key first
reg export "HKLM\SOFTWARE\Classes\Installer\Products\<product code>" "$env:TEMP\EdgeOrphan_backup.reg"

# Remove the orphaned registration
Remove-Item "HKLM:\SOFTWARE\Classes\Installer\Products\<product code>" -Recurse -Force

# Also remove any matching orphaned Features entry
Get-ChildItem "HKLM:\SOFTWARE\Classes\Installer\Features" -ErrorAction SilentlyContinue |
  Where-Object { $_.PSChildName -eq "<product code>" } |
  Remove-Item -Recurse -Force -ErrorAction SilentlyContinue

Replace <product code> with the value from step 3. One thing to expect: on this machine Remove-Item came back with “Cannot find path… because it does not exist” even though the read a moment earlier had worked. HKLM:\SOFTWARE\Classes is a merged view of two registry hives, and the key was in fact gone. Verify before you chase it.

Verification

# Confirm the orphaned key is gone
Test-Path "HKLM:\SOFTWARE\Classes\Installer\Products\<product code>"   # expect False

# Force an Edge update check and watch for a new 11714 in the next few minutes
& "C:\Program Files (x86)\Microsoft\EdgeUpdate\MicrosoftEdgeUpdate.exe" /ua /installsource scheduler
Start-Sleep -Seconds 30
Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='MsiInstaller'; Id=11714; StartTime=(Get-Date).AddMinutes(-5)} -ErrorAction SilentlyContinue

No new 11714 event after the forced update check is a good sign. Because the error only ever fired on real version bumps, the final confirmation is a quiet log after the next actual Edge update. Put a note in your calendar and check the Application log again in about a week.

Notes

• To find the orphan on any machine, look for the Edge entry under HKLM:\SOFTWARE\Classes\Installer\Products with a blank ProductVersion. That is what sets it apart from the live install.
• HKLM:\SOFTWARE\Classes\Installer\... is a reflected view. A Remove-Item that reports “path does not exist” right after a successful read is not necessarily a failure. Re-check with Test-Path before assuming the removal did not happen.
• Seeing this on many machines at once? Check whether a deployment tool (Intune, SCCM, Ivanti or similar) ever pushed an MSI-based Edge Enterprise package instead of letting Edge update itself. That is the usual origin of the orphaned registration, and the fix above can be scripted and pushed the same way.

Got a different flavour of this? Error 1714 shows up for other products with the same root cause. If your log has one that will not go away, post the event text in the Help forum and we will work through it. The best answer earns points on Top of the Stack.