[English]Gibt es ein RDP-Problem mit Android, wenn per Remote-Desktop-App auf Windows Server 2022 zugegriffen werden soll? Blog-Leser Alexander S. hat mich vor einigen Tagen per Mail kontaktiert und mich über seine Beobachtungen informiert. Der Server verabschiedet sich mit einem BlueScreen. Ich stelle das Thema mal im Blog ein, vielleicht gibt es weitere Betroffene.
Anzeige
Blog-Leser Alexander S. ist über meinen RDP-Beiträge hier im Blog auf das Thema aufmerksam geworden und schrieb mir in seiner E-Mail Anfrage RDP:
Sehr geehrter Herr Born,
Ich bin auf Ihren Blog gestoßen und habe dort einige hilfreiche Beiträge gefunden.
Derzeit habe ich ein RDP-Problem (wie unten beschrieben) mit Windows Server 2022 und der RDP Verbindung mittels der Microsoft Remotedesktop App auf Android Geräten.
Das Problem ist schon etwas arg exotisch, da die Microsoft Remotedesktop App auf Android Geräten auf dem Windows Server 2022 einen BlueScreen wirft. Dazu schrieb der Leser.
Wir verwenden bei uns im Unternehmen neben den Rechnern im Büro auch Android Tablets (Samsung Galaxy S6 Lite). Über diese würde ich nun auch gerne den Server via VPN und RDP erreichen. Dazu verwenden wir auf den Tablets die Microsoft Remotedesktop App.
Nur mussten wir feststellen, dass dies zwar grundsätzlich funktioniert, sich über die Android Tablets zu verbinden, aber uns der Server immer wieder in den BlueScreen geht, so bald bestimmte Aktionen ausgeführt werden. Eine ist z.B. das Öffnen der Einstellungen oder das Doppelklicken auf das Windows Symbol (Startmenü), aber auch noch weitere.
Die Ereignisanzeige gibt danach folgende Meldungen aus:
Die folgenden SPNs konnten vom WinRM-Dienst nicht erstellt werden <URL>
Leider konnte ich im Internet dazu keine hilfreichen Infos finden. Falls Ihnen dieses Verhalten oder sogar eine Lösung dazu bekannt ist, würde ich mich über eine Rückmeldung sehr freuen!
Mir ist bisher keine Lösung oder ein weiterer Fall zum Problem bekannt – weiß auch nicht, ob es bereits gelöst ist (die Mail ist ja vom 9. Jan. 2023, Thema ist etwas liegen geblieben, sorry). Schon seltsam, dass der Windows Server 2022 da die Grätsche macht und einen BlueScreen wirft. Hat jemand sonst noch dieses Verhalten. Falls wer was zu weiß, kann er ja einen Kommentar hinterlassen.
Ein Speicherdump liegt mir nicht vor – aber aktuell habe ich auch keinen Debugger mehr, um den Dump auszuwerten. Einen Ansatz zur BlueScreen-Analyse habe ich vor Jahren im Artikel Windows BlueScreen-Analyse – Teil 3 beschrieben
2015
Interessanter Zusammenhang …
Aufgrund der Fehlermeldung kann ich mir denken, dass es keinen Unterschied macht, ob der Zugriff/Login als Administrator oder als Standardbenutzer (ggf. Terminal Server?) erfolgt.
Wenn ich könnte, würde ich das gezielt von meinem Samsung Galaxy Tab S8 aus testen. Ich aber keinen Zugang zu einem Windows Server 2022.
Ja das ist korrekt, es macht keinen Unterschied ob als Admin oder als normaler Benutzer.
Die SPNs haben damit vermutlich nix zu tun. Fehlercode 0x3b heißt: SYSTEM_SERVICE_EXCEPTION, also vermutlich spinnt ein Treiber.
Im Internet haben die Leute bei diesem Fehlercode Probleme mit Netzwerktreibern, USB-Treibern oder Chipsatztreibern.
NirSofts BlueScreenView könnte zumindest einen ersten Anhaltspunkt geben, welche Treiber beteiligt waren.
NirSofts BlueScreenView gibt folgende Infos:
Zum Dump File:
Bug Check String: SYSTEM_SERVICE_EXCEPTION
Bug Check Code: 0x0000003b
Parameter 1: 00000000`c0000005
Parameter 2: ffff9821`827a058e
Parameter 3: ffffb986`90444300
Parameter 4: 00000000`00000000
Caused By Driver: win32kbase.sys
Caused By Address: win32kbase.sys+1a058e
File Description: Basis-Win32k-Kerneltreiber
Product Name: Betriebssystem Microsoft® Windows®
Company: Microsoft Corporation
File Version: 10.0.20348.1 (WinBuild.160101.0800)
Processor: x64
Crash Address: ntoskrnl.exe+418580
Processors Count: 16
Major Version: 15
Minor Version: 20348
Weiters markiert NirSofts BlueScreenView in der unteren hälfte zwei Files rot:
File 1:
Filename: ntoskrnl.exe
Address In Stack: ntoskrnl.exe+42d869
From Address: fffff807`0ee00000
To Address: fffff807`0fe47000
Size: 0x01047000
Time Stamp: 0x4172820a
Time String: 17.10.2004 15:30:34
Product Name: Microsoft® Windows® Operating System
File Description: NT Kernel & System
File Version: 10.0.20348.1487 (WinBuild.160101.0800)
Company: Microsoft Corporation
Full Path: C:\Windows\system32\ntoskrnl.exe
File 2:
Filename: win32kbase.sys
Address In Stack: win32kbase.sys+1a058e
From Address: ffff9821`82600000
To Address: ffff9821`828df000
Size: 0x002df000
Time Stamp: 0x494fa5dd
Time String: 22.12.2008 15:36:13
Product Name: Betriebssystem Microsoft® Windows®
File Description: Basis-Win32k-Kerneltreiber
File Version: 10.0.20348.1 (WinBuild.160101.0800)
Company: Microsoft Corporation
Full Path: C:\Windows\system32\win32kbase.sys
Über weitere Hilfe bzw. Infos würde ich mich sehr freuen!
Nirsoft BlueScreen Viewer scheint leider nicht genügend Informationen auszuwerfen (der zieht kaum Informationen und ist zudem wohl auf den Mini-Dump angesetzt worden). In manchen Fällen reicht aber dessen Analyse, wenn er einen speziellen Treiber als Verursacher nennt.
Was Du noch tun kannst: Gehe die drei von mir verlinkten Artikel zur BlueScreen-Analyse durch – schaue dir an, was zum Erstellen eines vollständigen Dump erwähnt ist und stelle das so ein, dass der erstellt wird. Dann könntest Du den Nirsoft BlueScreen Viewer nochmals probieren. Hilft das nicht, bleibt nur noch, den Microsoft Debugger (sollte es inzwischen im Windows Store geben) zu installieren und den vollständigen Kernel-Dump analysieren lassen.
Die Fragmente zur Vorgehensweise habe ich ja in den verlinkten Beiträgen skizziert. Möglicherweise wird dir ja der spezielle Treiber, der bei euch den BlueScreen auslöst (könnte ein Netzwerktreiber sein, da die RDP-Verbindung darüber läuft) ausgeworfen.
Ich selbst kann aktuell keine Unterstützung liefern, da ich a) keinen Microsoft Debugger mehr installiert und b) seit 5 oder 6 Jahren keine Dump-Analysen mehr durchgeführt habe (und gut war ich da drin auch nicht – die Zeiten, als ich mit Maschinencode auf Du stand, sind bei mir 1985 mit dem Aufstieg vom Entwickler ins Management zu Ende gegangen – die x86 Maschinencode-Befehle habe ich mir nie zu Gemüte geführt).