Viele Windows-Nutzer suchen nach einer einzigen, vollständigen Programmliste – etwa, um Speicher freizugeben, ein Problem zu diagnostizieren oder zu prüfen, ob eine Software wirklich installiert ist. In der Praxis führt das oft zu Verwirrung: Die Anzeige in den Windows-Einstellungen unterscheidet sich von der klassischen Systemsteuerung, und im Startmenü oder in Programmordnern tauchen wiederum andere Einträge auf. Das liegt nicht an „fehlenden“ Programmen, sondern daran, dass Windows Installationen auf mehreren Wegen verwaltet: klassische Setup-Installationen, Store-Apps, portable Anwendungen ohne Installation sowie Systemkomponenten und Treiber werden unterschiedlich erfasst. Wer nachvollziehbar entscheiden will, was tatsächlich installiert ist, braucht daher eine Einordnung der jeweiligen Quelle und muss wissen, welche Arten von Software dort überhaupt erscheinen – und welche bewusst nicht.

Inhalt
- Warum es keine einzige „Programmliste“ gibt: Installationsarten und Datenquellen in Windows
- Die wichtigsten Stellen in Windows: Einstellungen, Systemsteuerung, Startmenü und App-Ordner richtig lesen
- Einstellungen: „Installierte Apps“ als zentrale, aber nicht lückenlose Übersicht
- Systemsteuerung: „Programme und Features“ für klassische Win32-Installationen
- Startmenü: „Alle Apps“ ist eine Startliste, kein Installationsnachweis
- App-Ordner und Installationspfade: Dateien sind vorhanden, aber die Zuordnung ist heikel
- Typische Stolpersteine: Doppelte Einträge, fehlende Programme, „komische“ Namen
- Wenn Einträge fehlen oder doppelt sind: typische Ursachen, Überprüfung per Registry, Paketverwaltung und Uninstallern
Warum es keine einzige „Programmliste“ gibt: Installationsarten und Datenquellen in Windows
Windows führt installierte Software nicht in einer einzigen, universellen Liste. Stattdessen existieren mehrere Datenquellen, die jeweils einen anderen Zweck erfüllen: Einige sind für die Deinstallation klassischer Desktop-Programme gedacht, andere verwalten App-Pakete aus dem Microsoft Store, wieder andere bilden Komponenten ab, die eher Betriebssystemfunktionen als „Programme“ sind. Daraus entsteht die häufige Irritation, dass in einer Übersicht Einträge fehlen, doppelt erscheinen oder anders heißen als erwartet.
Der Kern des Problems liegt in der Installationsart. Ein MSI-Installer schreibt andere Informationen als ein Setup.exe, ein Store-App-Paket wird über AppX/MSIX verwaltet, portable Programme hinterlassen unter Umständen gar keinen Eintrag, und Systemfeatures werden über Windows-Komponentenmechanismen geführt. Jede dieser Klassen landet in einer anderen „Programmliste“ – oder in gar keiner.
Installationsarten: Was Windows technisch unterscheidet
Klassische Desktop-Anwendungen (Win32) registrieren sich typischerweise für Wartung, Reparatur und Deinstallation. Dafür werden Einträge in der Registry angelegt, die Name, Version, Publisher und eine Deinstallationsroutine enthalten. Diese Informationen speisen sowohl die modernen Einstellungen als auch die klassische Systemsteuerungsansicht. Entscheidend ist: Nur Installationen, die diese Registrierung vornehmen, tauchen dort zuverlässig auf.
Apps aus dem Microsoft Store (UWP bzw. verpackte Desktop-Apps als MSIX) werden als Pakete verwaltet. Sie erscheinen in der App-Liste der Einstellungen, können aber je nach Pakettyp in der klassischen Systemsteuerung fehlen oder dort anders gruppiert werden. Zusätzlich existieren bereitgestellte (provisionierte) App-Pakete, die für neue Benutzerkonten vorbereitet sind und erst bei der ersten Anmeldung tatsächlich für das jeweilige Konto installiert werden.
Daneben gibt es Software ohne formale Installation: portable Tools, entpackte ZIP-Programme oder Anwendungen, die lediglich Dateien unter C:\Program Files, C:\Program Files (x86) oder im Benutzerprofil ablegen. Ohne registrierten Uninstall-Eintrag kann Windows solche Programme nicht in „Installierte Apps“ aufführen, obwohl sie faktisch nutzbar sind.
Datenquellen in Windows: Woher die unterschiedlichen Listen kommen
Die sichtbaren Übersichten bauen auf unterschiedlichen Quellen auf. Die moderne Ansicht in den Einstellungen kombiniert mehrere Mechanismen (Win32-Uninstall-Einträge, AppX/MSIX-Pakete) und ermittelt Größenangaben teils aus Paketmetadaten, teils aus geschätzten Werten. Die klassische „Programme und Features“-Ansicht konzentriert sich hingegen auf klassische Installationsregistrierungen.
Für eine technische Einordnung helfen die wichtigsten Quellen, die Windows selbst ausliest oder die Administratoren zur Inventarisierung verwenden. Diese Quellen sind nicht identisch, überschneiden sich aber:
- Win32-Deinstallationsdaten (Registry, 64‑Bit):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall - Win32-Deinstallationsdaten (Registry, 32‑Bit auf 64‑Bit Windows):
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall - Benutzerbezogene Win32-Einträge (pro Benutzerkonto):
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall - Store-/AppX-/MSIX-Pakete pro Benutzer:
Get-AppxPackage - Bereitgestellte (provisionierte) Pakete für neue Benutzer:
Get-AppxProvisionedPackage -Online - Windows-Features (Komponenten, optional):
optionalfeatures.exeGet-WindowsOptionalFeature -Online
Warum Einträge fehlen, doppelt sind oder „falsch“ wirken
Fehlende Programme sind häufig kein Hinweis darauf, dass sie nicht installiert sind, sondern dass sie in einer anderen Kategorie geführt werden. Portable Programme erscheinen meist nur als Ordner und Verknüpfungen, nicht als verwaltete Installation. Umgekehrt können Anwendungen in mehreren Listen auftauchen: Ein Win32-Programm kann zusätzlich ein Store-Front-End besitzen, oder ein Hersteller installiert getrennte Komponenten (Hauptprogramm, Runtime, Updater), die getrennte Uninstall-Einträge erzeugen.
Auch die Frage „für wen“ ein Programm installiert wurde spielt eine Rolle. Software kann maschinenweit (für alle Benutzer) oder nur für ein einzelnes Benutzerkonto installiert sein. In letzterem Fall existiert der Eintrag typischerweise nur unter HKEY_CURRENT_USER und kann in bestimmten Ansichten fehlen, etwa wenn aus einem anderen Konto heraus geprüft wird oder ein Inventarisierungstool nur maschinenweite Einträge ausliest.
Hinzu kommen systemnahe Komponenten: Treiberpakete, Visual-C++-Redistributables, .NET-Desktop-Runtimes, WebView2 oder Gerätesoftware werden oft bewusst sichtbar geführt, weil sie aktualisiert und deinstalliert werden können. Andere Bestandteile sind dagegen Windows-Bestandteil und erscheinen eher als Feature oder gar nicht als „Programm“, obwohl sie Dateien und Dienste mitbringen.
| Kategorie | Typische Datenquelle / Liste | Warum sie dort (nicht) erscheint |
|---|---|---|
| Klassische Desktop-Programme (MSI/Setup) | Einstellungen „Installierte Apps“; Systemsteuerung „Programme und Features“; Registry ...\Uninstall |
Registriert Deinstallation und Metadaten; ohne Uninstall-Eintrag kann der Listeneintrag fehlen |
| Store-Apps (UWP/MSIX) | Einstellungen „Installierte Apps“; PowerShell Get-AppxPackage |
Paketverwaltung statt klassischer Uninstall-Schlüssel; Systemsteuerung kann unvollständig sein |
| Provisionierte Apps (für neue Konten) | PowerShell Get-AppxProvisionedPackage -Online |
Noch nicht pro Benutzer installiert; sichtbar als „bereitgestellt“, nicht zwingend als nutzbare App im aktuellen Konto |
| Portable/entpackte Programme | Dateisystem (z. B. C:\Tools, Benutzerprofil) |
Keine Installationsregistrierung; Windows hat keine verlässliche Quelle für eine Programmliste |
| Windows-Features und Komponenten | optionalfeatures.exe; PowerShell Get-WindowsOptionalFeature -Online |
Funktionalität des Betriebssystems, nicht als „App“ deinstallierbar; getrennte Verwaltung |
Konsequenz für die Praxis: Welche Liste wofür taugt
Eine „vollständige“ Übersicht entsteht nur, wenn mehrere Quellen zusammengedacht werden: Win32-Deinstallationsdaten decken den klassischen Softwarebestand ab, AppX/MSIX listen Store- und Paket-Apps je Benutzerkonto, und Windows-Features bilden Systemkomponenten. Die sichtbaren Windows-Listen sind deshalb stets eine kuratierte Perspektive, keine absolute Wahrheit über alle ausführbaren Dateien auf dem System.
Für die Zuverlässigkeit zählt, ob eine Anwendung verwaltet installiert wurde. Sobald eine Installation eine Deinstallationsroutine registriert oder als Paket geführt wird, ist sie in den passenden Listen nachvollziehbar. Fehlt ein Eintrag, liegt das meist an der Installationsform (portable, manuell kopiert, Skript-Deployment ohne Registrierung) oder an der Konten-/Kontextfrage (nur für einen Benutzer installiert, aktuell aber in einem anderen Kontext geprüft).
Windows zeigt installierte Software nicht an einer einzigen Stelle vollständig an. Mehrere Übersichten existieren parallel, weil sie unterschiedliche Installationsarten und Verwaltungsmodelle abdecken: klassische Desktop-Programme (MSI/Setup), Store-Apps (AppX/MSIX), vorinstallierte System-Apps sowie Komponenten, die absichtlich nicht wie „normale Programme“ erscheinen. Wer die Listen korrekt interpretiert, erkennt schnell, warum Einträge fehlen, doppelt wirken oder unter anderem Namen auftauchen.
Einstellungen: „Installierte Apps“ als zentrale, aber nicht lückenlose Übersicht
In Windows 11 führt der Weg über Einstellungen → Apps → Installierte Apps. In Windows 10 heißt der Bereich meist Einstellungen → Apps → Apps & Features. Diese Ansicht bündelt typische Desktop-Anwendungen und viele Apps aus dem Microsoft Store in einer gemeinsamen Liste. Sie eignet sich für eine schnelle Bestandsaufnahme und für Standard-Deinstallationen, ist aber nicht als forensisch vollständiges Inventar gedacht.
Einträge werden hier teilweise aus unterschiedlichen Quellen zusammengeführt. Bei klassischen Programmen stammen Name, Hersteller, Version und Deinstallationsroutine oft aus dem Installer. Bei Store-Apps kommen Paketname und Metadaten aus dem App-Paket. Dadurch entstehen typische Abweichungen: Manche Programme erscheinen ohne Versionsnummer, andere unter einem Produktnamen, der sich vom Startmenü-Eintrag unterscheidet, und wieder andere werden als mehrere Komponenten gelistet (z. B. Laufzeitumgebungen oder Sprachpakete).
Systemsteuerung: „Programme und Features“ für klassische Win32-Installationen
Die klassische Übersicht Systemsteuerung → Programme → Programme und Features bleibt für viele Desktop-Installationen die verlässlichste Einzelquelle. Sie listet typischerweise Software, die sich über Windows Installer (MSI) oder über registrierte Uninstaller in Windows eingetragen hat. Genau diese Voraussetzung erklärt, warum bestimmte Anwendungen dort fehlen: Portable Tools, viele Store-Apps sowie manche „per Benutzer“ installierte Programme registrieren sich nicht für diese Liste.
Zusätzlich existiert in der Systemsteuerung unter Windows-Features aktivieren oder deaktivieren eine eigene Welt: Hier stehen Betriebssystem-Komponenten (z. B. .NET Framework, Hyper-V, SMB-Funktionen). Diese Elemente sind keine „Programme“ im üblichen Sinne und erscheinen deshalb nicht zuverlässig in den App-Listen. Wer prüfen will, ob eine Funktion Bestandteil von Windows ist, findet sie eher dort als in den App-Übersichten.
| Stelle in Windows | Typischer Inhalt / was häufig fehlt |
|---|---|
| Einstellungen → Apps → Installierte Apps | Viele Desktop-Programme und Store-Apps; kann Systemkomponenten, Treiberpakete, portable Tools und einige pro-Benutzer-Installationen unvollständig abbilden |
| Systemsteuerung → Programme und Features | Vor allem klassische Win32-/MSI-Installationen mit registriertem Uninstaller; Store-Apps und Windows-Features fehlen in der Regel |
| Startmenü → „Alle Apps“ | Startverknüpfungen und App-Registrierungen; zeigt auch Apps ohne „richtige“ Installation, kann aber Programme ohne Startmenü-Eintrag übersehen |
| App-Ordner / Installationsordner | Physische Dateien; zeigt auch portable Software, ist aber ohne Registrierung/Deinstallationsinfos schwer eindeutig zuzuordnen |
Das Startmenü (Bereich Alle Apps) zeigt in erster Linie, was startbar ist: Verknüpfungen, App-Registrierungen und teilweise auch Webseiten-Apps. Dort kann Software auftauchen, die nicht „klassisch installiert“ ist, etwa portable Programme, die lediglich eine Verknüpfung erhalten haben, oder Apps, die als Web-App eingebunden wurden. Umgekehrt können installierte Programme fehlen, wenn der Installer keinen Startmenü-Eintrag erzeugt hat oder wenn ein Eintrag entfernt wurde.
Für die Einordnung hilft ein Blick auf den Kontext: Ein Startmenü-Eintrag kann auf eine ausführbare Datei in C:\Program Files verweisen, auf eine App-ID einer Store-App oder auf einen Helferprozess. Daraus folgt: Das Startmenü eignet sich gut, um „Wie starte ich es?“ zu klären, aber nur eingeschränkt, um „Ist es installiert und wie wird es deinstalliert?“ zuverlässig zu beantworten.
App-Ordner und Installationspfade: Dateien sind vorhanden, aber die Zuordnung ist heikel
Ein Abgleich über Ordner zeigt, ob Programmdateien existieren. Klassische Installationen liegen häufig unter C:\Program Files oder C:\Program Files (x86), benutzerspezifische Installationen oft unter %LOCALAPPDATA%\Programs. Store-Apps werden hingegen typischerweise in einem geschützten Bereich verwaltet (z. B. C:\Program Files\WindowsApps), der ohne passende Rechte nicht ohne Weiteres einsehbar ist. Das Vorhandensein von Dateien bedeutet jedoch nicht automatisch, dass Windows sie als „installiert“ führt oder sauber deinstallieren kann.
Gerade bei portabler Software oder bei „entpackten“ Anwendungen entsteht die häufige Fehlinterpretation: Das Programm läuft, aber keine Programmliste zeigt es an. In solchen Fällen existiert oft kein registrierter Uninstaller. Umgekehrt können nach einer fehlerhaften Deinstallation Einträge in Listen stehen bleiben, obwohl der Ordner bereits gelöscht wurde.
- Einstellungen-Ansicht prüfen: Öffnen über
ms-settings:appsfeatures(Start → Ausführen) und nach Name, Herausgeber oder Installationsdatum filtern. - Systemsteuerung gezielt öffnen: Aufruf über
appwiz.cpl; dort erscheinen typischerweise nur Programme mit registrierter Deinstallationsroutine. - Startmenü richtig interpretieren: „Alle Apps“ zeigt Startpunkte, nicht zwingend Installationsstatus; fehlende Einträge bedeuten nicht automatisch „nicht installiert“.
- Typische Installationsorte abgleichen:
C:\Program Files,C:\Program Files (x86),%LOCALAPPDATA%\Programs; Store-Apps liegen häufig unterC:\Program Files\WindowsAppsund sind dort geschützt. - Windows-Komponenten separat betrachten: Systemfunktionen finden sich unter
optionalfeatures.exebeziehungsweiseWindows-Features aktivieren oder deaktivierenund tauchen nicht wie normale Apps auf.
Typische Stolpersteine: Doppelte Einträge, fehlende Programme, „komische“ Namen
Doppelte Einträge sind häufig technisch plausibel: Ein Hauptprogramm kann eine separate Runtime, ein Treiberpaket oder ein Update-Modul mitbringen, das als eigener Eintrag verwaltet wird. „Fehlende“ Programme sind oft portable Anwendungen, Apps ohne registrierten Uninstaller oder Software, die nur für ein Benutzerkonto installiert wurde. Abweichende Namen entstehen, weil Listen unterschiedliche Metadatenquellen nutzen: Produktname aus dem Installer, Anzeigename aus einem App-Paket oder Eintragstitel aus einer Verknüpfung.
Für eine saubere Zuordnung hilft ein konsistentes Vorgehen: Zuerst in Installierte Apps nachsehen, danach in Programme und Features gegenprüfen, anschließend Startmenü und Installationspfade als Indizien heranziehen. So werden die jeweiligen Grenzen der Listen sichtbar, ohne aus einem einzelnen fehlenden Eintrag vorschnell auf „nicht installiert“ oder „defekt“ zu schließen.
Wenn Einträge fehlen oder doppelt sind: typische Ursachen, Überprüfung per Registry, Paketverwaltung und Uninstallern
Dass Programmlisten in Windows Einträge vermissen lassen oder doppelt anzeigen, hat meist technische, nachvollziehbare Gründe. „Installiert“ ist kein einheitlicher Zustand, sondern wird je nach Installationsart an unterschiedlichen Stellen dokumentiert: klassische MSI/Setup-Installationen schreiben Uninstall-Informationen in die Registry, Store-Apps werden als AppX/MSIX-Pakete verwaltet, portable Tools hinterlassen oft gar keine Spuren, und Hersteller-Tools nutzen mitunter eigene Updater und Komponentenpakete. Werden diese Quellen gemischt dargestellt, entstehen Lücken oder Doppelungen.
Typische Ursachen für fehlende Einträge
Fehlende Programmeinträge bedeuten häufig nicht, dass eine Anwendung „nicht installiert“ ist, sondern dass sie nicht in der jeweiligen Datenquelle geführt wird. Portable Programme (nur entpackt oder in einen Ordner kopiert) erscheinen typischerweise weder in „Apps“ noch in klassischen Deinstallationslisten, weil keine Uninstall-Registrierung existiert. Auch Anwendungen, die pro Benutzer installiert werden, können in einer systemweiten Ansicht fehlen, wenn diese nur die maschinenweiten Uninstall-Einträge ausliest.
Weitere Ursachen sind defekte oder unvollständige Uninstall-Registrierung (z. B. nach einem abgebrochenen Setup), Bereinigungen durch „Cleaner“, oder Installationen über spezielle Paketformate. Bei Microsoft Store/Windows-App-Paketen hängt die Sichtbarkeit zudem davon ab, ob die Option „Systemkomponenten“ einbezogen wird. Systemnahe Komponenten (Runtimes, Treiberpakete, Sprachfeatures) werden je nach Oberfläche ausgeblendet oder unter anderen Kategorien geführt.
Warum Einträge doppelt erscheinen
Doppelte Einträge entstehen häufig durch parallele 32‑Bit- und 64‑Bit-Registrierungen, getrennte Einträge für „Hauptprogramm“ und „Updater/Helper“, oder durch mehrere Installationskontexte (pro Benutzer und pro Gerät). Auch Suite-Installationen schreiben oft mehrere Uninstall-Schlüssel: einmal für die Suite, zusätzlich für einzelne Module. In einigen Oberflächen werden Einträge aus Registry und Paketverwaltung zusammengeführt, ohne sauber zu deduplizieren; dann taucht dieselbe Anwendung unter leicht abweichendem Namen, Publisher oder Version zweimal auf.
| Symptom in der Liste | Häufige technische Ursache |
|---|---|
| Programm fehlt in „Apps“ | Portable Nutzung; defekter Uninstall-Eintrag; Installation nur für einen Benutzer; Installation per winget/choco ohne klassischen Uninstaller-Eintrag (je nach Paket/Installer) |
| Programm erscheint zweimal | Eintrag unter HKLM und HKCU; 32‑Bit/64‑Bit-Uninstall-Zweige; Suite + Komponenten; zusätzliches „Update“-Produkt |
| Nur „Microsoft Visual C++ Redistributable“ etc. sichtbar | Runtimes/Frameworks registrieren sich korrekt, werden aber in manchen Ansichten nicht als „App“ priorisiert |
| Store-App fehlt in klassischer Systemsteuerung | AppX/MSIX wird nicht über Uninstall-Registry verwaltet, sondern über die Paketverwaltung |
Überprüfung per Registry: der „klassische“ Installationsnachweis
Für klassische Installer (MSI und viele EXE-Setups) ist die Registry die maßgebliche Quelle für das, was viele Tools als „installiert“ melden. Entscheidend sind Uninstall-Schlüssel, die u. a. Anzeigenamen, Version und Deinstallationsbefehl enthalten. 64‑Bit- und 32‑Bit-Software werden dabei in getrennten Zweigen geführt, was sowohl Lücken als auch Doppelungen erklärt.
- Systemweite 64‑Bit-Einträge:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall - Systemweite 32‑Bit-Einträge auf 64‑Bit-Windows:
HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall - Benutzerspezifische Einträge:
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall - Relevante Werte zur Plausibilisierung:
DisplayName,DisplayVersion,Publisher,InstallLocation,UninstallString,QuietUninstallString
Einträge ohne DisplayName oder mit kryptischen GUID-Namen sind nicht automatisch „Fehler“; sie können interne Installer-Produkte repräsentieren. Gleichzeitig gilt: Fehlt ein Uninstall-Schlüssel vollständig, kann die Anwendung trotzdem vorhanden sein (z. B. portable Nutzung, Copy-Deployment, oder ein Installer, der nicht standardkonform registriert).
Abgleich über Paketverwaltung: winget, Store und AppX/MSIX
Bei moderner Paketverwaltung und Store-Apps sind andere Bestandsdaten maßgeblich. Windows Package Manager (winget) führt eine eigene Liste „erkannter“ installierter Pakete, die aus mehreren Quellen stammen kann (z. B. ARP/Registry, MSIX, Store-Zuordnung). Das erklärt, warum winget mitunter mehr oder weniger findet als „Apps“ oder die Systemsteuerung.
- Installierte Pakete über winget anzeigen:
winget list - Konkretes Paket eingrenzen (Name/Id):
winget list --name "Beispiel"winget list --id "Publisher.App" - Provisionierte (vorinstallierte) AppX-Pakete, die für neue Benutzer bereitstehen:
Get-AppxProvisionedPackage -Online | Select-Object DisplayName, PackageName - Installierte AppX-Pakete pro Benutzer (PowerShell):
Get-AppxPackage | Select-Object Name, PackageFullName
Der Unterschied zwischen provisionierten und tatsächlich installierten AppX-Paketen ist für „fehlende“ Apps zentral: Ein provisioniertes Paket ist eine Vorlage, die erst beim Anlegen eines Benutzerprofils installiert wird. Umgekehrt können Apps für einen Benutzer entfernt sein, aber weiterhin provisioniert bleiben und bei neuen Profilen wieder auftauchen.
Zusätzliche Quellen: Installer-Datenbanken und Uninstaller-Tools
Wenn Registry und Paketverwaltung nicht schlüssig sind, helfen Abgleiche mit Installer-Datenbanken und professionell arbeitenden Uninstaller-Werkzeugen. MSI-basierte Installationen lassen sich über die Windows-Installer-Produktdatenbank identifizieren, wobei die Anzeige je nach Abfrageweg eingeschränkt sein kann. Uninstaller-Tools lesen meist mehrere Quellen (Uninstall-Registry, AppX/MSIX, Dienste/Autostarts, Restdateien) und können dadurch „mehr“ finden; diese Mehrmenge besteht häufig aus Komponenten, die Oberflächen bewusst ausblenden.
- MSI-Produkte über PowerShell prüfen (ohne Win32_Product):
Get-Package -ProviderName msi | Select-Object Name, Version - Installationspakete im Installer-Cache plausibilisieren (nicht löschen):
C:\Windows\Installer - Deinstallationsbefehle aus Registry testen (vorsichtig, nicht blind ausführen):
UninstallStringbzw.QuietUninstallString - Konflikte erkennen: Ein Programm taucht in
winget listauf, aber ohne passenden Schlüssel unter...\Uninstall– Hinweis auf nicht klassisch registrierte Installation (z. B. MSIX) oder auf eine unvollständige Registrierung.
Für die Beurteilung „fehlt“ versus „doppelt“ zählt letztlich, welche Installationsart vorliegt und welche Quelle eine Liste auswertet. Ein sauberer Abgleich erfolgt über die Uninstall-Registry (klassisch), die AppX/MSIX-Paketlisten (Store/modern) und – falls nötig – die Paketverwaltung. Erst wenn diese Quellen widersprüchlich bleiben, spricht das für beschädigte Registrierungen, Reste früherer Versionen oder Installationsfehler, die eine Reparaturinstallation oder eine kontrollierte Neuinstallation erforderlich machen können.
Meroth IT-Service ist Ihr lokaler IT-Dienstleister in Frankfurt am Main für kleine Unternehmen, Selbstständige und Privatkunden
Kostenfreie Ersteinschätzung Ihres Anliegens?
Werbung
(**) UVP: Unverbindliche Preisempfehlung
Preise inkl. MwSt., zzgl. Versandkosten
