Einige Installationsprogramme registrieren sich unter der 32-Bit-Deinstallations-Hive auch auf 64-Bit-Windows. Prüfen Sie beide Ansichten, bevor Sie annehmen, der Eintrag sei weg.
Wenn der Hersteller ein Bereinigungsprogramm liefert, führen Sie es vor manuellen Registry-Löschungen aus. Diese Reihenfolge verringert die Chance, Dienste oder Treiber zurückzulassen.
Wenn sowohl x86- als auch x64-Einträge existieren, deinstallieren Sie zuletzt die Bittigkeit, die Sie tatsächlich installiert haben; falsche Reihenfolge lässt den Geistereintrag manchmal wieder auftauchen.
Trennen Sie „fehlende Dateien“ von „fehlendem Deinstaller“. Ein Geistereintrag verweist oft noch auf einen gültigen ProductCode, obwohl das Ziel von UninstallString gelöscht wurde. Notieren Sie die GUID-ähnlichen Kennungen in der Registry und vergleichen Sie sie mit einem MSI-Protokoll, falls vorhanden; abweichende GUIDs bedeuten, dass Sie eine andere Edition betrachten als das Installationsprogramm erwartet.
Auf 64-Bit-Windows können 32-Bit-Registrierungen unter WOW6432Node liegen, während native 64-Bit-Einträge daneben ohne dieses Suffix stehen. Behandeln Sie sie wie parallele Telefonbücher – nur eine Seite zu leeren ist der Grund, warum die Systemsteuerung behauptet, die App existiere noch.
Nach einer fehlgeschlagenen Deinstallation starten Sie das aktuelle Installationsprogramm des Herstellers erneut; viele bieten einen „Cleanup“- oder „Alle Komponenten entfernen“-Modus, der den eigenen ProductCode besser versteht als manuelles Löschen von Schlüsseln. Manuelle Bearbeitung ist der letzte Ausweg, nicht der erste Zug.
Wenn Windows Update oder Store-Komponenten beteiligt sind, pausieren Sie und lesen Sie zuerst die Microsoft-Anleitung. Das falsche Servicing-Schlüssel zu löschen kann die komponentenbasierte Wartung beschädigen; bleiben Sie beim vom Hersteller dokumentierten produktspezifischen Teilbaum.
Wenn das Betriebssystem endlich zustimmt, dass das Produkt weg ist, starten Sie neu und installieren Sie mit dem neuesten Build von der Herstellerseite – nicht von einem alten USB-Stick –, damit die ProductCode-Ausrichtung zu den Support-Skripten passt.
ARPCache kann eine Neustart-Runde lang die Realität maskieren. Wenn die Systemsteuerung sofort nach der Bereinigung noch ein entferntes Produkt listet, starten Sie einmal neu, bevor Sie weitere Registry-Löschungen verfolgen; zwischengespeicherte Oberflächeneinträge hinken manchmal hinter der tatsächlichen Deinstallations-Hive her.
Seite-an-Seite-x86/x64-Paare teilen oft eine einzige Verknüpfung. Die Verknüpfung aus Public\Desktop zu löschen, ohne beide Deinstallationseinträge zu entfernen, ist der Grund, warum „Geister“-Verknüpfungen wieder auftauchen und ins Leere zeigen.
Wenn MSI-basierte Pakete einen kaputten Upgrade-Pfad hinterlassen, führen Sie die „Cleanup“-EXE des Herstellers mit Protokollierung aus und vergleichen Sie verbleibende ProductCodes mit deren Support-Matrix. Blindes GUID-Stöbern skaliert schlecht auf gemeinsam genutzten PCs – siehe Windows-PCs mit mehreren Benutzern.
Wenn Sie nach der Herstellerbereinigung weiter „bereits installiert“ sehen, erfassen Sie ausführliche msiexec /i product.msi-Protokolle von einer Wegwerf-VM mit derselben OS-Patchstufe; Unterschiede in den Servicing-Stacks erklären oft unmögliche Installationen nur auf einem Rechner.