Windows-Shell-Integration heute — Kontextmenüs, Dateizuordnungen und Windows 11

„Nach dem Wechsel auf Windows 11 ist das Kontextmenü unserer App nicht mehr zu finden.“ Beim Nachsehen ist der Eintrag nicht verschwunden: Er erscheint, sobald man am Ende des Menüs „Weitere Optionen anzeigen“ öffnet. Das ist kein Defekt, sondern die von Windows 11 geänderte Menügestaltung. Vor Ort führt das zu Anfragen wie „ein Klick mehr“ oder „der Eintrag ist nicht zu finden“.

Allerdings sind „eine Datei mit dieser App öffnen“ und „einen eigenen Befehl im neuen Kontextmenü zeigen“ getrennte Aufgaben. Wer das nicht trennt und sofort eine Shell-Erweiterungs-DLL schreibt, macht auch Anforderungen kompliziert, die nur eine Zuordnungsregistrierung brauchen.

Dieser Artikel ist eine Einführung für IT-Verantwortliche in kleinen und mittleren Unternehmen und für Windows-Entwickler, die Geschäftsanwendungen betreuen. Er verbindet die Grundlage der Zuordnung, den Unterschied der alten und neuen Menüs, die Wahl der Implementierung, Registrierung und Entfernung im Installer sowie die Eingrenzung von Störungen.

1. Zuerst das Fazit

Die Grundlage von Zuordnung und Verb ist unverändert; unter Windows 11 hat sich nur die Darstellung des Menüs in alt und neu geteilt. Legen Sie zuerst fest, was Sie erreichen wollen, und wählen Sie nur den dafür nötigen Mechanismus.

Wenn es nur um „Öffnen“ geht, von Zuordnung und statischem Verb ausgehen

Die Grundlage der Dateizuordnung ist die dreistufige Registrierungsstruktur Erweiterungsschlüssel → ProgID → Verb. Der Erweiterungsschlüssel zeigt auf die ProgID, und shell\<verb>\command unter der ProgID hält die zu startende Befehlszeile. Wer nur „mit dieser App öffnen“ will, kommt weiterhin mit dieser Registrierung und einem statischen Verb aus; eine Shell-Erweiterungs-DLL ist unnötig. Microsoft rät ebenfalls, zuerst das einfachste statische Verb zu prüfen, das die Anforderung erfüllt.¹²

Das Ziel der Registrierung ist HKLM für alle Benutzer, HKCU je Benutzer. HKCR ist eine zusammengeführte Sicht der jeweiligen Classes, daher schreibt man ausdrücklich nach HKLM oder HKCU und behandelt HKCR als Prüfmittel.³

Zudem sind die Registrierung als Kandidat und die Wahl zur Standard-App getrennt. Die Standard-App für den Doppelklick wählt der Benutzer, und das OS schützt diese Wahl. Der Installer soll die Vorgabe nicht selbst übernehmen, sondern bis zur korrekten Kandidatenregistrierung gehen.⁴

Eigene Befehle im neuen Menü brauchen IExplorerCommand und Paketidentität

Unter Windows 11 weichen klassische IContextMenu-Erweiterungen ins alte Menü aus, das mit „Weitere Optionen anzeigen“ (Umschalt+F10) geöffnet wird. Um eigene Befehle im neuen Menü zu zeigen, braucht es eine IExplorerCommand-Implementierung und Paketidentität.⁵⁶

Der offizielle Weg ist, eine native DLL mit IExplorerCommand im MSIX-Manifest (desktop4:FileExplorerContextMenus) zu registrieren. Lässt sich die vorhandene App nicht vollständig auf MSIX umstellen, gibt ein Sparse-Paket (MSIX mit externem Speicherort) nur die Identität.⁶⁷

Sicherheit der DLL und Aufräumen bei der Deinstallation mitdenken

Eine klassische Shell-Erweiterung ist eine COM-DLL, die in den Prozess von Explorer und anderen geladen wird. Absturz oder Verzögerung der Erweiterung greifen auf den ganzen Host über. Ein 64-Bit-Host braucht eine 64-Bit-DLL; In-Process-Erweiterungen in verwaltetem Code werden nicht unterstützt.⁸⁹

Nach Registrierung, Änderung oder Löschung einer Zuordnung benachrichtigen Sie mit SHChangeNotify(SHCNE_ASSOCCHANGED). Bei der Deinstallation löschen Sie die eigene ProgID und Ähnliches und lassen den Standardwert des Erweiterungsschlüssels; das ist die offizielle Anleitung. Shell-Integration heißt nicht nur, das Menü zu zeigen, sondern Änderung sichtbar zu machen und aufzuräumen.¹¹⁰

Lesen nach Ziel

Wer den Mechanismus lernen will, liest ab Kapitel 2; wer die Linie für eine vorhandene App festlegen will, ab Kapitel 6.

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (16 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

2. Mechanik der Dateizuordnung — dreistufig: Erweiterungsschlüssel → ProgID → Verb

Dieses Kapitel ordnet Dateiregistrierung → Schreibziel → App-Registrierung → Benutzerwahl. Dass die Erweiterung auf die ProgID zeigt, das Verb die Befehlszeile hält und aufwendigere Erweiterungen als In-Process-COM-DLL laufen, ist seit über zwanzig Jahren die Grundlage.

2.1. Die drei Stufen an einem Beispiel lesen

Zuerst die Grundform der Zuordnung an einem Beispiel. Der Erweiterungsschlüssel zeigt auf die ProgID, das Verb darin hält den zu startenden Befehl.¹ Die Vorrangregel, wenn der Benutzer eine Standard-App gewählt hat, steht in 2.4.

HKEY_CLASSES_ROOT
   .kmrpt                                  ← (1) Erweiterungsschlüssel
      (Default) = KomuraSoft.Report.1      ←     nur Zeiger auf die ProgID
      OpenWithProgids
         KomuraSoft.Report.1               ←     Kandidat unter „Öffnen mit“
   KomuraSoft.Report.1                     ← (2) ProgID (Substanz der Zuordnung)
      (Default) = KomuraSoft-Bericht
      DefaultIcon
         (Default) = "C:\Program Files\KomuraSoft\Report.exe",0
      shell                                ← (3) Liste der Verben
         open
            command
               (Default) = "C:\Program Files\KomuraSoft\Report.exe" "%1"

• (1) Der Erweiterungsschlüssel (.kmrpt) zeigt im Standardwert nur auf den ProgID-Namen. Direkt hier einen Befehl zu schreiben ist falsch.
• (2) Die ProgID (KomuraSoft.Report.1) ist die Substanz der Zuordnung und hält Anzeigename, Symbol und Verb-Liste.
• (3) Das Verb ist die Handlung wie „Öffnen“ oder „Drucken“; der Standardwert von shell\open\command ist die tatsächlich gestartete Befehlszeile.

Diese Trennung erlaubt, mehrere Erweiterungen (.kmrpt und .kmrpt-file etwa) auf dieselbe ProgID zu zeigen oder bei einem Versionswechsel die ProgID auszutauschen.

flowchart TB
    accTitle: Dreistufige Struktur der Dateizuordnung
    accDescr: Der Erweiterungsschlüssel ist nur ein Zeiger, dessen Standardwert auf die ProgID zeigt; die ProgID hält Anzeigename, Symbol und Verb-Liste; der Standardwert von command unter dem Verb ist die tatsächlich gestartete Befehlszeile
    ext["Erweiterungsschlüssel .kmrpt"] -->|Standardwert zeigt auf die ProgID| pid["ProgID KomuraSoft.Report.1"]
    pid --> vb["Verb (open unter shell und so weiter)"]
    vb --> cmd["Standardwert von command"]
    cmd --> exe["Report.exe wird gestartet"]
    pid -.-> attr["Hält auch Anzeigename und DefaultIcon"]

Abbildung 1: Der Erweiterungsschlüssel ist der Zeiger, die ProgID die Substanz, command des Verbs die tatsächlich gestartete Befehlszeile.

2.2. HKCR ist eine zusammengeführte Sicht — wohin Sie schreiben, ändert die Bedeutung

Das Beispiel oben steht unter HKEY_CLASSES_ROOT (HKCR), aber HKCR ist kein physischer Speicherort, sondern eine zusammengeführte Sicht von HKLM\Software\Classes und HKCU\Software\Classes. Liegt derselbe Schlüssel in beiden, gewinnt HKCU.³

flowchart TB
    accTitle: HKCR ist eine zusammengeführte Sicht
    accDescr: HKCR überlagert die jeweiligen Classes von HKLM und HKCU; liegt derselbe Schlüssel in beiden, hat HKCU Vorrang; Registrierungen schreibt man ausdrücklich nach HKLM oder HKCU und behandelt HKCR als nur lesend
    hklm["HKLM\\Software\\Classes (alle Benutzer)"] --> hkcr["HKCR (zusammengeführte Sicht)"]
    hkcu["HKCU\\Software\\Classes (je Benutzer)"] --> hkcr
    hkcu -.-> win["Derselbe Schlüssel: HKCU gewinnt"]
    hkcr -.-> ro["Als nur lesend (zur Prüfung) behandeln"]

Abbildung 2: HKCR ist die überlagerte Sicht der Classes von HKLM und HKCU; das Schreibziel muss immer eines der beiden sein.

In der Praxis ist es sicher, Registrierungen ausdrücklich nach HKLM oder HKCU zu schreiben und HKCR als nur lesend (zur Prüfung) zu behandeln.

Zuordnungsdaten und die Bittigkeit der COM-Registrierung nicht vermengen

Bei der WOW64-Registrierungsumleitung unterscheiden sich Zuordnungsdaten und COM-Registrierung. Zuordnungsdaten direkt unter HKLM\Software\Classes wie Erweiterungsschlüssel und ProgID sind seit Windows 7 zwischen 32-Bit- und 64-Bit-Registrierungssicht geteilt; ein 32-Bit-Installer entweicht nicht nach Wow6432Node.

Dagegen sind einige Unterschlüssel der COM-Registrierung wie Classes\CLSID Umleitungsziele; bei der später behandelten Shell-Erweiterung (In-Process-COM) wirkt die getrennte 32-/64-Bit-Schreibweise. Details in „Fallstricke der 32-/64-Bit-Registrierungsumleitung und -virtualisierung“.

2.3. Registrierung auf der App-Seite — App Paths, Applications, RegisteredApplications

Zur Dateiseite (Erweiterung und ProgID) gehören drei Arten der App-Registrierung.¹¹

• App Paths (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths): Registrierung, damit der Start allein über den EXE-Namen mit ShellExecuteEx gelingt. Die PATH-Umgebungsvariable bleibt unberührt; Microsoft empfiehlt diesen Weg.
• Applications (HKCR\Applications\<App.exe>): Definiert die Standardöffnung, wenn unter „Öffnen mit“ eine beliebige Datei übergeben wird, und den Anzeigenamen der App (FriendlyAppName).
• RegisteredApplications + Capabilities: Erklärt, welche Erweiterungen und MIME-Typen die App behandelt, und lässt sie als Kandidat in den Windows-Einstellungen für Standard-Apps erscheinen.

Die meisten Anfragen „unsere App fehlt in der Liste der Standard-Apps“ kommen daher, dass die ProgID registriert ist, diese Capabilities-Registrierung aber fehlt.

flowchart TB
    accTitle: Drei Arten der Registrierung auf der App-Seite
    accDescr: Auf der App-Seite gibt es App Paths, Applications und RegisteredApplications; sie dienen dem Start allein über den Dateinamen, der Standardöffnung unter Öffnen mit und dem Erscheinen in den Einstellungen für Standard-Apps
    app["Registrierung auf der App-Seite"] --> ap["App Paths"]
    app --> apps["Applications"]
    app --> ra["RegisteredApplications"]
    ap --> r1["Start allein über den Dateinamen"]
    apps --> r2["Standard unter Öffnen mit"]
    ra --> r3["Erscheint unter Standard-Apps"]
    r3 -.-> cap["Bedingung: Erklärung in Capabilities"]

Abbildung 3: Die App-Seite hat drei Registrierungen; als Kandidat unter Standard-Apps braucht es die Capabilities-Registrierung.

2.4. Die Standard-App gehört dem Benutzer — Schutz von UserChoice

Einen ProgID-Namen in den Standardwert des Erweiterungsschlüssels zu schreiben macht noch nicht die Standard-App. Das Ergebnis einer ausdrücklichen Wahl unter „Öffnen mit“ und Ähnlichem liegt in HKCU\...\Explorer\FileExts\<Erweiterung>\UserChoice und hat bei der Auflösung der Zuordnung Vorrang.

UserChoice nicht direkt umschreiben

Windows unterstützt die programmgesteuerte Änderung der Standard-App nicht. Die Einstellung der Standard-App trifft der Benutzer über die Systemeinstellungen-UI; die UserChoice-Daten sind verschleiert, und der Filtertreiber (UCPD.sys) blockiert Schreibzugriffe von Apps. In verwalteten Umgebungen sind Gruppenrichtlinie und MDM die offiziellen Mittel.⁴

Dass Werkzeuge wie SetUserFTA den Hash nachahmten und umschrieben, ist die Kehrseite dieses Schutzes.

Der Installer bereitet vor, gewählt zu werden

In den Installer der eigenen App gehören diese drei Punkte.

1. ProgID und Verb korrekt registrieren.
2. Zu OpenWithProgIds hinzufügen.
3. Bei Bedarf den Benutzer zu den Einstellungen für Standard-Apps führen.

Die Vorgabe wird nicht übernommen; der Benutzer soll wählen können.

flowchart TB
    accTitle: Auflösung der Standard-App und Schutz von UserChoice
    accDescr: Das ausdrücklich gewählte Ergebnis des Benutzers liegt in UserChoice und hat bei der Auflösung der Zuordnung Vorrang; Umschreiben durch Apps blockiert UCPD.sys, daher bleibt dem Installer die Kandidatenregistrierung und die Führung zur Einstellungsseite
    uc["UserChoice (Wahl des Benutzers)"] -->|Vorrang| res["Auflösung der Zuordnung"]
    ext["Standardwert des Erweiterungsschlüssels"] --> res
    wr["Umschreiben durch die App"] -.->|UCPD.sys blockiert| uc
    res ~~~ inst["Aufgabe des Installers"]
    inst --> a1["Registrierung von ProgID und Verb"]
    inst --> a2["Hinzufügen zu OpenWithProgIds"]
    inst --> a3["Führung zur Einstellungsseite"]

Abbildung 4: Bei der Auflösung der Zuordnung hat die Benutzerwahl (UserChoice) Vorrang; Umschreiben durch Apps schützt das OS.

3. Verben außer „Öffnen“ — print, edit, runas, eigene Verben

3.1. Standardverben und eigene Verben

Es gibt nicht nur open. Standardverben, deren Bedeutung das OS kennt, sind neben open etwa edit, print, play, preview; Standardverben erhalten automatisch einen Anzeigenamen je nach OS-Gebietsschema. Das Standardverb beim Doppelklick ergibt sich in der Reihenfolge Standardwert des shell-Schlüssels → erstes Verb in der Registrierung → open → openwith.¹²

flowchart TB
    accTitle: Reihenfolge, in der das Standardverb feststeht
    accDescr: Das Standardverb beim Doppelklick ist das erste gefundene aus Standardwert des shell-Schlüssels, erstem Verb in der Registrierung, open, openwith
    s1["Standardwert des shell-Schlüssels"] -->|sonst| s2["Erstes Verb in der Registrierung"]
    s2 -->|sonst| s3["open"]
    s3 -->|sonst| s4["openwith"]

Abbildung 5: Beim Doppelklick gilt das erste in dieser Reihenfolge gefundene Standardverb.

Ein eigenes Verb registrieren Sie so.

KomuraSoft.Report.1
   shell
      open
         command
            (Default) = "C:\Program Files\KomuraSoft\Report.exe" "%1"
      print
         command
            (Default) = "C:\Program Files\KomuraSoft\Report.exe" /print "%1"
      verify                          ← eigenes Verb
         (Default) = Bericht prüfen(&V)   ← Anzeigename im Menü
         command
            (Default) = "C:\Program Files\KomuraSoft\Report.exe" /verify "%1"

3.2. Erhöhung, Anzeige bei Umschalt und altes DDE trennen

Verben kennen außerdem folgende Angaben.

• Ein Verb runas definiert den erhöhten Start entsprechend „Als Administrator ausführen“ und dient auch Starts über ShellExecute-APIs mit runas.
• Ein leerer Wert Extended am Verb-Schlüssel macht ein erweitertes Verb, das nur bei Rechtsklick mit gedrückter Umschalttaste erscheint. Nützlich, um selten genutzte, riskante Vorgänge zu verbergen.¹²
• In Zuordnungen alter Apps kann DDE (ddeexec) ein Dokument an einen vorhandenen Prozess senden; der Verb-Start über DDE ist bereits veraltet (Deprecated). Es gibt keinen Grund, ihn neu zu schreiben.¹²

3.3. EXE-Pfad und Pfad der gewählten Datei in Anführungszeichen setzen

Häufige Unfälle betreffen Anführungszeichen in der Befehlszeile. Enthält ein Element der Befehlszeichenfolge Leerzeichen, müssen Anführungszeichen her. Das gilt für EXE-Pfade wie C:\Program Files\... und %1 (Pfad der gewählten Datei) sollte immer "%1" sein. Dass der Dateipfad des Benutzers keine Leerzeichen enthält, ist nicht garantiert. Ein My Program.exe ohne Anführungszeichen wird als Start von My mit Argument Program.exe gelesen.¹³

flowchart TB
    accTitle: Unfall mit Anführungszeichen in der Befehlszeile
    accDescr: Ein Befehl ohne Anführungszeichen wird an Leerzeichen getrennt und fälschlich als Start von My mit Argument Program.exe gelesen; EXE-Pfad und %1 für den Pfad der gewählten Datei daher immer in Anführungszeichen
    c1["command ohne Anführungszeichen"] -->|Trennung am Leerzeichen| bad["Falsch als andere EXE gelesen"]
    c2["command mit Anführungszeichen"] --> good["Start wie vorgesehen"]
    c2 -.-> q1["EXE-Pfad in Anführungszeichen"]
    q1 -.-> q2["auch %1 immer in Anführungszeichen"]

Abbildung 6: Ein Befehl ohne Anführungszeichen wird am Leerzeichen falsch getrennt; EXE-Pfad und %1 daher immer in Anführungszeichen.

3.4. Vor dem Schreiben einer DLL prüfen, ob ein statisches Verb reicht

Die bisherige, nur aus der Registrierung bestehende Mechanik (statisches Verb) braucht keine DLL und gefährdet den Explorer nicht. Microsoft selbst wiederholt, vor dem Schreiben einer Shell-Erweiterung zu prüfen, ob das einfachste statische Verb die Anforderung erfüllt.²

4. Klassische Shell-Erweiterungen — DLLs, die im Explorer laufen

Was dieses Kapitel festhält: eine klassische Erweiterungs-DLL läuft im Prozess von Explorer und anderen. Wer den Ort versteht, verbindet Stabilität, Bittigkeit und Sprache.

4.1. Arten von Shell-Erweiterungen

Anforderungen, die ein statisches Verb nicht erfüllt — Menü dynamisch nach Auswahl, Austausch von Symbol oder Eigenschaftenseite — brauchen Shell-Erweiterungshandler. Typische Arten:⁸

Alle werden als COM-Klasse implementiert und mit CLSID in der Registrierung eingetragen. Die COM-Idee selbst erklärt „Was sind COM, ActiveX und OCX?“.

4.2. Was ein In-Process-COM-Server bedeutet

Das Wesen der klassischen Shell-Erweiterung ist ein In-Process-COM-Server (DLL), der in den Prozess des Explorers (und jeder App, die den gemeinsamen Dateidialog öffnet) geladen wird. Daraus folgen alle Vorbehalte.⁸

• Stürzt die Erweiterung ab, stürzt der Explorer mit ab. Hängt sie, friert der Rechtsklick Sekunden ein. Der Schaden bleibt nicht beim Explorer; er trifft jede App, die einen Dateidialog zeigt.
• Der Menüaufbau läuft auf dem UI-Thread; langsame Arbeit wie Netz- oder Datei-E/A darf beim Anzeigen des Menüs nicht laufen.
• Das Threading-Modell wird grundsätzlich als Apartment registriert.

flowchart TB
    accTitle: Mitgerissen-Struktur der In-Process-Erweiterung
    accDescr: Die Shell-Erweiterungs-DLL wird nicht nur in den Explorer, sondern in den Prozess jeder App geladen, die einen Dateidialog öffnet; Absturz oder Hängen der Erweiterung greifen daher auf den ganzen Hostprozess über
    dll["Shell-Erweiterungs-DLL"] -->|Laden in den Prozess| exp["Explorer"]
    dll -->|Laden in den Prozess| any["Beliebige App mit Dateidialog"]
    exp --> dmg["Absturz oder Hängen greifen über"]
    any --> dmg
    dmg -.-> rule["Keine langsame Arbeit beim Anzeigen"]

Abbildung 7: Die Erweiterungs-DLL läuft im Hostprozess; Absturz oder Hängen greifen auf den ganzen Host über.

Untersucht man „in einem bestimmten Ordner friert der Explorer ein“ oder „der Rechtsklick dauert fünf Sekunden“, ist die Ursache oft nicht die eigene App, sondern eine Shell-Erweiterung eines Drittanbieters. Die Eingrenzung steht in Kapitel 8.

4.3. Übereinstimmung der Bittigkeit — in 64-Bit-Umgebungen ist eine 64-Bit-DLL zwingend

Eine In-Process-DLL muss dieselbe Bittigkeit haben wie der ladende Prozess. Der Explorer auf 64-Bit-Windows ist ein 64-Bit-Prozess; eine nur als 32-Bit gebaute Shell-Erweiterungs-DLL wird gar nicht geladen und erscheint nie im Menü. Es gibt keinen Fehler; das ist ein Klassiker von „registriert, erscheint aber nicht“.

Die App selbst muss nicht 64-Bit werden

Die Kombination 32-Bit-App und 64-Bit-Shell-Erweiterungs-DLL ist zulässig; die COM-Registrierung teilt sich jedoch nach Bittigkeit (Wow6432Node). Der Start über command eines Verbs ist eine andere Prozess-EXE und unterliegt dieser Grenze nicht (32-Bit-EXE bleibt in Ordnung).

flowchart TB
    accTitle: Übereinstimmung der Bittigkeit der Shell-Erweiterungs-DLL
    accDescr: In den 64-Bit-Explorer lässt sich nur eine 64-Bit-Shell-Erweiterungs-DLL laden; eine nur-32-Bit-DLL erscheint ohne Fehler nicht im Menü; eine über command eines Verbs gestartete EXE ist ein anderer Prozess und unterliegt der Grenze nicht
    exp["64-Bit-Explorer"] -->|lädt| d64["64-Bit-Shell-Erweiterungs-DLL"]
    exp -.->|lädt nicht| d32["Nur-32-Bit-DLL"]
    d32 -.-> sym["Erscheint ohne Fehler nicht im Menü"]
    exe["EXE, die das Verb startet"] -->|anderer Prozess| ok32["32-Bit bleibt in Ordnung"]

Abbildung 8: In den 64-Bit-Explorer wird nur eine 64-Bit-DLL geladen; eine über das Verb gestartete EXE unterliegt dieser Grenze nicht.

4.4. Warum man sie nicht in verwaltetem Code schreiben soll

Die Frage „kann man eine Shell-Erweiterung in C# schreiben?“ kommt oft; Microsoft rät von In-Process-Shell-Erweiterungen in verwaltetem Code (.NET) ab und stellt sie ausdrücklich außerhalb des Supports.⁹

Der Grund liegt darin, dass die Erweiterung in beliebige Prozesse geladen wird. Die Host-App wird vor allem durch drei Faktoren instabil.

• CLR-Versionskollision. Besonders unter .NET Framework unter 4.
• Wiedereintritt. Beim Warten auf Sperren tritt die CLR in die Nachrichtenschleife ein.
• Objektlebensdauer. Die nicht deterministische Lebensdauer durch Garbage Collection kollidiert mit dem COM-Referenzzählvertrag.

Manche Punkte sind ab .NET Framework 4 und modernem .NET gemildert; die offizielle Haltung ist unverändert.

Die praktische Linie ist einfach. In-Process-Erweiterungen in nativem C++ schreiben. Wer verwalteten Code will, macht eine normale EXE, die das Verb startet, oder eine Out-of-Process-Erweiterung in einem eigenen Prozess (Vorschauhandler und Ähnliches).⁹

flowchart TB
    accTitle: Entscheidung, ob verwalteter Code zulässig ist
    accDescr: In-Process-Erweiterungen im Explorer-Prozess schreibt man grundsätzlich in nativem C++; verwalteter Code kommt für eine normale EXE, die das Verb startet, oder eine Out-of-Process-Erweiterung in einem eigenen Prozess in Frage
    q1{"Erweiterung im Prozess?"} -->|Ja| cpp["In nativem C++ schreiben"]
    q1 -->|Nein| mg["Verwalteter Code zulässig"]
    cpp -.-> why["CLR-Kollision oder Wiedereintritt macht den Host instabil"]
    mg --> e1["Normale EXE, die das Verb startet"]
    mg --> e2["Out-of-Process-Erweiterung, etwa Vorschau"]

Abbildung 9: In-Process-Erweiterungen sind grundsätzlich natives C++; verwalteter Code bleibt Konfigurationen in einem anderen Prozess vorbehalten.

5. Das neue Kontextmenü unter Windows 11 — Verdopplung des Menüs

Hier der Ablauf warum es ins alte Menü wanderte → Registrierung im neuen Menü → vorhandenen Installer behalten. Den Unterschied zwischen reiner Zuordnung „mit dieser App öffnen“ und dem Hinzufügen eigener Befehle klärt 5.4.

5.1. Was geschehen ist

Windows 11 hat das Kontextmenü des Explorers erneuert. Ausschneiden, Kopieren und Ähnliches stehen oben als Symbolleiste, „Öffnen“ und „Öffnen mit“ sind oben zusammengefasst, von Apps hinzugefügte Befehle werden unter den Shell-Standardbefehlen gruppiert. Fügt eine App mehrere Befehle hinzu, landen sie in einem Flyout (Untermenü) mit App-Namen.⁵

Der entscheidende Punkt: Klassische IContextMenu-basierte Shell-Erweiterungen wurden nicht gelöscht, sondern ins alte Menü verschoben, das mit „Weitere Optionen anzeigen“ (Umschalt+F10) das Windows-10-Menü unverändert lädt.⁵ Das „versteckte Menü“ der Eingangsanfrage ist diese Verdopplung.

flowchart TB
    accTitle: Unter Windows 11 verdoppeltes Kontextmenü
    accDescr: Beim Rechtsklick öffnet sich zuerst das neue Menü; dort erscheinen nur mit IExplorerCommand und Paketidentität registrierte Befehle; klassische IContextMenu-Erweiterungen weichen ins alte Menü aus, das über Weitere Optionen anzeigen geöffnet wird
    rc["Rechtsklick auf eine Datei"] --> newm["Neues Menü (Windows 11)"]
    newm --> newi["Befehle mit IExplorerCommand und Identität"]
    newm -->|Weitere Optionen anzeigen Umschalt+F10| oldm["Altes Menü (Windows-10-Menü)"]
    oldm --> oldi["Klassische IContextMenu-Erweiterung"]
    newi -.-> fly["Mehrere Befehle im Flyout gebündelt"]

Abbildung 10: Im neuen Menü erscheinen nur Befehle mit IExplorerCommand und Identität; klassische Erweiterungen weichen ins alte Menü aus.

5.2. Offizieller Weg ins neue Menü — IExplorerCommand plus Manifestregistrierung

Der offizielle Weg, eigene Befehle im neuen Menü zu zeigen, ist eine native DLL mit IExplorerCommand und die Registrierung im MSIX-Manifest.⁶

Im Manifest zwei Erklärungen schreiben

Das folgende Beispiel erklärt in der ersten Hälfte den COM-Server (CLSID und Implementierungs-DLL) und in der zweiten die Kontextmenüerweiterung (Ziel und Befehl). Dieselbe CLSID verbindet beide.

<!-- Paketmanifest (Auszug) -->
<com:Extension Category="windows.comServer">
  <com:ComServer>
    <com:SurrogateServer DisplayName="Komura commands">
      <com:Class Id="01234567-89AB-CDEF-0123-456789ABCDEF"
                 Path="KomuraCommand.dll" ThreadingModel="STA" />
    </com:SurrogateServer>
  </com:ComServer>
</com:Extension>
<desktop4:Extension Category="windows.fileExplorerContextMenus">
  <desktop4:FileExplorerContextMenus>
    <desktop5:ItemType Type=".kmrpt">
      <desktop5:Verb Id="VerifyReport"
                     Clsid="01234567-89AB-CDEF-0123-456789ABCDEF" />
    </desktop5:ItemType>
  </desktop4:FileExplorerContextMenus>
</desktop4:Extension>

Type von ItemType kann eine bestimmte Erweiterung sein, außerdem * (alle Dateien), Directory (Ordner), Directory\Background (Hintergrund eines Ordners). Die DLL muss zur Architektur des Explorers (64-Bit/ARM64) passen.⁶

Methoden zum Menüaufbau schnell zurückkehren lassen

IExplorerCommand selbst gibt es seit Windows 7; implementiert werden Titel (GetTitle), Symbol (GetIcon), Zustand aktiv/inaktiv/ausgeblendet (GetState) und Ausführen (Invoke). Die Methoden kommen vom UI-Thread; Zugriff auf Netzressourcen ist verboten, und Methoden zum Menüaufbau müssen schnell zurückkehren. Schwere Arbeit folgt nach Invoke.¹⁴⁶

flowchart TB
    accTitle: Manifeststruktur der Registrierung im neuen Menü
    accDescr: Die COM-Server-Erklärung im MSIX-Manifest ordnet CLSID und DLL zu, die Erklärung der Kontextmenüerweiterung verbindet Ziel und Implementierung über ItemType und Verb, und der eigene Befehl erscheint im neuen Menü
    man["MSIX-Manifest"] --> com["COM-Server-Erklärung"]
    man --> ctx["Erklärung der Menüerweiterung"]
    com -->|CLSID und DLL zuordnen| impl["IExplorerCommand-Implementierungs-DLL"]
    ctx -->|über ItemType und Verb angeben| impl
    impl --> shown["Befehl im neuen Menü"]
    ctx -.-> tgt["Ziel ist Erweiterung oder alle Dateien und so weiter"]

Abbildung 11: Zwei Erklärungen im Manifest verbinden Implementierungs-DLL und Ziel, und der Befehl erscheint im neuen Menü.

5.3. Option für nicht verpackte Apps — nur Identität über ein Sparse-Paket

Der Ausweg bei „unsere App lässt sich nur als MSI verteilen, MSIX geht nicht“ ist ein Sparse-Paket (MSIX mit externem Speicherort). Ein kleines, nur aus dem Manifest bestehendes, signiertes MSIX ohne App-Dateien wird am Ende des vorhandenen Installers registriert. Die App erhält Paketidentität und kann die obige Manifestregistrierung (Anzeige im neuen Menü) nutzen.

Verfügbar ab Windows 10 Version 2004; das Paket braucht eine Signatur mit einem auf dem Zielrechner vertrauenswürdigen Zertifikat.⁷ Reihenfolge von Registrierung und Entfernung sowie der Vorbehalt, dass die Registrierung je Benutzer gilt, stehen in 7.3.

flowchart TB
    accTitle: Ablauf, Identität über ein Sparse-Paket zu erhalten
    accDescr: Nachdem der vorhandene Installer die App-Dateien abgelegt hat, registriert ein nur aus dem Manifest bestehendes Sparse-Paket mit externem Speicherort die App, sie erhält Paketidentität, und die Manifestregistrierung im neuen Menü wird möglich
    inst["Vorhandener Installer"] --> files["App-Dateien ablegen"]
    sp["Sparse-Paket"] -.-> only["Nur Manifest, keine App-Dateien"]
    files --> reg["Mit externem Speicherort registrieren"]
    sp --> reg
    reg --> id["Paketidentität erhalten"]
    id --> ok["Registrierung im neuen Menü möglich"]
    sp -.-> sign["Vertrauenswürdige Signatur nötig"]

Abbildung 12: Ein Sparse-Paket ohne App-Dateien, mit externem Speicherort registriert, gibt der App Paketidentität.

Der größte Vorteil ist, den Installer nicht ersetzen zu müssen; das ist die realistische Lösung für Apps mit vorhandenem MSI/EXE-Installer. Der Vergleich mit der vollständigen MSIX-Umstellung steht in „Wahl der Verteilung von Windows-Apps“.

5.4. Wie Zuordnungs-Verben im neuen Menü erscheinen

Ein häufiger Irrtum: Die Zuordnung aus Kapitel 2 und 3 (ProgID und Verb) gilt auch im neuen Menü. Standardverb beim Doppelklick, „Öffnen“ und die Kandidaten unter „Öffnen mit“ werden aus der Zuordnung aufgelöst und oben im neuen Menü gezeigt. Wer nur „mit dieser App öffnen“ will, braucht unter Windows 11 keine zusätzliche Arbeit.

Andererseits ist die Zuordnung keine allgemeine Menüerweiterung; beliebige eigene Befehle in der ersten Ebene des neuen Menüs brauchen IExplorerCommand plus Identität. Das ist die Arbeitsteilung.⁶

flowchart TB
    accTitle: Arbeitsteilung von Zuordnung und neuem Menü
    accDescr: Die Zuordnung aus ProgID und Verb dient auch im neuen Menü der Auflösung von Standardverb, Öffnen und Öffnen mit und erscheint oben; beliebige eigene Befehle in der ersten Ebene des neuen Menüs brauchen IExplorerCommand und Identität
    assoc["Zuordnung (ProgID und Verb)"] --> sol["Auflösung von Standardverb und Öffnen"]
    sol --> top["Oben im neuen Menü"]
    assoc -.-> keep["Unter Windows 11 keine Zusatzarbeit"]
    cmd["Beliebiger eigener Befehl"] --> need["IExplorerCommand plus Identität"]
    need --> first["Erste Ebene des neuen Menüs"]

Abbildung 13: Die Zuordnung löst auch im neuen Menü „Öffnen“; nur eigene Befehle brauchen IExplorerCommand plus Identität.

6. Entscheidungstabelle für die Praxis — welche der drei Optionen

Prüfen Sie zuerst, ob (a) reicht; eigene Befehle im neuen Menü brauchen (b). Vorhandene klassische Erweiterungen vorerst zu halten ist (c).

Entscheidung 1: Das einfachste Mittel wählen, das die Anforderung erfüllt

Anforderungen, die (a) erfüllen, nicht mit (b) oder (c) belasten, steht an erster Stelle. Eine Shell-Erweiterung übernimmt vom Schreiben an die Verantwortung für die Stabilität des Explorers.

Entscheidung 2: Halten des alten Menüs und Verbesserung der Bedienung trennen

(c) heißt nur „nicht kaputt“; das Benutzererlebnis bleibt eine Ebene schlechter. Je häufiger der Befehl im Alltag ist, desto größer der Nutzen einer Migration nach (b).

flowchart TB
    accTitle: Wahl unter den drei Optionen
    accDescr: Reicht Start per Doppelklick oder Öffnen, genügen Zuordnung und statisches Verb; eigene Befehle im neuen Menü brauchen IExplorerCommand und MSIX-Manifestregistrierung, ohne volle MSIX-Umstellung Identität über ein Sparse-Paket; vorhandene klassische IContextMenu-Erweiterungen bleiben vorerst im alten Menü
    q1{"Reicht Öffnen?"} -->|Ja| pa["Zuordnung plus statisches Verb"]
    q1 -->|Nein| q2{"Eigene Befehle im neuen Menü?"}
    q2 -->|Ja| q3{"MSIX-Umstellung möglich?"}
    q3 -->|Ja| pb1["IExplorerCommand plus MSIX"]
    q3 -->|Nein| pb2["Identität über Sparse-Paket"]
    q2 -->|Nein| pc["Klassische Erweiterung vorerst halten"]
    pc -.-> old["Nur im alten Menü"]
    pa -.-> dllfree["Keine DLL, geringes Risiko"]

Abbildung 14: Je nach Anforderung unter statischem Verb, IExplorerCommand plus Identität und Halten der klassischen Erweiterung wählen.

7. Praxis von Ausbringung und Registrierung — Installer, Sparse-Paket, Aufräumen

Ist die Implementierung gewählt, gehören Schreibziel, Änderungsbenachrichtigung, Paketregistrierung und -entfernung sowie Aufräumen bei der Deinstallation in den Installer.

7.1. HKLM oder HKCU

Das Schreibziel folgt der Form des Installers. Für alle Benutzer (Ablage unter Program Files, Administratorrechte) HKLM\Software\Classes, bei Installation je Benutzer (ohne Erhöhung) HKCU\Software\Classes. Mischen erzeugt Anfragen vom Typ „bei A öffnet es, bei B nicht“.

Bei Shell-Erweiterungen mit CLSID-Registrierung kann Reg-Free COM die Registrierung innerhalb der App überflüssig machen, gilt aber nicht für vom Explorer geladene Shell-Erweiterungen; dort braucht es die reguläre Registrierung („Was ist Reg-Free COM?“).

7.2. Nach Änderung benachrichtigen — SHChangeNotify

Nach Registrierung, Änderung oder Löschung einer Zuordnung benachrichtigen Sie mit SHChangeNotify das Ereignis SHCNE_ASSOCCHANGED. Fehlt das, erkennt der Explorer die Änderung manchmal erst nach einem Neustart.¹¹⁰

// Nach einer Zuordnungsänderung einmal aufrufen, etwa in einer Custom Action des Installers
SHChangeNotify(SHCNE_ASSOCCHANGED, SHCNF_IDLIST, nullptr, nullptr);

7.3. Registrierung und Entfernung des Sparse-Pakets

Registrierung und Entfernung des Sparse-Pakets sind Aufgabe des Installers. Registrieren nach dem Ablegen der Dateien, entfernen vor dem Löschen.⁷

# Bei der Installation: nach dem Ablegen der Dateien den Installationsort als externen Speicherort registrieren
Add-AppxPackage -Path "C:\Program Files\KomuraSoft\KomuraReport.identity.msix" `
                -ExternalLocation "C:\Program Files\KomuraSoft"

# Bei der Deinstallation: die Paketregistrierung entfernen, bevor die Dateien gelöscht werden
Remove-AppxPackage <Paketvollname>

Registrierung für den ausführenden Benutzer und Ausbringung für alle Benutzer trennen

Add-AppxPackage registriert für den Benutzer, der es ausgeführt hat. Läuft es aus einer Custom Action eines Per-Machine-MSI unter LocalSystem, erhält der installierende Benutzer keine Identität; daher unter Identitätswechsel (Impersonation) ausführen.

Allerdings gilt auch die Registrierung unter Identitätswechsel nur für den Benutzer, der diese Installation ausgeführt hat. Nutzen mehrere Benutzer denselben PC, haben andere und später angelegte Benutzer keine Paketidentität, und der Befehl erscheint nicht im neuen Menü.

Sollen alle Benutzer ihn nutzen, prüfen Sie beim ersten Start der App die eigene Paketregistrierung und registrieren bei Bedarf — Registrierung je Benutzer. Die Deinstallation plant das Entfernen bei jedem Benutzer mit Registrierung ein.

Wenn das Menü nach der Registrierung nicht erscheint

Das Wirksamwerden einer Manifestregistrierung kann einen Explorer-Neustart (oder Abmeldung) brauchen.⁶

flowchart TB
    accTitle: Reihenfolge von Registrierung und Entfernung eines Sparse-Pakets
    accDescr: Bei der Installation das Sparse-Paket nach dem Ablegen der Dateien registrieren, bei der Deinstallation die Registrierung vor dem Löschen der Dateien entfernen; die Registrierung gilt nur für den ausführenden Benutzer
    i1["Installation"] --> i2["Dateien ablegen"]
    i2 --> i3["Sparse-Paket registrieren"]
    u1["Deinstallation"] --> u2["Paketregistrierung entfernen"]
    u2 --> u3["Dateien löschen"]
    i3 -.-> pu["Registrierung gilt nur für den ausführenden Benutzer"]

Abbildung 15: Registrieren nach dem Ablegen der Dateien, entfernen vor dem Löschen; die Registrierung gilt je ausführendem Benutzer.

7.4. Aufräumen bei der Deinstallation — was löschen und was lassen

Für das Aufräumen bei der Deinstallation gibt die offizielle Anleitung eine klare Linie.¹

• Löschen: den ganzen eigenen ProgID-Schlüssel, Capabilities-/RegisteredApplications-Registrierung, CLSID-Registrierung der Shell-Erweiterung, Sparse-Paket (Remove-AppxPackage).
• Lassen: den Standardwert des Erweiterungsschlüssels (.kmrpt). Die offizielle Empfehlung ist, ihn nicht zu löschen, selbst wenn er noch auf die eigene ProgID zeigt. Nach der Installation zu beurteilen, ob eine andere App die Vorgabe übernommen hat, ist schwierig, und Windows ignoriert eine nicht registrierte Standardwert-ProgID, sodass das Lassen keinen echten Schaden anrichtet.
• Am Ende des Aufräumens ebenfalls SHChangeNotify(SHCNE_ASSOCCHANGED) aufrufen.

Die meisten Probleme „deinstalliert, und Reste erscheinen noch im Menü“ sind Lücken in diesem Aufräumen.

flowchart TB
    accTitle: Entwurf des Aufräumens bei der Deinstallation
    accDescr: Bei der Deinstallation eigene ProgID- und CLSID-Registrierung sowie Sparse-Paket löschen, den Standardwert des Erweiterungsschlüssels lassen, weil eine nicht registrierte ProgID ignoriert wird, und am Ende mit SHChangeNotify benachrichtigen
    un["Deinstallation"] --> del["Löschen"]
    un --> keep["Lassen"]
    del --> d1["ProgID- und CLSID-Registrierung"]
    del --> d2["Sparse-Paket"]
    keep --> k1["Standardwert des Erweiterungsschlüssels"]
    k1 -.-> why["Eine nicht registrierte ProgID wird ignoriert"]
    d1 --> fin["Am Ende mit SHChangeNotify benachrichtigen"]
    k1 --> fin

Abbildung 16: Eigene Registrierung löschen, Standardwert des Erweiterungsschlüssels lassen, am Ende die Änderung benachrichtigen.

8. Fehlerbehebung — fehlt, doppelt, langsam

Störungen untersucht man getrennt nach „erscheint nicht“, „erscheint doppelt oder bleibt“ und „langsam oder stürzt ab“. Zuletzt, wie Registrierung und Aufräumen in einer sauberen Umgebung zu prüfen sind.

8.1. Erscheint nicht im Menü

Zuerst klären, welches Menü Sie ansehen, alt oder neu. Dann in dieser Reihenfolge eingrenzen.

1. Welches Menü: Eine Registrierung im klassischen Stil erscheint nur im alten Menü unter Umschalt+F10. Zuerst beide prüfen.
2. Bittigkeit: Eine nur-32-Bit-Shell-Erweiterungs-DLL wird nicht in den 64-Bit-Explorer geladen (4.3).
3. Schreibziel: HKLM/HKCU, Verwechslung mit Wow6432Node. Den tatsächlichen Schlüssel mit reg query prüfen.
4. Paketregistrierung: Für das neue Menü Vorhandensein mit Get-AppxPackage, Vertrauen des Signaturzertifikats und Pfad von -ExternalLocation prüfen, dann den Explorer neu starten.⁶
5. Vergessene Benachrichtigung: Fehlt SHChangeNotify, erkennt man das daran, ob ein Explorer-Neustart es wirksam macht.

flowchart TB
    accTitle: Reihenfolge der Eingrenzung, wenn es nicht im Menü erscheint
    accDescr: Zuerst klären, welches Menü Sie ansehen, dann Bittigkeit der DLL, Schreibziel in der Registrierung, Paketregistrierung und Signatur, vergessenes SHChangeNotify
    c1["Klären, alt oder neu"] --> c2["Bittigkeit der DLL prüfen"]
    c2 --> c3["Schreibziel HKLM und HKCU prüfen"]
    c3 --> c4["Paketregistrierung und Signatur prüfen"]
    c4 --> c5["Vergessene Benachrichtigung am Neustart erkennen"]

Abbildung 17: Bei „erscheint nicht“ in der Reihenfolge angesehenes Menü, Bittigkeit, Schreibziel, Paketregistrierung, vergessene Benachrichtigung eingrenzen.

8.2. Erscheint doppelt oder bleibt

Zuerst in welchem Menü die Doppelung liegt.

• Nur im alten Menü doppelt: Lücken beim Aufräumen der Deinstallation (7.4) oder Reste einer alten ProgID.
• In alt und neu: Koexistenz klassischer Registrierungsregistrierung und MSIX-Manifestregistrierung.

Beides sind typische Eingrenzungen; urteilen Sie nach dem tatsächlichen Registrierungsinhalt.

flowchart TB
    accTitle: Eingrenzung der Doppelanzeige
    accDescr: Nur im alten Menü doppelt deutet auf Reste wie Aufräumen-Lücke oder alte ProgID; in alt und neu auf Koexistenz klassischer Registrierung und Manifestregistrierung
    q{"Wo doppelt?"} -->|Nur altes Menü| zan["Reste"]
    q -->|Alt und neu| hei["Koexistenz"]
    zan -.-> z1["Aufräumen-Lücke oder alte ProgID"]
    hei -.-> h1["Klassische Registrierung und neue Registrierung nebeneinander"]

Abbildung 18: Nur im alten Menü doppelt spricht für Reste, in alt und neu für Koexistenz.

8.3. Explorer ist langsam oder stürzt ab

Ist der Rechtsklick langsam oder stürzt ein bestimmter Ordner ab, zuerst die installierten Shell-Erweiterungen aufnehmen.

1. Erweiterungen auflisten. Mit einem Werkzeug wie NirSoft ShellExView Nicht-Microsoft-Erweiterungen prüfen.
2. Vorübergehend deaktivieren und eingrenzen. Verdächtige per binärer Suche, die verursachende DLL finden. Bei Absturz ist das „fehlerhafte Modul“ in der Ereignisanzeige ein Hinweis.
3. Bei eigener Erweiterung den Menüaufbaupfad prüfen. Synchrone E/A oder Netzzugriff verdächtigen (4.2 und 5.2).

flowchart TB
    accTitle: Verursachende DLL finden bei langsam oder Absturz
    accDescr: Mit ShellExView Nicht-Microsoft-Shell-Erweiterungen auflisten, Verdächtige vorübergehend deaktivieren und per binärer Suche die verursachende DLL finden; bei Absturz auch das fehlerhafte Modul in der Ereignisanzeige
    s1["Bestandsaufnahme der Shell-Erweiterungen"] --> s2["Nicht-Microsoft auflisten"]
    s2 --> s3["Vorübergehend deaktivieren, binäre Suche"]
    s3 --> s4["Verursachende DLL finden"]
    crash["Bei Absturz"] -.-> ev["Fehlerhaftes Modul prüfen"]
    ev -.-> s4

Abbildung 19: Nicht-Microsoft-Erweiterungen vorübergehend deaktivieren und per binärer Suche eingrenzen; bei Absturz die Ereignisanzeige nutzen.

8.4. Zur Prüfung eignet sich Windows Sandbox

Die Grundprüfung der Shell-Integration ist „in sauberer Umgebung installieren → Verhalten → deinstallieren → keine Reste“. Dafür eignet sich Windows Sandbox (Pro/Enterprise/Education): Bei jedem Start steht in Sekunden ein unbenutztes Wegwerf-Windows bereit, sodass Registrierung und Aufräumen des Installers beliebig oft laufen. Beim Schließen verschwindet alles; das passt auch zur Suche nach Registrierungsresten.¹⁵

9. Zusammenfassung

Heißt es nach dem Wechsel auf Windows 11, „das Menü ist versteckt“, prüfen Sie zuerst in der Entscheidungstabelle in Kapitel 6, was Sie erreichen wollen. Die Überlegung hat drei Stufen.

1. Entscheiden, ob die Zuordnung reicht

Reicht „mit dieser App öffnen“, genügen Zuordnung und statisches Verb weiterhin. Die Grundlage ist Erweiterungsschlüssel → ProgID → Verb; HKCR ist die zur Prüfung bestimmte, überlagerte Sicht der Classes von HKLM und HKCU. Das Schreibziel ausdrücklich setzen, %1 immer in Anführungszeichen.

Die Standard-App wählt jedoch der Benutzer. Der Installer übernimmt die Vorgabe nicht, sondern registriert korrekt als Kandidat.

2. Entscheiden, in welchem Menü eigene Befehle erscheinen

Klassische IContextMenu-Erweiterungen laufen im alten Menü unter „Weitere Optionen anzeigen“. Eigene Befehle im neuen Menü brauchen IExplorerCommand und die Registrierung im MSIX-Manifest. Apps ohne vollständige MSIX-Umstellung erhalten Paketidentität über ein Sparse-Paket; das ist die realistische Lösung.

Die DLL einer klassischen Erweiterung läuft im Prozess von Explorer und anderen. Absturz oder Verzögerung greifen auf den ganzen Host über; ein 64-Bit-Host braucht eine 64-Bit-DLL. In-Process-Erweiterungen in verwaltetem Code werden nicht unterstützt; natives C++ ist die Regel.

3. Registrierung, Änderungsbenachrichtigung und Entfernung als Satz prüfen

Nach Registrierung, Änderung oder Löschung einer Zuordnung mit SHChangeNotify benachrichtigen. Bei der Deinstallation eigene ProgID und Ähnliches löschen, den Standardwert des Erweiterungsschlüssels lassen. Das Sparse-Paket gilt je Benutzer; in Umgebungen mit mehreren Benutzern gehören Registrierung und Entfernung je Benutzer in den Plan.

Mit Windows Sandbox in sauberer Umgebung installieren → Verhalten → deinstallieren → Reste prüfen, wiederholt.

Vom einfachsten Mittel ausgehen und nur bei Bedarf eigene Befehle im neuen Menü hinzufügen. Diese Reihenfolge klärt Umfang der Arbeit und welche Registrierung und Implementierung zu halten sind.

Verwandte Artikel

• Was sind COM, ActiveX und OCX? — Unterschiede und Zusammenhänge
• Was ist Reg-Free COM? — COM ohne Registrierung nutzen
• Registry-32-Bit/64-Bit-Umleitung und Virtualisierungsfallen — Wow6432Node und das Problem „Der Wert, den ich geschrieben habe, ist nicht da“
• Wahl der Verteilung von Windows-Apps — MSI, MSIX, ClickOnce, xcopy, eigener Updater
• Abwärtskompatibilität von DLL- und COM-Schnittstellen — welche Änderungen den Aufrufer zerbrechen
• Windows-Anwendungskompatibilität — Kompatibilitätsmodus, Shims und Compatibility Administrator

Verwandte Beratungsbereiche

KomuraSoft LLC übernimmt Entwurf und Implementierung von Dateizuordnung, Kontextmenü und Shell-Erweiterung für Geschäftsanwendungen, die Anpassung an das neue Kontextmenü unter Windows 11 (IExplorerCommand, Einführung eines Sparse-Pakets), die Überprüfung von Registrierung und Aufräumen vorhandener Installer sowie die Untersuchung, warum der Explorer langsam ist oder abstürzt. Schon bei der Linie „was tun mit dem unter Weitere Optionen anzeigen versteckten Menü?“ zu beginnen ist in Ordnung.

• Windows-App-Entwicklung
• Nutzung und Migration bestehender Assets
• Technische Beratung und Design-Review
• Kontakt

Quellen

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Warum erscheint der Kontextmenüeintrag unserer App unter Windows 11 nur unter „Weitere Optionen anzeigen“?

Weil unter Windows 11 das Kontextmenü des Datei-Explorers in zwei Schichten zerfallen ist, alt und neu. Im neuen Menü erscheinen nur Befehle, die die Schnittstelle IExplorerCommand implementieren und in einem MSIX-Paketmanifest registriert sind, also eine Paketidentität haben. Klassische IContextMenu-basierte Shell-Erweiterungen wurden ins alte Menü verschoben, das Sie mit „Weitere Optionen anzeigen“ (Umschalt+F10) öffnen. Die Erweiterung selbst ist nicht kaputt und funktioniert vorerst weiter, aber wenn Sie sie im neuen Menü wollen, brauchen Sie eine Migration zu IExplorerCommand und entweder die Verpackung als MSIX oder die Vergabe der Identität mit einem Sparse-Paket.

Kann das Installationsprogramm unsere App als Standard-App für eine Datei festlegen, die beim Doppelklick öffnet?

Nein. Die Wahl der Standard-App ist so entworfen, dass sie der Benutzer trifft, und Windows unterstützt das Ändern der Standard-App von nirgendwo sonst als der Systemeinstellungen-UI. Die UserChoice-Informationen, die die Wahl jedes Benutzers halten, sind verschleiert, und ein Filtertreiber (UCPD.sys) schützt sie zusätzlich schreibend vor Apps. Was ein Installationsprogramm tun kann, ist, eine ProgID und Verben zu registrieren, sich zu OpenWithProgIds hinzuzufügen, damit es als Kandidat unter „Öffnen mit“ erscheint, und den Benutzer zur Seite Standard-Apps zu lenken. Die korrekte Implementierung ist nicht, die Vorgabe zu stehlen, sondern bereit zu sein, gewählt zu werden.

Darf ich eine Shell-Erweiterung in verwaltetem Code wie C# schreiben?

Microsoft hat klar gesagt, dass das Schreiben einer In-Process-Shell-Erweiterung (eines Kontextmenühandlers, eines Symbolhandlers und Ähnlichem) in verwaltetem Code nicht empfohlen und nicht unterstützt wird. Die Erweiterung wird in den Explorer und in den Prozess jeder App geladen, die einen gemeinsamen Dateidialog öffnet, sodass CLR-Versionskollisionen, Wiedereintritt und nicht deterministische Objektlebensdauer die Host-App instabil machen. Die Regel ist eine Implementierung in nativem C++. Eine normale EXE, die von einem Verb-Command gestartet wird, oder eine Out-of-Process-Erweiterung wie ein Vorschauhandler, der in einem eigenen Prozess läuft, ist in verwaltetem Code in Ordnung.

Was ist ein Sparse-Paket (MSIX mit externem Speicherort)?

Ein kleines MSIX-Paket, das keine App-Dateien enthält, nur ein Manifest (Identitätsinformationen). Für eine App, die auf gewöhnliche Weise mit einem vorhandenen Installationsprogramm (MSI, Inno Setup und Ähnliches) installiert wird, registrieren Sie es mit Add-AppxPackage -ExternalLocation auf den Installationsordner, und die App erwirbt Paketidentität und kann Funktionen nutzen, die Identität erfordern, etwa die Registrierung im neuen Windows-11-Kontextmenü und Toastbenachrichtigungen. Es ist ab Windows 10 Version 2004 verfügbar, und das Paket braucht eine Codesignatur, der auf dem Zielrechner vertraut wird. Es ist die realistische Option, wenn Sie die neue Menüunterstützung wollen, ohne die gesamte Verteilung auf MSIX umzustellen.

Was soll ich tun, wenn ein Kontextmenüeintrag doppelt erscheint oder nicht verschwindet?

Isolieren Sie zuerst die Ursache, indem Sie prüfen, auf welchem Menü er erscheint: dem neuen oder dem alten (Weitere Optionen anzeigen). Die typische Doppelanzeige ist, dass eine klassische Registrierungsregistrierung und eine MSIX-Manifestregistrierung koexistieren, oder dass eine ProgID- oder Erweiterungs-CLSID-Registrierung bei der Deinstallation zurückgeblieben ist. Nach dem Ändern von Zuordnungen verdächtigen Sie auch ein vergessenes SHChangeNotify(SHCNE_ASSOCCHANGED); direkt nach der Paketregistrierung ein vergessenes Explorer-Neustart. Wenn das immer noch nicht löst, deaktivieren Sie vorübergehend Nicht-Microsoft-Erweiterungen in ShellExView und identifizieren Sie die Täter-DLL per binärer Suche.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.