Dateizuordnungen in Windows 11 reparieren: Warum sie sich ändern und wie ich sie dauerhaft korrigiere

Wie Windows 11 Dateizuordnungen verwaltet: Benutzerprofil, Systemregistrierung und registrierte Apps

Dateizuordnungen in Windows 11 entstehen nicht an einer einzelnen Stelle, sondern aus mehreren Informationsquellen, die in einer festen Reihenfolge ausgewertet werden. Entscheidend ist die Trennung zwischen benutzerspezifischen Entscheidungen (welche App öffnet bei diesem Konto eine bestimmte Endung) und systemweiten Registrierungen (welche Programme können welche Typen, Protokolle oder Shell-Operationen verarbeiten). Hinzu kommt, dass „Standard-Apps“ nicht nur klassische .ext-Zuordnungen betreffen, sondern auch URI-Protokolle (z. B. mailto:) und Shell-Verben wie open, edit oder print.

Praktisch bedeutet das: Eine scheinbar „falsche“ Zuordnung ist häufig das Ergebnis korrekter, aber konkurrierender Einträge – etwa wenn ein Programm seine Fähigkeiten breit registriert, während die tatsächliche Standardwahl je Benutzer in einem anderen Bereich festgeschrieben ist. Die Diagnose wird dadurch anspruchsvoller, dass Windows 11 Standards bewusst vor stillen Überschreibungen schützt und bestimmte Änderungen nur über die Einstellungen oder über dokumentierte Schnittstellen akzeptiert.

Benutzerprofil: per-User-Zuordnungen und die Explorer-Sicht

Die konkrete Standardentscheidung eines Benutzers wird überwiegend im Profil gespeichert. Zentral ist der Zweig HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts. Für jede Erweiterung existiert dort typischerweise ein Unterschlüssel, der Unterstrukturen wie OpenWithList, OpenWithProgids und – für die wirksame Standardwahl – UserChoice enthalten kann. Der UserChoice-Unterschlüssel enthält den ausgewählten ProgId und weitere Metadaten; Windows prüft diese Daten auf Integrität, weshalb direkte manuelle Manipulation in der Registry in der Regel nicht als stabiler Weg gilt.

Wichtig ist die begriffliche Trennung: Eine Dateiendung wird nicht direkt einer EXE zugeordnet, sondern einem ProgId. Dieser ProgId verweist dann auf Befehlszeilen, Symbole, Beschreibungen und Shell-Verben. Der Explorer bildet daraus Kontextmenü-Einträge („Öffnen“, „Bearbeiten“), „Öffnen mit…“-Vorschläge und die tatsächlich verwendete Standardaktion. Dadurch kann ein System mehrere geeignete Apps anbieten, obwohl am Ende nur eine als Standard gesetzt ist.

Systemregistrierung: Klassen, ProgIDs und Shell-Verben

Die systemweite Basis liegt unter HKEY_LOCAL_MACHINE\Software\Classes und wird als zusammengeführte Sicht auch über HKEY_CLASSES_ROOT (HKCR) bereitgestellt. HKCR ist keine „eigene“ Datenbank, sondern eine Zusammenführung aus benutzerspezifischen Klassen (HKEY_CURRENT_USER\Software\Classes) und den systemweiten Klassen unter HKLM. Damit können pro Benutzer zusätzliche Klassen registriert oder systemweite Einträge überlagert werden, ohne dass die Installation selbst global geändert werden muss.

Für die Zuordnung ist meist ein zweistufiges Modell relevant: Unter HKCR\.ext steht, welcher ProgId grundsätzlich zu dieser Endung gehört (Default-Wert). Der ProgId-Schlüssel selbst (z. B. HKCR\AcroExch.Document.DC) definiert dann unter shell\open\command den Startbefehl. Weitere Verben wie print oder edit sind optional und beeinflussen Kontextmenüs sowie Automatisierungen. Für Ordner, Laufwerke und „Directory“-Objekte gelten eigene Klassen wie Folder, Directory oder Drive; unerwünschte Bindungen in diesen Klassen können dazu führen, dass Ordner beim Öffnen an ein Programm „durchgereicht“ werden, statt im Explorer zu erscheinen.

Registrierte Apps: Capabilities, ProgIDs und die Standard-App-Auswahl

Damit eine Anwendung in „Standard-Apps“ sinnvoll auswählbar ist, registriert sie üblicherweise Capabilities. Windows liest diese Angaben aus Einträgen wie HKLM\Software\RegisteredApplications, die auf Capability-Pfade verweisen. Dort werden unterstützte Dateitypen, Protokolle und teils MIME-Typen aufgelistet und jeweils mit ProgId-Namen verknüpft. Diese Architektur trennt „App kann X“ (Capabilities) von „Benutzer wählt X als Standard“ (UserChoice). Updates von Apps ändern häufig die Capabilities oder die zugehörigen ProgId-Definitionen, ohne dass damit automatisch die Standardwahl des Benutzers geändert werden darf.

Bei Microsoft Store-Apps (UWP/Windows App SDK) kommen zusätzlich Paket- und AppModel-Registrierungen hinzu, die ebenfalls in die Erkennung geeigneter Handler einfließen. Die Standardwahl endet dennoch bei einem ProgId, der für die jeweilige App registriert ist. Das erklärt, warum nach einer Deinstallation „tote“ Zuordnungen entstehen können: Der ProgId bleibt als Benutzerentscheidung erhalten, obwohl die dazugehörige Anwendung oder der Befehl nicht mehr existiert.

Priorität und typische Kollisionspunkte

Windows 11 löst Zuordnungen entlang einer Prioritätskette auf: Zuerst zählt die benutzerspezifische Standardwahl, dann folgen Klassenüberlagerungen im Benutzerzweig, anschließend die systemweiten Klassen. Kollisionspunkte entstehen, wenn mehrere Apps denselben Typ registrieren, wenn ein Update einen ProgId ersetzt, oder wenn Shell-Klassen (etwa Folder) durch Fremdsoftware erweitert werden. Besonders sichtbar wird das bei Kontextmenü-Erweiterungen und bei „Öffnen“-Verben, weil diese nicht nur Endungen betreffen, sondern Objektklassen wie Ordner, Laufwerke oder Verknüpfungen.

• Wirksame Standardwahl je Endung: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.ext\UserChoice (liefert den ProgId, der im Explorer als Standard genutzt wird)
• Systemweite Zuordnung Endung → ProgId: HKCR\.ext beziehungsweise HKLM\Software\Classes\.ext (Default-Wert zeigt auf einen ProgId, oft ergänzt durch PerceivedType oder Content Type)
• ProgId-Definition und Startbefehl: HKCR\<ProgId>\shell\open\command (konkrete Befehlszeile; zusätzliche Verben unter shell können Verhalten und Menüs beeinflussen)
• Ordner- und Laufwerksverhalten: HKCR\Folder, HKCR\Directory, HKCR\Drive (fremde shell\open\command-Einträge oder Shell-Erweiterungen können dazu führen, dass Ordner nicht im Explorer öffnen)
• App-Fähigkeiten (Auswahlliste in Einstellungen): HKLM\Software\RegisteredApplications sowie verknüpfte Capability-Schlüssel (steuert, welche Apps als Handler angeboten werden, nicht die finale Benutzerauswahl)

Für eine saubere Analyse ist die Unterscheidung zwischen „App ist registriert“ und „App ist Standard“ zentral. Registrierungen erklären, warum eine Anwendung als Option auftaucht; die Standardentscheidung erklärt, warum sie tatsächlich startet. Wird diese Trennung konsequent eingehalten, lassen sich Fehlerbilder wie „falsches Programm öffnet alles“, „Ordner öffnen in einer App“ oder „Zuordnung zeigt auf deinstallierte Software“ präzise einem Speicherort und damit einer Korrekturebene zuordnen.

Fehlerbilder und Ursachen: App-Installationen, Updates, Default-Reset, Richtlinien und beschädigte Zuordnungen

Fehlerhafte Dateizuordnungen unter Windows 11 wirken auf den ersten Blick banal, entstehen aber häufig aus einer Mischung aus Installer-Logik, Systemschutzmechanismen und Richtlinien. Typisch sind plötzliche Änderungen der Standard-App für vertraute Dateitypen, widersprüchliche Dialoge beim Öffnen sowie Zuordnungen, die sich scheinbar „nicht merken“. Besonders irritierend sind Fälle, in denen nicht nur Dateiendungen, sondern auch Protokolle oder Shell-Verben betroffen sind und damit ganze Arbeitsabläufe kippen.

Typische Fehlerbilder in der Praxis

Ein häufiges Muster ist die Entkopplung zwischen Anzeige und Verhalten: In den Einstellungen steht eine App als Standard, beim Doppelklick öffnet jedoch eine andere. Ursache ist oft, dass verschiedene Ebenen greifen (per-user vs. systemweit) oder dass mehrere Handler um denselben Typ konkurrieren. Ebenso verbreitet sind „Schleifen“ mit der Auswahl-App: Nach dem Setzen eines Standards erscheint beim nächsten Öffnen erneut der Dialog, weil die Zuordnung nicht korrekt in den erlaubten Hash-basierten Strukturen landet oder unmittelbar wieder überschrieben wird.

Daneben existieren Sonderfälle, die weniger nach Dateizuordnung aussehen, aber technisch dazugehören. Dazu zählen beschädigte Shell-Verben (etwa open oder edit), fehlerhafte Kontextmenü-Einträge oder das Öffnen von Ordnern/Verzeichnissen in einer unerwünschten Anwendung. Gerade bei Ordnern und Laufwerken liegt das Problem oft nicht in einer „Dateiendung“, sondern in der Behandlung von Shell-Klassen wie Folder oder Directory und deren Befehlszeilen.

• Standard-App springt zurück: Nach dem Setzen über „Standard-Apps“ oder „Öffnen mit“ steht die gewünschte App kurzzeitig, später greift wieder eine andere Registrierung, oft ausgelöst durch Update/Repair der konkurrierenden App.
• „Diese App kann nicht geöffnet werden“ / falscher Handler: Ein veralteter Registrierungseintrag zeigt auf eine nicht mehr vorhandene .exe oder ein AppX-Paket, sodass der Shell-Start ins Leere läuft.
• Ordner öffnen in Programm statt Explorer: Manipulierte Verben für Directory/Folder oder ein ersetzter Explorer-Aufruf führen dazu, dass Doppelklicks Programme starten oder Fehlerdialoge erzeugen.
• „Immer diese App verwenden“ ohne Wirkung: Der UI-Dialog setzt nicht die tatsächlich wirksame Zuordnung (z. B. Konflikt zwischen HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts und registrierten ProgIDs), oder eine Richtlinie blockiert Persistenz.

Einfluss von App-Installationen und Reparaturfunktionen

Installationsroutinen registrieren Dateitypen, Protokolle und ProgIDs, häufig mit dem Ziel, die eigene App als bevorzugten Handler zu platzieren. Klassische MSI/EXE-Installer schreiben dazu typischerweise in HKLM\Software\Classes (maschinenweit) oder HKCU\Software\Classes (benutzerspezifisch). Store-Apps (UWP/Windows-Apps) registrieren Handler paketbasiert; Windows berücksichtigt dann deklarierte Capabilities und AppX-Registrierungen bei der Auswahlliste, während die wirksame Standardwahl weiterhin pro Benutzer über UserChoice festgelegt wird.

Zusätzliche Dynamik entsteht durch „Repair“ und „Self-Healing“: Viele Anwendungen prüfen beim Start, ob ihre ProgIDs und Verknüpfungen vorhanden sind, und stellen sie bei Abweichungen wieder her. Dadurch kann eine Zuordnung nach einem manuell gesetzten Standard scheinbar „grundlos“ zurückkehren. Auch Deinstallationen sind ein Risikofaktor: Entfernt ein Uninstaller ProgIDs oder Klassen unsauber, bleiben Verweise zurück, die auf nicht mehr vorhandene Komponenten zeigen. Windows fällt dann entweder auf einen anderen registrierten Handler zurück oder fordert erneut zur Auswahl auf.

Windows-Updates, „Default-Reset“ und Schutzmechanismen

Windows 11 schützt Standardzuordnungen stärker als frühere Versionen. Bestimmte Zuordnungen werden nicht als einfache Registry-Werte betrachtet, sondern als vom Benutzer bestätigte Auswahl, die über eine Hash-Logik abgesichert ist. Das erschwert „stille“ Änderungen durch Drittsoftware, führt aber auch zu Fehlerbildern, wenn Registrierungen uneinheitlich sind: Dann kann Windows eine Zuordnung verwerfen und auf eine Standard-App zurückfallen oder erneut die Auswahl verlangen.

Nach Funktionsupdates oder größeren kumulativen Updates treten Default-Resets bevorzugt dann auf, wenn ein Handler nicht mehr gültig ist (App entfernt, Paketname geändert, Pfad ungültig) oder wenn mehrere Apps denselben Typ mit widersprüchlichen Angaben registrieren. Auch Änderungen an Systemkomponenten (z. B. Browser-/WebView-Komponenten) können Protokoll-Handler beeinflussen, ohne dass eine klassische „Dateiendung“ beteiligt ist. In verwalteten Umgebungen kann dies mit Richtlinien kollidieren: Ein per Policy gesetzter Standard und eine per Benutzer gesetzte Abweichung werden nicht immer gleich behandelt, was wie ein Reset wirkt, obwohl die Policy lediglich wieder durchsetzt.

• Ungültige Ziel-App: Der registrierte Handler verweist auf eine entfernte App oder ein nicht mehr vorhandenes Paket; Windows verwirft den Eintrag und nutzt einen Fallback aus den verbleibenden Registrierungen.
• Konflikt mehrerer ProgIDs: Mehrere Anwendungen beanspruchen denselben Typ, aber mit unterschiedlichen Verben oder Capabilities; Windows entscheidet neu, insbesondere nach Re-Registrierung durch Updates.
• Hash/Integritätslogik greift: Versuche, Standard-Apps „direkt“ zu setzen (z. B. durch unpassende Registry-Edits), werden nicht als bestätigte Auswahl akzeptiert; Windows zeigt erneut den Dialog oder setzt zurück.

Richtlinien, MDM und Domänenfaktoren

In Unternehmen entstehen unerwünschte Zuordnungen häufig nicht durch Installationen, sondern durch zentrale Vorgaben. Gruppenrichtlinien und MDM-Konfigurationen können Standardzuordnungen initial verteilen oder dauerhaft erzwingen. Ein verbreitetes Missverständnis: Manche Verfahren setzen Default Associations nur beim ersten Anmelden eines Profils, andere werden bei bestimmten Ereignissen (z. B. Neuanlage des Profils, In-Place-Upgrade, Neuapplikation von Richtlinien) erneut angewendet. Daraus ergeben sich zwei typische Bilder: Entweder „nichts lässt sich ändern“ (Erzwingung) oder „es springt nach einiger Zeit zurück“ (erneute Durchsetzung der Vorgabe).

Auch sicherheitsbezogene Baselines spielen hinein. AppLocker/Windows Defender Application Control oder restriktive Software-Restriktionen können den Start des gewünschten Handlers verhindern, sodass Windows beim Öffnen auf einen anderen registrierten Handler ausweicht oder den Start blockiert. Das wirkt wie eine fehlerhafte Zuordnung, ist aber faktisch eine Ausführungs- oder Paketzulassungsfrage. Zusätzlich beeinflussen Roaming-Profile und Umleitungen den Zeitpunkt, zu dem pro Benutzer gespeicherte Zuordnungen geladen werden; kurzfristige Inkonsistenzen nach der Anmeldung sind dann möglich.

Beschädigte Zuordnungen und inkonsistente Registry-Strukturen

Beschädigungen entstehen häufig durch „Tuning“-Tools, aggressive Cleaner oder manuelle Eingriffe, die nur einen Teil der Kette ändern. Eine funktionierende Zuordnung besteht in der Regel aus: einer Endung, die auf eine ProgID zeigt, einer ProgID mit korrekten Shell-Verben, einem gültigen Befehl (inklusive korrekter Quoting-Regeln) und ggf. ergänzenden Capabilities. Sobald ein Glied fehlt oder auf eine falsche Klasse zeigt, werden Nebenwirkungen sichtbar: Kontextmenüs verschwinden, „Öffnen“ startet die falsche Komponente oder Parameter werden falsch übergeben.

Besonders empfindlich sind die Shell-Klassen für Ordner und Laufwerke. Wenn etwa HKCR\Directory\shell\open\command oder HKCR\Folder\shell\open\command auf eine Fremdanwendung umgebogen wurde, betrifft das nicht nur den Explorer-Doppelklick, sondern auch interne Aufrufe aus Dialogen (Dateiöffnen, „Speichern unter“) und manche Skripte. In solchen Fällen wirkt die Störung „systemweit“, obwohl sie technisch über die gemeinsame Klassenauflösung von HKCR (Zusammenführung von HKLM\Software\Classes und HKCU\Software\Classes) zustande kommt.

• Typische Bruchstellen: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.EXT\UserChoice, HKCU\Software\Classes\.EXT, HKLM\Software\Classes\.EXT, HKCR\ProgID\shell\open\command, HKCR\Directory\shell\open\command.
• Fehler durch falsches Quoting: Ein Command wie "C:\Program Files\App\app.exe" "%1" funktioniert, während fehlende Anführungszeichen oder vertauschte Platzhalter dazu führen können, dass Pfade mit Leerzeichen abbrechen oder Parameter als Teil des Pfads interpretiert werden.
• Überlagerung durch Benutzerklassen: Ein scheinbar „systemweiter“ Fix in HKLM\Software\Classes greift nicht, wenn HKCU\Software\Classes dieselbe ProgID oder Endung abweichend definiert und damit in HKCR priorisiert.

Analyse und nachhaltige Korrektur: GUI, Registry, DISM/Export-Import, Gruppenrichtlinien und Schutz vor Überschreiben

Erste Diagnose in der GUI: Wo Windows 11 tatsächlich entscheidet

Für eine belastbare Analyse muss zwischen Zuordnungen für Dateitypen (z. B. .pdf), Protokollen (z. B. mailto:) und Shell-Verben (z. B. „Öffnen“, „Bearbeiten“) unterschieden werden. Die Windows-11-Oberfläche unter „Standard-Apps“ zeigt primär per Benutzer gesetzte Zuordnungen. Sie spiegelt jedoch nicht zwangsläufig alle wirksamen Mechanismen wider, etwa wenn ein Programm zusätzliche Kontextmenüeinträge registriert oder wenn eine Richtlinie Standardwerte erzwingt.

Bei typischen Fehlerbildern – etwa wenn ein Ordner scheinbar „an ein Programm gebunden“ ist oder beim Doppelklick ein unerwartetes Tool startet – liegt die Ursache häufig nicht bei einer Dateiendung, sondern bei Shell-Registrierungen: dem Folder– oder Directory-Handler, dem Standardverb unter shell oder einem überschriebenen DelegateExecute. Die GUI kann solche Zustände höchstens indirekt sichtbar machen, weshalb eine Validierung in der Registry und mit Systemwerkzeugen erforderlich bleibt.

Registry-Prüfung: UserChoice, ProgIDs und Shell-Verben sauber abgrenzen

Für Dateiendungen nutzt Windows 11 eine mehrstufige Auflösung. Auf Systemebene liegen Klassen- und ProgID-Registrierungen typischerweise unter HKLM\Software\Classes (zusammengeführt als HKCR). Auf Benutzerebene steuert Windows die tatsächliche Auswahl über UserChoice pro Endung und Protokoll. Dort ist ein Hash hinterlegt, der manuelle Änderungen erschwert; direkte Registry-Edits an UserChoice gelten deshalb als unzuverlässig und führen häufig zu Rückfällen oder ignorierten Werten.

Bei „Ordner-Fehlzuordnungen“ ist die Endungsebene irrelevant. Entscheidend ist, welches Standardverb unter HKCR\Folder\shell beziehungsweise HKCR\Directory\shell aktiv ist und ob ein command-Unterschlüssel oder ein DelegateExecute-Eintrag die Ausführung umbiegt. Seriöse Korrekturen setzen hier an der Shell-Klasse an und stellen das erwartete Verb (open) sowie die Standardwerte wieder her, statt einzelne Apps zu deinstallieren.

• UserChoice für Dateiendungen: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.EXT\UserChoice (Werte wie ProgId, Hash; Änderungen per Editor sind in der Praxis meist wirkungslos oder werden zurückgesetzt)
• UserChoice für Protokolle: HKCU\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\PROTOKOLL\UserChoice (z. B. http, mailto)
• Systemweite Klassen/ProgIDs: HKLM\Software\Classes (erscheint zusammengeführt unter HKCR; hier registrieren Installer häufig ProgID, shell\open\command, Application)
• Ordner- und Verzeichnis-Handler: HKCR\Folder\shell und HKCR\Directory\shell (Prüfung auf abweichenden Standardwert, unerwartete Verben, verdächtige command-Ketten oder DelegateExecute)

Reparaturpfade: Zurücksetzen, Systemintegrität und kontrolliertes Neusetzen

Für die eigentliche Korrektur sind drei Ebenen zu trennen: Zurücksetzen der Benutzerwahl (damit falsche UserChoice-Bindungen verschwinden), Wiederherstellen systemnaher Shell-Registrierungen (falls Ordner/Verzeichnisse betroffen sind) und Absicherung, damit App-Updates die gewünschte Konstellation nicht erneut überlagern. In der GUI bleibt das Neusetzen einzelner Dateitypen über „Standard-Apps“ der robusteste Weg, weil Windows dabei konsistente Hashes und gültige ProgIDs schreibt.

Wenn systemweite Komponenten beschädigt sind oder Shell-Registrierungen auffällig instabil reagieren, ist eine Integritätsprüfung sinnvoll. DISM und SFC reparieren keine „falsche Präferenz“, aber sie können fehlerhafte Systemdateien und Komponentenstores korrigieren, die Shell-Handler oder AppX-Registrierungen beeinflussen. In Umgebungen mit Standardisierung ist der Export/Import von Default Associations ein sauberer Weg: Er definiert Standard-Apps pro Dateityp/Protokoll als Baseline (typisch für neue Profile; die Wirkung auf bestehende Profile hängt von der jeweiligen Richtlinien-/Deployment-Logik ab).

• Integrität prüfen und reparieren: DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
• Default-App-Zuordnungen exportieren (Referenzgerät): Dism /Online /Export-DefaultAppAssociations:C:\Temp\DefaultApps.xml
• Default-App-Zuordnungen importieren (Zielgerät/Abbild): Dism /Online /Import-DefaultAppAssociations:C:\Temp\DefaultApps.xml
• Per GUI gezielt neu setzen: Einstellungen > Apps > Standard-Apps (Dateiendung oder App auswählen; vermeidet ungültige UserChoice-Einträge)

Der DISM-Import setzt eine Baseline, ersetzt aber nicht automatisch jede bestehende Benutzerentscheidung in allen Szenarien. Deshalb ist die Kombination aus „sauberer Baseline“ (XML) und gezielten Ausnahmen (GUI pro Nutzer oder verwaltete App-Konfiguration) in der Praxis stabiler als ein rein systemweiter Eingriff an einzelnen Schlüsseln.

Gruppenrichtlinien und Schutz vor Überschreiben: kontrollierte Standards statt ständiger Reparaturen

In verwalteten Umgebungen liefern Gruppenrichtlinien den wirksamsten Schutz vor späteren Überschreibungen durch App-Installer, Feature-Updates oder „Default-App“-Prompts. Zentral ist die Richtlinie zur Vorgabe einer Standardzuordnungs-Konfigurationsdatei. Sie verweist auf eine XML, die mit DISM exportiert wurde und auf einem erreichbaren Pfad liegt. Entscheidend ist die Erwartungshaltung: Eine solche Vorgabe definiert Standards als Baseline; sie ist kein universeller „Lock“ für alle bestehenden Benutzerzuordnungen, kann aber die Ausgangslage nach Profilneuanlage oder definierten Rollout-/Upgrade-Ereignissen stabilisieren.

Für die Fehlersuche bei „Rückfällen“ empfiehlt sich eine Ereignis- und Änderungsanalyse statt Trial-and-Error: App-Reparaturen, In-Place-Upgrades und Browser-Updates registrieren ProgIDs neu; manche Anwendungen platzieren zusätzliche Verben und übernehmen Kontextmenü-Kommandos. Systemweite Registry-Änderungen sollten deshalb minimal-invasiv bleiben. Besonders riskant sind Änderungen unter HKCR\Folder und HKCR\Directory, weil sie Explorer-Grundfunktionen betreffen und Nebenwirkungen bis hin zu gebrochenen Kontextmenüs oder nicht mehr öffnenden Ordnern auslösen können.

• GPO für Standardzuordnungen: Computerkonfiguration\Administrative Vorlagen\Windows-Komponenten\Datei-Explorer\Eine Standardzuordnungskonfigurationsdatei festlegen (Pfad auf DefaultApps.xml auflösen, z. B. UNC)
• Erwartbare Überschreiber identifizieren: App-Updates/Installer, die ProgIDs neu registrieren unter HKLM\Software\Classes, sowie Browser-/PDF-Apps, die Protokolle (http, https) beanspruchen
• Systemweite Eingriffe absichern: Vor Änderungen Export betroffener Schlüssel, z. B. reg export HKCR\Folder C:\Temp\HKCR_Folder.reg
reg export HKCR\Directory C:\Temp\HKCR_Directory.reg
• Überschreibungen nachhalten: Prüfung, ob neue/unerwartete Verben unter HKCR\Folder\shell oder HKCR\Directory\shell auftauchen, und ob ein DelegateExecute gesetzt wurde