So deaktivieren Sie Cross-Device Resume

Kurze Antwort

Cross-Device Resume lässt sich über eine MDM-Richtlinie von Windows deaktivieren. In unserem Experiment startete CrossDeviceResume.exe nach deren Anwendung, einem Neustart und der Anmeldung 153 Sekunden lang nicht. Nach dem erneuten Zulassen der Funktion und einem weiteren Neustart erschien der Prozess wieder.

Einfacher lässt sich die Einstellung über BoosterX → Optimierung → Tweaks → Cross-Device Resume anwenden: Deaktivierung auswählen, „Anwenden“ drücken und den PC neu starten. Diese Untersuchung prüfte einen öffentlichen Mechanismus von Windows, nicht die Umsetzung von BoosterX: Wie genau das Programm die Einstellung anwendet, wurde in dieser Reihe nicht getestet und wird im Artikel nicht behauptet. Details zur Anwendung und Rücknahme stehen auf der Seite der Einstellung.

Was geprüft wurde

Uns interessierte nicht nur das Verschwinden der Resume-Benachrichtigungen, sondern auch die Verhinderung des regulären Starts seines separaten Prozesses bei der Anmeldung in Windows. Das sind unterschiedliche Ergebnisse: Ein Programm kann starten und sich sofort beenden, ohne Benachrichtigungen weiterlaufen oder gar keine Startanforderung erhalten.

Microsoft beschreibt DisableCrossDeviceResume als Benutzerrichtlinie, die Benachrichtigungen zur Fortsetzung der Arbeit vom Telefon deaktiviert, und nennt die Notwendigkeit eines Neustarts. Dokumentiert: der Zweck der Richtlinie und der Zeitpunkt ihrer Anwendung. In unserem Experiment beobachtet: das Ausbleiben des Starts eines separaten Prozesses. Beschreibung von Microsoft.

Untersuchungsumfang

Bedingung	Geprüfte Umgebung
System	Windows 11 Pro 25H2, Build 26200.9445
Komponente	CrossDeviceResume 2607.27000.0.0
Prüfstand	Eine virtuelle Maschine VMware
Szenario	Neustart und interaktive Anmeldung desselben Benutzers
Beobachtung	Prozessliste und Audit ihrer Erstellung, Ereignisse 4688
Datum des Experiments	2026-09-17

Dies ist ein funktionales Experiment, kein Test von FPS oder Speicherverbrauch. Das Modell der physischen CPU, die Konfiguration der virtuellen Ressourcen und die Treiberversionen sind nicht in die veröffentlichte Stichprobe aufgenommen. Das Ergebnis lässt sich ohne Prüfung nicht auf physische PCs, andere Builds oder andere Startwege übertragen.

Wie die Prüfung durchgeführt wurde

Zunächst wurde der laufende Prozess und der Ausgangszustand der Richtlinie festgehalten. Dann wurde die verbietende Richtlinie über den lokalen Verwaltungsmechanismus von Windows angewendet, den Erfolg der Operation geprüft und der Zustand zurückgelesen. Nach dem Neustart wurde die interaktive Anmeldung und der Start der Shell abgewartet, die Prozesse und das Journal ihrer Erstellung geprüft.

Zur Gegenkontrolle wurde Resume zugelassen und der Neustart mit Anmeldung wiederholt. Separat wurde die Funktion erneut verboten, der bereits laufende Prozess ausdrücklich beendet und ein möglicher erneuter Start beobachtet. Das Beenden des Prozesses war eine eigenständige Handlung und darf nicht der Richtlinie zugeschrieben werden.

Warum ein Registry-Eintrag noch keine Deaktivierung beweist

Das Vorhandensein der erforderlichen Zahl in der Registry bestätigt nicht, dass Windows sie als gültige MDM-Richtlinie akzeptiert hat. Daher widerspricht die Situation „Wert geschrieben, aber CrossDeviceResume startet trotzdem“ nicht dem Ergebnis dieser Untersuchung.

In der veröffentlichten Dokumentation dieser Richtlinie gibt es keine fertige Entsprechung zu einer normalen Registry-Einstellung. In unserer Reihe gibt es keinen separaten kontrollierten Vergleich aller Varianten der direkten Eintragung. Die direkte Eintragung ist nicht als Ersatz für die Anwendung der Richtlinie bestätigt, aber es gibt auch keinen Grund zu behaupten, dass jede Registry-Änderung immer nutzlos ist. Das funktionierende Ergebnis wurde über den Mechanismus der Richtlinienverwaltung erzielt, mit Prüfung des Zustands und des tatsächlichen Starts nach der Anmeldung.

Die Rolle der System-DLL und der Laborumgehung

Im Experiment wurde die integrierte mdmlocalmanagement.dll verwendet. Sie stellt die Schnittstelle der lokalen Verwaltung bereit: RegisterDeviceWithLocalManagement und ApplyLocalManagementSyncML. Ihre Deklarationen sind im öffentlichen Header des Windows SDK verfügbar. Die Systembibliothek nahm die Anforderung zur Anwendung der Richtlinie an; es war nicht nötig, fremde DLLs herunterzuladen, Windows-Dateien zu ersetzen oder den ausführbaren Code zu patchen. Intune und Cloud-Verwaltung wurden im Versuch nicht verwendet.

Die normale lokale Registrierung auf dem geprüften Windows Pro gab „nicht unterstützt“ zurück. Im Labor gelang es, diese Einschränkung durch vorübergehendes Aktivieren des Embedded Mode zu umgehen, danach die Richtlinie anzuwenden und den ursprünglichen Parameter des Modus wiederherzustellen. Microsoft beschreibt den Embedded Mode im Kontext spezialisierter Geräte Windows IoT. Eine solche Verwendung auf Pro ist kein von Microsoft bestätigtes Supportszenario.

Die Wiederherstellung des temporären Modus entfernte die lokale Verwaltungsregistrierung und die zugewiesene Richtlinie nicht. Nebenwirkungen der vorübergehenden Aktivierung des Modus außerhalb des geprüften Szenarios wurden nicht untersucht. Hier wird das Prinzip des Experiments beschrieben; die Befehle, der Inhalt der Anforderung und die Reproduktionsreihenfolge der Umgehung werden nicht veröffentlicht.

Ergebnisse

Prüfung	Ergebnis und Grenze der Aussage
Anwendung der verbietenden Richtlinie	Operation erfolgreich, das Zurücklesen bestätigte den Zustand
Bereits laufender Prozess	Wurde nicht automatisch beendet
Neustart und Anmeldung mit Verbot	Prozess fehlte; 153 Sekunden nach dem Start der Shell wurde kein Start registriert
Zulassen, Neustart und Anmeldung	Prozess erschien, die Erstellung wurde durch das Journal bestätigt
Erneutes Verbot und separates Beenden des Prozesses	Nach 10 Sekunden fehlte der Prozess; ein erneuter Start wurde innerhalb von 120 Sekunden Beobachtung nicht festgestellt
Vollständige Rücknahme des Prüfstands	Ausgangszustand durch VM-Snapshot wiederhergestellt und geprüft

In der Stichprobe gibt es eine VM und eine Abfolge von Prüfungen. Wiederholte Beobachtungen innerhalb des 120-Sekunden-Intervalls sind keine unabhängigen Experimente. Eine unabhängige Reproduktion auf einem zweiten Computer gibt es nicht.

Was bestätigt ist

• Im geprüften Szenario verhinderte die Richtlinie den regulären Start eines separaten Prozesses nach Neustart und Anmeldung.
• Das erneute Zulassen der Funktion brachte den Start auf demselben Prüfstand zurück.
• Die Anwendung der Richtlinie allein beendet einen bereits laufenden Prozess nicht.
• Für das erzielte Ergebnis waren weder das Ersetzen von System-DLLs noch ein EXE-Patch erforderlich.

Der verhinderte Start schließt die Arbeit dieses Prozesses im beobachteten Szenario aus. Das ist ein konkreter Effekt der Deaktivierung einer unnötigen Hintergrundfunktion, auch ohne FPS-Messung.

Was nicht bestätigt ist

Nicht gemessen wurden der FPS-Zuwachs, die Änderung der Frametime, die allgemeine CPU-Last und die RAM-Einsparung. Nicht geprüft wurden der manuelle Start der EXE, alle alternativen Aktivierungswege, die Platzierung von Resume innerhalb von ShellHost und der Betrieb unter einem anderen Konto oder SYSTEM. Einen separaten Paarversuch der Anwendung über die fertige Oberfläche von BoosterX gab es in dieser Reihe nicht: Die Tabelle beschreibt den Labormechanismus von Windows.

Einschränkungen

Zum Datum der Prüfung kennzeichnet Microsoft die Richtlinie als anwendbar auf Windows Insider Preview. Die Beobachtung auf dem genannten Windows 11 Pro 25H2 ersetzt nicht die offizielle Supportmatrix. Die Prüfung auf einer weiteren geplanten VM fand nicht statt, daher gibt es für sie keine Ergebnisse. Das Ausbleiben von Ereignissen über 153 Sekunden bedeutet nicht ein Verbot jeglicher Starts für immer: Der bestätigte Effekt betrifft den regulären Start nach Neustart und Anmeldung, und den Start des Prozesses auf anderen Wegen hat diese Untersuchung nicht untersucht.

Der Artikel legt nicht fest, auf welche Weise BoosterX seine Einstellung anwendet. Der Zusammenhang zwischen der Karte in BoosterX und der hier geprüften MDM-Richtlinie war nicht Teil des Experimentplans; ein Urteil darüber, ob das Programm denselben Mechanismus verwendet, erfordert eine separate Prüfung anhand des tatsächlichen Verhaltens der Anwendung.

Die Deaktivierung betrifft Resume. Sie darf nicht als Deaktivierung der gesamten „Verbindung mit dem Telefon“ oder der gesamten geräteübergreifenden Infrastruktur von Windows beschrieben werden.

Praktische Schlussfolgerung

Wenn Sie die Fortsetzung der Arbeit vom Telefon nicht nutzen, ist die Deaktivierung von Resume begründet. Auf dem geprüften Prüfstand ermöglichte die MDM-Richtlinie, seinen regulären Start zu vermeiden. Für den Nutzer ist es einfacher, die vorhandene Einstellung in BoosterX zu wählen und den PC neu zu starten, als manuell mit dem Richtlinienspeicher zu experimentieren. Prüfen Sie das Ergebnis auf Ihrer Windows-Version.

Wiederherstellung des Zustands

Im Experiment brachten das Zulassen der Funktion und ein erneuter Neustart den Start des Prozesses zurück. Danach wurde die VM vollständig aus dem ursprünglichen Snapshot wiederhergestellt: Es wurde das Fehlen der während der Prüfung zugewiesenen Richtlinie, der Ausgangszustand des Modus, die Aufhebung der temporären automatischen Anmeldung und die Rückkehr des Prozesses geprüft.

In BoosterX erlaubt das Aktivieren in derselben Karte Resume nach dem Anwenden und einem Neustart. Das ist kein vollständiges Analogon zur Rücknahme des Snapshots: Die lokale Verwaltungsregistrierung, die durch die Laboranwendung der Richtlinie erstellt wurde, bleibt erhalten, ebenso wie zuvor angewendete Einschränkungen anderer Werkzeuge. Details zur Rücknahme sind auf der Seite der Einstellung angegeben.

Öffentliche Primärquellen

• Microsoft: Connectivity / DisableCrossDeviceResume: Zweck der Richtlinie, Benutzerbereich und Neustart; kein Beweis für die Ergebnisse unserer VM.
• Microsoft Windows SDK: mdmlocalmanagement.h: Deklarationen der Schnittstelle der lokalen Verwaltung; kein Versprechen der Verfügbarkeit in jeder Edition.
• Microsoft: Embedded Mode: Kontext von Windows IoT; keine Anleitung für eine unterstützte Anwendung auf Pro.

Die Untersuchung und die verwendeten Werkzeuge gehören dem Entwickler von BoosterX, daher hat der Entwickler ein direktes Interesse an den Ergebnissen. Die Methodik und die Grenzen der Anwendbarkeit sind oben beschrieben, und die Schlussfolgerungen lassen sich anhand offener Daten und der aufgeführten öffentlichen Quellen überprüfen. Microsoft ist nicht der Autor der Untersuchung und hat ihre Schlussfolgerungen nicht bestätigt.

Datum der Prüfung und Änderungsverlauf

2026-09-17: erste Version; öffentliche Quellen geprüft, Ergebnisse einer VM, Grenzen der Aussage und Gegenprüfung des Starts veröffentlicht.

2026-09-19: nach unabhängiger Gegenprüfung wurde der Rahmen der Aussage korrigiert: die Behauptung über einen konkreten Mechanismus von BoosterX entfernt. Die Untersuchung prüft die öffentliche MDM-Richtlinie von Windows und den Laborweg ihrer Anwendung, nicht die Umsetzung der Einstellung im Programm; die Ergebnisse des Experiments, die Grenzen der Aussage und die Quellen bleiben erhalten, die Vorbehalte zu den Grenzen des bestätigten Effekts wurden präzisiert.

2026-09-20: der Disclaimer zum Interessenkonflikt wurde verstärkt: das direkte Interesse des Entwicklers, dem die Untersuchung und die Werkzeuge gehören, wird ausdrücklich anerkannt; die description wurde gekürzt.