Linux Live-Remote-Prozess-Debugging
Dieser Artikel beschreibt, wie Sie eine WinDbg-Live-Verbindung zu Linux herstellen. Für das Remote-Debugging von Live-Prozessen unter Linux ist WinDbg Version 1.2402.24001.0 oder höher erforderlich.
Der GNU Debugger – GDBServer, wird unter Linux verwendet, um die WinDbg-Verbindung zu unterstützen. Weitere Informationen zu GDBServer finden Sie unter https://en.wikipedia.org/wiki/Gdbserver. Sie finden die Dokumentation für das gdb-Remotedebugging beispielsweise hier: https://sourceware.org/gdb/current/onlinedocs/gdb#Remote-Debugging
Die Beispiele hier verwenden das Windows Subsystem für Linux (WSL), es können aber auch andere Implementierungen von Linux verwendet werden.
WinDbg Arten des Remote-Prozess-Debugging
Es gibt zwei primäre Methoden zur Durchführung von Remote-Debugging mit WinDbg – ein Prozessserver oder ein KD-Verbindungsserver. Prozessserver werden für das Debuggen im Benutzermodus verwendet; KD-Verbindungsserver werden für das Debuggen im Kernel-Modus verwendet. Allgemeine Informationen über diese WinDbg-Verbindungstypen finden Sie unter Prozessserver (Benutzermodus) und KD-Verbindungsserver (Kernel-Modus).
Es gibt zwei Möglichkeiten, das Debuggen von Linux Prozessen im Benutzermodus zu starten. Sie können gdbserver entweder in einem bestimmten Prozess starten, oder Sie können gdbserver als Prozessserver starten, der vorhandene Prozesse auflisten und an sie anhängen kann. Dies ist vergleichbar mit dem Prozessserver DbgSrv (dbgsrv.exe) unter Windows. Weitere Informationen finden Sie unter Aktivieren eines Prozessservers.
Debuggen von Linux-Prozessen im Benutzermodus
Es ist möglich, sich mit einem bestimmten Prozess im Benutzermodus zu verbinden oder im Multimodus alle Prozesse in einer Liste anzuzeigen und einen auszuwählen, mit dem Sie sich verbinden möchten. Beide Methoden werden in diesem Thema beschrieben. Beide Methoden haben die gleiche Syntax für die Verbindungszeichenfolge, die im Folgenden beschrieben wird.
Format für die Verbindungszeichenfolge von gdbserver
Das Format für die Verbindung zu gdbserver ist „protocol:arguments“, wobei arguments eine durch Kommata getrennte Liste von „argument=wert“ ist. Bei einer benutzerdefinierten gdbserver-Verbindung lautet das Protokoll gdb, und die Argumente sind wie folgt festgelegt
server=<address> – Obligatorisch: Gibt die IP-Adresse des gdbservers an, mit dem eine Verbindung hergestellt werden soll.
port=<port> – Obligatorisch: Gibt die Port-Nummer des gdbservers an, mit dem eine Verbindung hergestellt werden soll.
threadEvents=<true|false> – Optional: Gibt an, ob die Thread-Ereignisse für diese Version von gdbserver im Stoppmodus korrekt funktionieren oder nicht.
In den aktuellen gdbserver-Versionen gibt es ein Problem, bei dem die Aktivierung von Thread-Ereignissen bei einem Server im Stoppmodus (den WinDbg verwendet) zum Absturz von gdbserver führt. Wenn dieser Wert Falsch ist (der Standardwert), werden Ereignisse zum Starten und Stoppen von Threads zwar synthetisiert, erscheinen aber möglicherweise deutlich später als der tatsächliche Zeitpunkt der Thread-Erstellung/-Zerstörung. Sobald ein Fix für dieses Problem in gdbserver verfügbar ist, können die tatsächlichen Ereignisse über diese Option aktiviert werden.
Verbindung zu einem einzelnen Benutzermodus-Prozess herstellen
In diesem Abschnitt wird beschrieben, wie Sie mit WinDbg einen Benutzermodus-Prozess in Linux identifizieren und sich mit ihm verbinden können.
WSL (Windows Subsystem für Linux)
Die Beispiele hier verwenden WSL (Windows Subsystem für Linux), es können aber auch andere Implementierungen von Linux verwendet werden. Informationen zum Einrichten und Verwenden von WSL finden Sie unter:
- Installieren von Linux unter Windows mit WSL
- Einrichten einer WSL-Entwicklungsumgebung
- Zugriff auf Netzwerkanwendungen mit WSL
- Intune-Einstellungen für WSL
Wählen des gewünschten Prozesses
Listen Sie Prozesse in Linux mit dem Befehl ps -A auf, um den laufenden Prozess zu ermitteln, mit dem Sie sich verbinden möchten.
user1@USER1:/mnt/c/Users/USER1$ ps -A
PID TTY TIME CMD
458 pts/1 00:00:00 bash
460 ? 00:00:00 rtkit-daemon
470 ? 00:00:00 dbus-daemon
482 ? 00:00:19 python3
1076 ? 00:00:00 packagekitd
1196 pts/0 00:00:00 ps
In dieser exemplarischen Vorgehensweise werden wir uns mit python3 verbinden.
Suchen der IP-Adresse des Zielsystems
Wenn Sie eine Verbindung zu einem Remote-Linux-Ziel herstellen, verwenden Sie einen Befehl wie ip route show, um die externe IP-Adresse zu ermitteln.
user1@USER1:/mnt/c/Users/USER1$ ip route show
default via 192.168.1.1 dev enp3s0 proto dhcp metric 100
172.25.144.0/24 dev enp3s0 proto kernel scope link src 192.168.1.107 metric 100
In dieser exemplarischen Vorgehensweise stellen wir eine Verbindung zur WSL her, die auf demselben PC läuft, und verwenden die IP-Adresse localhost.
Anhängen von GDBServer an den ausgewählten Prozess
Geben Sie auf der Linux-Konsole der WSL gdbserver localhost:1234 python3 ein, um den gdbserver auf Port 1234 zu starten und ihn an den python3-Prozess anzuhängen.
USER1@USER1:/mnt/c/Users/USER1$ gdbserver localhost:1234 python3
Process python3 created; pid = 1211
Listening on port 1234
In einigen Linux-Umgebungen muss der Befehl möglicherweise als Administrator*in ausgeführt werden, zum Beispiel mit sudo – sudo gdbserver localhost:1234 python3. Seien Sie vorsichtig bei der Aktivierung des Root-Zugriffs für Debugger-Administrator*innen, und verwenden Sie diesen nur, wenn er erforderlich ist.
Erstellen Sie die Prozessserververbindung in WinDbg
Öffnen Sie WinDbg, und wählen Sie „File / Connect to Remote Debugger“, und geben Sie eine Zeichenfolge für die Verbindung ein. Für dieses Beispiel werden wir gdb:server=localhost,port=1234 verwenden.
Sobald Sie auf die Schaltfläche OK klicken, sollte sich der Debugger mit dem gdbserver verbinden und Sie sollten sich am ersten Haltepunkt für den Prozessstart befinden.
Sobald Sie den ersten Haltepunkt erreicht haben, können Sie mehrmals G drücken. Sie erhalten Nachrichten über das Laden von Modulen (und Ereignisse im Stil von sxe „break on module load“ sollten richtig funktionieren).
Beachten Sie, dass es einen Moment dauern kann, bis Sie zu diesem Punkt gelangen, da die Debugsymbole in den Zwischenspeicher geladen werden. Zusätzlich zur Suche nach Symbolen und Binärdateien über den Symbolserver oder Ihren lokalen Suchpfad verfügt die GDBServer Integration über die Funktionalitäten, diese Dateien aus dem remoten Dateisystem zu ziehen, wenn sie nicht über symsrv oder lokal gefunden werden können. Dies ist in der Regel ein viel langsamerer Vorgang als das Abrufen von Symbolen über symsrv oder einen lokalen Suchpfad, aber es verbessert die Gesamterfahrung durch das Auffinden geeigneter Symbole.
Verwenden Sie den Befehl k stacks, um den Stack aufzulisten. Es werden python3-Module angezeigt, was bestätigt, dass wir python3 unter Linux mit WinDbg debuggen.
0:000> k
# Child-SP RetAddr Call Site
00 00007fff`ffffce10 00007fff`f786d515 libc_so!_select+0xbd
01 00007fff`ffffce80 00005555`55601ce8 readline_cpython_310_x86_64_linux_gnu!PyInit_readline+0xac5
02 00007fff`ffffcf60 00005555`556f06a1 python3!PyOS_Readline+0x109
03 00007fff`ffffcfa0 00005555`556eee7e python3!PyFrame_LocalsToFast+0x62a1
04 00007fff`ffffd000 00005555`556edcf0 python3!PyFrame_LocalsToFast+0x4a7e
05 00007fff`ffffdb80 00005555`557a18e9 python3!PyFrame_LocalsToFast+0x38f0
06 00007fff`ffffdc00 00005555`557a1470 python3!PyCodec_LookupError+0xb09
07 00007fff`ffffdc50 00005555`557b89dc python3!PyCodec_LookupError+0x690
08 00007fff`ffffdc70 00005555`5560b42f python3!PyUnicode_Tailmatch+0xc6c
09 00007fff`ffffdcb0 00005555`5560b012 python3!PyRun_InteractiveLoopObject+0x4e0
0a 00007fff`ffffdd50 00005555`557b7678 python3!PyRun_InteractiveLoopObject+0xc3
0b 00007fff`ffffdda0 00005555`555f55c8 python3!PyRun_AnyFileObject+0x68
0c 00007fff`ffffddd0 00005555`555ea6e8 python3!PyRun_AnyFileExFlags+0x4f
0d 00007fff`ffffde00 00005555`55780cad python3!Py_str_to_int+0x2342a
0e 00007fff`ffffdef0 00007fff`f7c7cd90 python3!Py_BytesMain+0x2d
0f 00007fff`ffffdf20 00007fff`f7c7ce40 libc_so!_libc_init_first+0x90
10 00007fff`ffffdfc0 00005555`55780ba5 libc_so!_libc_start_main+0x80
11 00007fff`ffffe010 ffffffff`ffffffff python3!start+0x25
12 00007fff`ffffe018 00000000`00000000 0xffffffff`ffffffff
An diesem Punkt sollten Sie in der Lage sein, fast alles zu tun, was mit WinDbg möglich ist, das an einen Remote-Windows-Debugger über einen Remote-Prozessserver angehängt ist. Sie können schrittweise vorgehen, auf Quellcodeebene debuggen, Haltepunkte festlegen, Locals inspizieren usw.
Sobald Sie mit dem Debuggen fertig sind, verwenden Sie STRG+D, um das gbdserver-Fenster in WSL zu verlassen.
Verbindung zu einem Prozessserver herstellen
Sie können nicht nur eine Verbindung zu einem einzelnen Prozess über einen Benutzermodus-GDBServer herstellen, sondern auch einen Prozessserver einrichten und vorhandene Prozesse auf dem System auflisten und mit ihnen verbinden. Dazu wird gdbserver mit dem Kommandozeilen-Argument "--multi" gestartet – gdbserver --multi localhost:1234
user1@USER1:/mnt/c/Users/USER1$ sudo gdbserver --multi localhost:1234
Listening on port 1234
Um sich mit dem Prozessserver zu verbinden, wählen Sie in WinDbg „File / Connect to process server“ und geben dieselbe Zeichenfolge ein, die Sie beim obigen gdbserver-Beispiel für einen einzelnen Prozess verwendet haben:
gdb:server=localhost,port=1234
Sobald Sie auf die Schaltfläche OK klicken, sollten Sie mit dem gdbserver als Prozessserver verbunden sein. Wie bei dbgsrv können Sie entweder einen neuen Prozess starten oder die vorhandenen Prozesse auflisten und an einen anhängen.
In diesem Beispiel verwenden Sie die Option „Attach to process“.
Beachten Sie, dass Sie viele der Dinge sehen, die auch für Windows-Prozesse sichtbar sind (einschließlich der PID des Benutzers und der Kommandozeile). Einige der Spalten im Dialogfeld „Attach to process“ sind für Linux nicht relevant und enthalten keine Daten.
Beenden der Sitzung
Verwenden Sie STRG+D, um das gbdserver-Fenster in WSL zu schließen, und wählen Sie in WinDbg die Option "Stop Debugging". Um die Sitzung zu beenden, müssen Sie in manchen Fällen auch den Debugger beenden.
Wiederherstellung der Verbindung zum Prozessserver
WinDbg erkennt einen Prozessserver im Gegensatz zu einem einzelnen Ziel daran, ob der gdbserver mit einem Prozess verbunden ist oder nicht. Wenn Sie an einen Prozess angehängt sind, diesen eingefroren lassen, den Debugger schließen und versuchen, sich erneut mit dem Prozessserver zu verbinden, wird dieser höchstwahrscheinlich nicht als Prozessserver erkannt. Starten Sie in diesem Fall den Ziel-Gdbserver neu, und stellen Sie die Verbindung zum Debugger wieder her.
Linux-WinDbg-Funktionalität
Während ein Großteil der Funktionalität des Debuggers beim Debuggen von Core-Dumps "wie erwartet“ funktioniert (z. B.: Stack-Walking, Symbole, Typinformationen, lokale Variablen, Disassemblierung usw.), ist es wichtig zu beachten, dass die gesamte Debugging-Toolchain noch nicht für ELF, DWARF und die daraus resultierenden Unterschiede zur Windows-Semantik sensibilisiert wurde. Einige Befehle im Debugger können derzeit zu unerwarteten Ausgaben führen. Zum Beispiel zeigt lm immer noch falsche Informationen für ein ELF-Modul an, da es PE-Header erwartet und manuell analysiert.
Linux-Kernel-Modus über EXDI
Der Windows-Debugger unterstützt das Debuggen des Kernels über EXDI. Dies bietet die Möglichkeit, eine Vielzahl von Hardware und Betriebssystemen zu debuggen. Allgemeine Informationen zum Festlegen, Konfigurieren und zur Fehlerbehebung von EXDI-Verbindungen finden Sie unter Konfigurieren des EXDI-Debugger-Transports.
Informationen darüber, wie Sie QEMU-Kernel-Mode-Debugging mit EXDI einrichten, finden Sie unter Einrichten von QEMU-Kernel-Mode Debugging mit EXDI.
Linux-Symbole und -Quellen
Dieser Abschnitt beschreibt die grundlegende Verwendung und Verfügbarkeit von Linux-Symbolen. Ausführlichere Informationen finden Sie unter Linux-Symbole und -Quellen und Source Code Extended Access.
DebugInfoD-Symbolserver
Ab WinDbg Version 1.2104 unterstützt der Quellpfad-Befehl (.srcpath, .lsrcpath (Quellpfad festlegen)) den Abruf von Dateien von DebugInfoD-Servern über den DebugInfoD*-Tag.
Das Tag DebugInfoD* kann auf einen oder mehrere DebugInfoD-Server verweisen, wobei jede Server-URL als https://domain.com formatiert ist und durch *getrennt wird. Die Server werden in derselben Reihenfolge durchsucht wie im Quellpfad aufgeführt. Die Dateien werden aus der ersten übereinstimmenden URL abgerufen. Weitere Informationen finden Sie unter Erweiterter Quellcodezugriff.
Zum Beispiel können Sie mit dem Befehl .sympath (Symbolpfad festlegen) einen DebugInfoD-Pfad wie folgt festlegen.
.sympath+ DebugInfoD*https://debuginfod.elfutils.org
Allgemeine Informationen zum Festlegen des Symbolpfads finden Sie unter Verwenden von Symbolen.
Um Informationen über geladene Symbole anzuzeigen, verwenden Sie !sym noisy. Weitere Informationen finden Sie unter !sym.
Ebenfalls unterstützt wird der automatische Download von Quellen von DebugInfoD-Servern, die die Rückgabe dieses Artefakttyps unterstützen. Das können Sie im Wesentlichen tun:
.srcpath+ DebugInfoD*https://debuginfod.elfutils.org
Weitere Informationen zur Arbeit mit DWARF-Symbolen und den Linux-Symboldienstprogrammen, wie !sourcemap und !diesym, finden Sie unter Linux-Symbole und -Quellen.
Exemplarische Vorgehensweise für C++ Apps
- Verwenden Sie einen Texteditor (wie nano oder vi), um Ihre C++ Datei zu erstellen. Zum Beispiel:
nano DisplayGreeting.cpp
- Schreiben Sie in dem Texteditor Ihr C++ Programm. Hier ist ein einfaches Programm, das Begrüßungen anzeigt und das debuggt werden muss:
#include <array>
#include <cwchar>
#include <cstdio>
#include <iostream>
using namespace std;
void GetCppConGreeting(wchar_t* buffer, size_t size)
{
wchar_t const* const message = L"HELLO FROM THE WINDBG TEAM. GOOD LUCK IN ALL OF YOUR TIME TRAVEL DEBUGGING!";
wcsncpy(buffer, message, size);
}
int main()
{
std::array<wchar_t, 50> greeting{};
GetCppConGreeting(greeting.data(), greeting.size());
cin.get();
wprintf(L"%ls\n", greeting.data());
return 0;
}
Speichern Sie (STRG-O), und beenden Sie (STRG-X) den nano-Editor.
Kompilieren Sie die C++ Datei mit g++. Mit der Option -o geben Sie den Namen der Ausgabedatei an, und die Option -g erzeugt eine Symboldatei:
g++ DisplayGreeting.cpp -g -o DisplayGreeting
Wenn Ihr Code keine Fehler enthält, erstellt der g++ Befehl eine ausführbare Datei mit dem Namen DisplayGreeting in Ihrem Verzeichnis.
Sie können das Programm mit dem folgenden Befehl ausführen:
./DisplayGreeting
- Wenn Sie die Eingabetaste drücken, wird die Nachricht in der App angezeigt. Wenn Sie sich die Ausgabe ansehen, sieht es so aus, als ob die Begrüßung abgeschnitten wird und stattdessen „????“ angezeigt wird.
HELLO FROM THE WINDBG TEAM. GOOD LUCK IN ALL OF YO????
Fehlersuche bei DisplayGreeting
- Sobald der Code zum Ausführen bereit ist, können wir die App über den gdbserver starten.
gdbserver localhost:1234 DisplayGreeting
Öffnen Sie WinDbg, und wählen Sie „File / Connect to Remote Debugger“, und geben Sie eine Zeichenfolge für die Verbindung ein. Für dieses Beispiel werden wir
gdb:server=localhost,port=1234verwenden.Sobald die Verbindung hergestellt ist, sollte die Ausgabe anzeigen, dass der Server auf Port 1234 lauscht und eine Remote-Debugging-Verbindung hergestellt ist.
Bob@Bob6:/mnt/c/Users/bob$ gdbserver localhost:1234 DisplayGreeting
Process /mnt/c/Users/bob/DisplayGreeting created; pid = 725
Listening on port 1234
Remote debugging from host 127.0.0.1, port 47700
Wie bereits erwähnt, muss der Befehl in einigen Linux Umgebungen möglicherweise als Administrator*in ausgeführt werden, in der Regel mit sudo. Seien Sie vorsichtig bei der Aktivierung des Root-Zugriffs für Debugger-Administrator*innen, und verwenden Sie diesen nur, wenn er erforderlich ist.
Hinzufügen der Quellcode- und Symbolpfade zur Debugger-Sitzung
Um Haltepunkte festzulegen und den Quellcode und die Variablen anzuzeigen, legen Sie die Symbole und den Quellpfad fest. Allgemeine Informationen zum Festlegen des Symbolpfads finden Sie unter Verwenden von Symbolen.
Verwenden Sie .sympath, um den Symbolpfad zur Debugger-Sitzung hinzuzufügen. In diesem Beispiel wird der Code an diesem Ort in der WSL Linux Ubuntu für einen Benutzer namens Bob ausgeführt.
\\wsl$\Ubuntu\mnt\c\Users\Bob\
In der WSL wird dieses Verzeichnis dem Speicherort des Windows-Betriebssystems zugeordnet: C:\Users\Bob\
Es werden also diese beiden Befehle verwendet.
.sympath C:\Users\Bob\
.srcpath C:\Users\Bob\
Weitere Informationen über das WSL-Dateisystem finden Sie unter Dateiberechtigungen für WSL.
- Um von den zusätzlichen Symbolen des Linux-Betriebssystems zu profitieren, fügen Sie die DebugInfoD-Symbole unter Verwendung des Speicherorts .sympath hinzu, etwa so.
.sympath+ DebugInfoD*https://debuginfod.elfutils.org
- Ebenfalls unterstützt wird der automatische Download von Quellen von DebugInfoD-Servern, die die Rückgabe dieses Artefakttyps unterstützen. Um davon zu profitieren, fügen Sie den elfutils-Server unter Verwendung von .srcpath hinzu.
.srcpath+ DebugInfoD*https://debuginfod.elfutils.org
Haltepunkt festlegen
Legen Sie einen Haltepunkt in der Hauptansicht der App DisplayGreeting fest.
0:000> bp DisplayGreeting!main
0:000> bl
0 e Disable Clear 00005555`55555225 [/mnt/c/Users/bob/DisplayGreeting.cpp @ 14] 0001 (0001) 0:**** DisplayGreeting!main
Verwenden Sie den Befehl Go oder die Menüoption, um die Ausführung des Codes neu zu starten.
Laden von Quellcode
Verwenden Sie den Befehl .reload, um die Symbole neu zu laden.
Verwenden Sie den Befehl lm, um zu bestätigen, dass wir die App DisplayGreeting ausführen.
0:000> lm
start end module name
00005555`55554000 00005555`55558140 DisplayGreeting T (service symbols: DWARF Private Symbols) c:\users\bob\DisplayGreeting
00007fff`f7a54000 00007fff`f7a732e8 libgcc_s_so (deferred)
00007fff`f7a74000 00007fff`f7b5a108 libm_so (deferred)
00007fff`f7b5b000 00007fff`f7d82e50 libc_so T (service symbols: DWARF Private Symbols) C:\ProgramData\Dbg\sym\_.debug\elf-buildid-sym-a43bfc8428df6623cd498c9c0caeb91aec9be4f9\_.debug
00007fff`f7d83000 00007fff`f7fae8c0 libstdc___so (deferred)
00007fff`f7fc1000 00007fff`f7fc1000 linux_vdso_so (deferred)
00007fff`f7fc3000 00007fff`f7ffe2d8 ld_linux_x86_64_so T (service symbols: DWARF Private Symbols) C:\ProgramData\Dbg\sym\_.debug\elf-buildid-sym-9718d3757f00d2366056830aae09698dbd35e32c\_.debug
Sobald der Befehl den Zugriff auf den Code von DisplayGreeting auslöst, wird er in WinDbg angezeigt.
Verwenden Sie den Befehl k, um den Stack aufzulisten.
0:000> k
# Child-SP RetAddr Call Site
00 00007fff`ffffde00 00007fff`f7b84d90 DisplayGreeting!main+0x1f [/mnt/c/Users/BOB/DisplayGreeting.cpp @ 15]
01 00007fff`ffffdef0 00007fff`f7b84e40 libc_so!__libc_start_call_main+0x80 [./csu/../sysdeps/x86/libc-start.c @ 58]
02 00007fff`ffffdf90 00005555`55555125 libc_so!__libc_start_main_impl+0x80 [./csu/../sysdeps/nptl/libc_start_call_main.h @ 379]
03 00007fff`ffffdfe0 ffffffff`ffffffff DisplayGreeting!start+0x25
04 00007fff`ffffdfe8 00000000`00000000 0xffffffff`ffffffff```
Verwenden Sie den Befehl dx, um die lokale Variable greeting anzuzeigen. Beachten Sie, dass die Größe der Variable 50 beträgt.
0:000> dx greeting
greeting : { size=50 } [Type: std::array<wchar_t, 50>]
[<Raw View>] [Type: std::array<wchar_t, 50>]
Schauen Sie sich den Code an, und stellen Sie fest, dass die Größe 50 für die Begrüßung möglicherweise nicht ausreichend ist.
wchar_t const* const message = L"HELLO FROM THE WINDBG TEAM. GOOD LUCK IN ALL OF YOUR TIME TRAVEL
Bestätigen Sie dies, indem Sie die lokale Variable für die Begrüßung erweitern und feststellen, dass die Begrüßung abgeschnitten ist.
Fehlerbehebung bei der gdbserver-Verbindung
Verwenden Sie die Option --debug, um zusätzliche Informationen in der gdbserver-Konsole anzuzeigen und um mehr Informationen über den Verbindungsstatus zu erhalten. Um zum Beispiel einen Prozessserver zu starten, verwenden Sie diesen Befehl.
gdbserver --debug --multi localhost:1234
Weitere Informationen
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für