Die AltGr-Falle: Warum globale Hotkeys unter Windows in C# scheitern

Sie tippen auf einer deutschen oder österreichischen Tastatur ein @, ein \ oder eine { – und plötzlich löst eine völlig andere Funktion Ihrer Anwendung aus. Kein Tippfehler, kein Zufall: Sobald eine Windows-App einen globalen Hotkey auf Strg+Alt+<Taste> registriert, kollidiert er mit dem AltGr-Sonderzeichen derselben Taste – bei RegisterHotKey ohne Möglichkeit, die beiden zu trennen. In meinen Workshops und eigenen Projekten begegnet mir dieses Problem regelmäßig, und es ist kein Nischenfall: Selbst Visual Studio und Visual Studio Code haben eigene Tickets zu genau diesem Konflikt.

Direktantwort: AltGr löst Strg+Alt-Hotkeys aus, weil Windows die Taste intern als Kombination aus linkem Strg und rechtem Alt implementiert – das Strg-Signal kommt zuerst. Mit RegisterHotKey/WM_HOTKEY ist das von einem echten Strg im Mechanismus selbst nicht zu trennen. Ein eigener Low-Level-Hook sieht mehr: Er liefert linkes und rechtes Alt einzeln (VK_LMENU/VK_RMENU) – für diesen Zweck nicht offiziell zugesagt, aber in der Praxis verlässlich –, worüber sich AltGr ausschließen lässt.

Was AltGr unter Windows technisch wirklich ist

Auf internationalen Tastaturlayouts – Deutsch, Österreichisch, Schweizer, Französisch (AZERTY), Spanisch und vielen weiteren – gibt es keine eigene „AltGr“-Taste im Sinne der Hardware: Physisch ist es die rechte Alt-Taste. Windows steuert ihr Verhalten über ein Flag im Tastaturlayout (KLLF_ALTGR) und injiziert beim Drücken zusätzlich ein linkes-Strg-Signal, das vor dem Alt-Signal eintrifft – eine bewusste Design-Entscheidung, kein Fehler. AutoHotkey bildet dasselbe Verhalten mit einem eigenen Modifier-Symbol (<^>!) nach.

Das ist der Kern der Falle: Für RegisterHotKey/WM_HOTKEY sehen echtes und synthetisches Strg identisch aus – im Mechanismus selbst gibt es keinen Ausweg (was sich im Handler nachträglich abfedern lässt, siehe Lösungsabschnitt). Ein eigener Low-Level-Keyboard-Hook bekommt mehr Rohdaten: Das synthetische Strg trägt einen anderen Scan-Code (0x21D statt 0x1D), zusammengesetzt aus zwei Konstanten in Microsofts eigenem Treiber-Header kbd.h (SCANCODE_CTRL, SCANCODE_SIMULATED). Der Haken: Dieser Header richtet sich an Layout- und Treiberentwickler, nicht an Anwendungen – Microsoft sagt den Wert Anwendungen nicht als Verhalten zu. Projekte wie AutoHotkey nutzen ihn trotzdem (SC_FAKE_LCTRL); warum die Lösung in diesem Artikel bewusst darauf verzichtet, steht im Lösungsabschnitt.

Die Kehrseite ist genauso wichtig: Auf einem AltGr-Layout ist Strg+Alt nicht nur verwechselbar mit AltGr, sondern auf Zeichenebene dieselbe Shift-Ebene – Strg+Alt+ß erzeugt auf einer deutschen Tastatur dasselbe \ wie AltGr+ß. Unterscheidbar wird das erst eine Ebene tiefer, im rohen Tastenereignis (dazu gleich mehr). Als Hotkey-Präfix ist Strg+Alt auf solchen Layouts deshalb nicht nur gelegentlich gestört, sondern von Grund auf ungeeignet.

Warum Strg+Alt-Hotkeys mit AltGr kollidieren können

Betroffen sind die üblichen Wege, einen globalen Hotkey zu bauen: ein eigener Low-Level-Keyboard-Hook, der das Signal sieht, aber leicht zu früh auswertet, und RegisterHotKey, das den Unterschied zwischen echtem und synthetischem Strg gar nicht erst zu sehen bekommt (mehr dazu im Lösungsabschnitt).

Wie verbreitet das Problem ist, zeigt ein Blick auf öffentlich dokumentierte Fälle: Visual Studio und Visual Studio Code haben eigene Tickets dazu – VS Code kippte die Richtung dabei sogar zweimal. 2017 bis 2018 feuerten Strg+Alt-Shortcuts dort ungewollt bei AltGr (ungarisches und polnisches Layout); ab 2019 kehrte sich das um (Strg+Alt feuerte plötzlich nicht mehr bei AltGr), seit VS Code 1.75 (Anfang 2023) lässt sich das über die Einstellung keyboard.mapAltGrToCtrlAlt wieder umschalten. Auch weitere Werkzeuge – darunter Eclipse Theia, die Godot Engine und Atom – haben eigene AltGr-Tickets, und Microsoft PowerToys führt den Konflikt bis heute als offizielles Known Issue. Der älteste belastbare Beleg kommt von Microsoft selbst: Raymond Chen beschrieb das Verhalten schon 2004 im offiziellen Entwicklerblog, unter dem Titel „Why Ctrl+Alt shouldn’t be used as a shortcut modifier“.

Eine Lösung auf Ebene von RegisterHotKey bietet Microsoft nicht – unterscheiden lässt sich AltGr nur eine Ebene tiefer, in den Rohereignissen (siehe Lösungsabschnitt) –, wohl aber die eigene Empfehlung, Strg+Alt gar nicht erst als Shortcut-Modifier zu verwenden (das steht bis heute in den Windows-Design-Richtlinien, einem seit Windows 7 nicht mehr aktualisierten Dokument). Einzelne Werkzeuge lösen den Konflikt zumindest teilweise selbst – Windows Terminal etwa mit einer 2019er-Korrektur plus der (standardmäßig aktiven) Einstellung altGrAliasing. Wer eine Windows-Anwendung mit globalen Tastenkombinationen für ein internationales Publikum baut, trifft früher oder später darauf.

🚀 KI schreibt mit, aber sie kennt AltGr nicht automatisch: Wenn Sie Hotkey-Code mit einem KI-Coding-Assistenten erstellen lassen, prüfen Sie das Ergebnis gezielt auf genau dieses Problem – mein Vergleich der gängigen KI-Coding-Assistenten zeigt, wie unterschiedlich gut die Tools mit solchen plattformspezifischen Windows-Eigenheiten umgehen.

Der Fehler im eigenen Projekt – eine Fallstudie

Ich habe diesen Fehler nicht in der Theorie kennengelernt, sondern in einem eigenen Tool, das auf globale Tastenkombinationen reagiert. Und das Ärgerliche daran: Ich hatte das Problem eigentlich schon einmal gelöst – nur an der falschen Stelle.

In einem frühen Testlauf hatte ich bereits gemessen, dass ein AltGr-Tastendruck als „linkes Strg, dann rechtes Alt“ ankommt. Diese Erkenntnis war korrekt. Nur die Konsequenz, die ich daraus zog, war zu eng gefasst: Ich habe daraufhin dafür gesorgt, dass ein Hotkey, der selbst auf Strg+Alt registriert ist, AltGr nicht versehentlich als eigene Kombination fehlinterpretiert. Was ich dabei übersehen habe, war der umgekehrte Fall – dass dasselbe synthetische Strg-Signal auch einen ganz anderen Hotkey auslöst: einen, der Strg zwar erwartet, aber kein Alt, einfach weil das Strg-Signal durchkommt, bevor irgendjemand weiß, dass gleich noch ein Alt folgt.

Der Fehler saß dadurch von Anfang an im primären Hotkey der Anwendung, unbemerkt über mehrere Entwicklungsphasen hinweg. Automatisierte Tests haben ihn nicht gefangen, weil niemand einen Testfall für „AltGr während eines völlig anderen Sonderzeichens“ geschrieben hatte – wieso auch, das Problem war ja „schon gelöst“. Aufgefallen ist er erst im Handtest. Das ist die unangenehme Lektion daraus: Eine korrekt gemessene Tatsache schützt Sie nicht automatisch vor der falschen Schlussfolgerung an einer zweiten Stelle im Code.

Die Lösung: Rechtes Alt als Ausschluss- und Abbruch-Signal

Die tragfähige Lösung dreht die Perspektive um: Statt das synthetische Strg-Signal zu filtern, behandelt man das rechte Alt selbst als das entscheidende Signal – zuverlässig und stabil, mit praktisch demselben Ergebnis wie der schärfere, aber inoffizielle Scan-Code-Filter von oben. Wo genau die beiden sich unterscheiden, steht am Ende dieses Abschnitts.

Wichtig: Das funktioniert nur, wenn Sie die Tastenereignisse selbst sehen – über einen eigenen Low-Level-Keyboard-Hook (SetWindowsHookEx mit WH_KEYBOARD_LL; Microsoft empfiehlt für dauerhaftes Mitlesen eigentlich Raw Input statt Low-Level-Hooks, dort liegen die Ereignisse aber auf einer anderen Ebene und die AltGr-Logik muss eigens getestet werden). Mit RegisterHotKey haben Sie im Mechanismus selbst keine Chance: fsModifiers kennt nur MOD_CONTROL/MOD_ALT, ohne Links/Rechts-Unterscheidung. Wer dabei bleibt, sollte Strg+Alt-Kombinationen vermeiden oder den Treffer im Handler best-effort per GetAsyncKeyState(VK_RMENU) gegenprüfen – kein race-freier Ersatz, aber ein brauchbarer Filter.

Für rein lokale Hotkeys (nicht global) reicht übrigens die gewöhnliche Nachrichtenschleife: Auf AltGr-Layouts kommt das rechte Alt als WM_KEYDOWN statt als WM_SYSKEYDOWN – ein dokumentiertes Indiz, verlässlich aber nur mit Kenntnis des aktiven Layouts. Für die hier gezeigte globale Abbruchlogik brauchen Sie den eigenen Hook.

Eine Voraussetzung trägt die ganze Lösung: EvaluateHotkeyCandidate darf die eigentliche Aktion nicht sofort auslösen. Sie muss den Kandidaten erst als Recognizing vormerken und die Aktion erst nach einer kurzen Bestätigungsphase ausführen. Nur dann kann ein nachfolgendes rechtes Alt überhaupt noch etwas abbrechen – feuert die Aktion bereits beim synthetischen Strg, kommt jede Abbruch-Logik zu spät.

// AltGr-Ausschluss-/Abbruchlogik fuer einen eigenen Low-Level-Hook.
// Commit-Mechanismus von EvaluateHotkeyCandidate: siehe Text oben.
// Setzt ein aktives AltGr-Layout voraus (sonst blockiert es auch
// echtes rechtes Alt auf Layouts wie US-Englisch).
private bool _rightAltDown;
private HotkeyState _state = HotkeyState.Idle;

private void OnKeyDown(Keys key)
{
    if (key == Keys.RMenu) // rechtes Alt; auf AltGr-Layouts = AltGr
    {
        _rightAltDown = true;

        // Bereits laufende Erkennung sofort abbrechen,
        // nicht nur "loslassen" – sonst wird ein Bruchstück
        // als gültiger Hotkey interpretiert.
        if (_state == HotkeyState.Recognizing)
        {
            _state = HotkeyState.Cancelled;
            return;
        }
    }

    if (_rightAltDown)
    {
        // AltGr aktiv: Diese Tastenkombination
        // darf keinen Hotkey auslösen.
        return;
    }

    EvaluateHotkeyCandidate(key);
}

private void OnKeyUp(Keys key)
{
    if (key == Keys.RMenu)
    {
        _rightAltDown = false;

        // Sperre wieder freigeben, sonst bleibt jeder Hotkey
        // nach dem ersten AltGr-Druck dauerhaft blockiert.
        if (_state == HotkeyState.Cancelled)
        {
            _state = HotkeyState.Idle;
        }
    }
}

Drei Dinge stecken darin: Erstens schließt rechtes Alt jede Kombination pauschal aus, solange es gedrückt ist. Zweitens bricht es eine laufende Erkennung aktiv ab (Zustand Cancelled, nicht einfach ein Loslassen) – ein simples Loslassen würde das bis dahin Erkannte trotzdem weiterverarbeiten, und das synthetische Strg-Signal trifft ja schon vor dem Alt ein. Drittens gibt OnKeyUp die Sperre wieder frei, sonst bleiben nach dem ersten AltGr-Druck alle Hotkeys blockiert.

In der Praxis braucht das noch eine Rückfallsicherung: Geht ein KeyUp verloren, hilft eine periodische Gegenprüfung über GetAsyncKeyState(Keys.RMenu) – aber außerhalb des Hook-Callbacks, etwa über einen separaten Timer, da der Tastenzustand innerhalb von LowLevelKeyboardProc noch nicht zuverlässig aktualisiert ist. Ein ganz anderer Fehlerfall ist, wenn Windows einen zu langsamen Hook selbst stillschweigend entfernt – dagegen hilft nur, den Callback extrem kurz zu halten und Arbeit an einen anderen Thread zu delegieren.

In einer testbaren Umgebung lohnt es sich, diese Erkennungslogik als eigene, von der Windows-API entkoppelte Klasse zu bauen und mit einem Test abzudecken, der ohne den AltGr-Ausschluss nachweislich fehlschlägt.

Der Kompromiss dahinter: Der Scan-Code-Filter aus dem vorigen Abschnitt (0x21D, nicht offiziell zugesagt) würde sogar das allererste Tastenereignis korrekt einordnen. Die RMenu-Lösung verzichtet bewusst auf diese letzte Präzision und nimmt dafür einen kurzen, gut abgesicherten Randfall in Kauf – derselbe Tausch, den Microsofts eigene RichEdit-Komponente trifft, die linkes Strg + rechtes Alt seit Jahren gar nicht erst als Hotkey behandelt.

Praxis-Tipps für eigene globale Hotkeys unter Windows

Wenn Sie selbst globale Tastenkombinationen in einer Windows-Anwendung implementieren, sind das die Punkte, die ich aus diesem Fall mitnehme:

• Vermeiden Sie Strg+Alt+<Taste> als primäre Kombination – das deckt sich mit Microsofts eigener Empfehlung von 2004. Weichen Sie auf Strg+Shift+<Taste> aus (für seltener genutzte Befehle; für häufige nennt Microsoft z. B. Strg+G/J/K/L/M/Q/R/T oder Strg+Zahl). Das ersetzt den AltGr-Ausschluss aus dem Codebeispiel nicht, sondern ergänzt ihn: Wertet Ihre Logik ein Strg-Signal sofort aus, kann AltGr auch einen Hotkey ganz ohne Alt anstoßen (siehe Fallstudie). Die Windows-Taste ist dagegen keine saubere Ausweichoption: Microsoft reserviert Windows-Tasten-Kombinationen ausdrücklich für das Betriebssystem – auch eine heute freie Kombination kann künftig belegt werden, und RegisterHotKey scheitert an bereits registrierten.
• Testen Sie aktiv mit AltGr-Tastendrücken, nicht nur mit den Tasten, die Ihr Hotkey formal erwartet. Ein Testfall, der gezielt RMenu simuliert, deckt genau diesen Fall ab, den ein „normaler“ Hotkey-Test übersieht.
• Behandeln Sie rechtes Alt als eigenständiges Signal, nicht nur als einen weiteren Modifier neben Strg und Alt. Die Unterscheidung zwischen Ausschluss und aktivem Abbruch ist dabei kein Detail, sondern trägt die eigentliche Lösung.
• Rechnen Sie damit, dass die Erkennung beim ersten Ereignis jeder AltGr-Kombination – dem synthetischen Strg – kurz anläuft und erst durch das folgende rechte Alt abgebrochen wird, statt das wegzudiskutieren. Genau deshalb braucht die Lösung die Bestätigungsphase. Diese kurze Verzögerung bewusst in Kauf zu nehmen ist besser als ein zusätzlicher Lookahead, der jede normale Nutzung weiter verlangsamt.

📊 Wenn Sie ohnehin an der Modernisierung Ihrer .NET-Codebasis arbeiten: Ein guter Zeitpunkt, um Hotkey- und Plattform-Code zu überprüfen, ist ein Framework-Upgrade – mein Überblick zum Upgrade auf .NET 10 zeigt, welche Neuerungen dabei auch für Windows-nahen Code relevant sind.

⚙️ Ein Randfall wie dieser ist ein kleines Beispiel für ein größeres Prinzip: Verhalten, das aus einer tieferen Abhängigkeit kommt und nicht aus dem eigenen Code, taucht in ganz unterschiedlichen Kontexten auf – mein Artikel zur Supply-Chain-Sicherheit in der KI-Infrastruktur beleuchtet, wie oft die eigentliche Ursache eines Problems eine Ebene tiefer liegt, als man zunächst vermutet.

Fazit: Ein Betriebssystem-Verhalten, keine eigene Schuld

Die AltGr-Falle ist kein Zeichen für schlechten Code. Sie ist ein seit über 20 Jahren bekanntes, dokumentiertes Windows-Verhalten, für das es keinen pauschalen Fix von Microsoft gibt – nur die eigene Empfehlung, Strg+Alt als Shortcut-Modifier zu vermeiden. Wer globale Hotkeys unter Windows registriert und dabei internationale Tastaturlayouts im Blick hat, muss AltGr aktiv mitdenken – nicht als Sonderfall am Rand, sondern als festen Bestandteil der Hotkey-Logik von Anfang an. Die Lösung ist überschaubar: rechtes Alt konsequent als Ausschluss- und Abbruch-Signal behandeln, den kurzen vorläufigen Erkennungszustand bewusst berücksichtigen und mit gezielten Tests absichern. Das kostet eine überschaubare Menge Code – aber deutlich weniger Nerven, als den Fehler erst im Live-Betrieb über Bug-Reports frustrierter Nutzer zu finden.

Ihre Erfahrungen sind gefragt!

Sind Ihnen ähnliche Tastatur-Eigenheiten unter Windows schon einmal begegnet, oder kämpfen Sie aktuell mit einem Hotkey, der sich einfach nicht zuverlässig verhält? In meinen weiteren .NET-Artikeln finden Sie mehr Praxis-Tipps für Entwickler, die mit den Eigenheiten von Windows direkt arbeiten.

Quellen:

• Hot Keys and altGr | Microsoft (Murray Sargent, 2015)
• Why Ctrl+Alt shouldn’t be used as a shortcut modifier | Microsoft (Raymond Chen, 2004)
• Keyboard – Choosing shortcut keys | Microsoft Learn
• Keyboard Manager for PowerToys | Microsoft Learn (Known Issues)
• Fixed Ctrl+Alt shortcuts conflicting with AltGr | Windows Terminal (Pull-Request #2235)
• VS Code PR #168607 – keyboard.mapAltGrToCtrlAlt
• AutoHotkey_L, keyboard_mouse.h – SC_FAKE_LCTRL