כיצד להשבית Cross-Device Resume
בדף זה
תשובה קצרה
Section titled “תשובה קצרה”ניתן להשבית את Cross-Device Resume באמצעות מדיניות MDM של Windows. בניסוי שלנו, לאחר החלתה, אתחול מחדש וכניסה למערכת, CrossDeviceResume.exe לא הופעל במשך 153 שניות של תצפית.
כאשר התכונה הותרה מחדש ובוצע אתחול נוסף, התהליך הופיע שוב.
קל יותר להחיל את ההגדרה דרך BoosterX → אופטימיזציה → TweaX → Cross-Device Resume: לבחור השבתה, ללחוץ “החל” ולאתחל את המחשב. מחקר זה בדק מנגנון ציבורי של Windows, ולא את המימוש של BoosterX: כיצד בדיוק התוכנה מחילה את ההגדרה לא נבדק בסדרה זו ולא נטען במאמר. פרטי ההחלה וההחזרה מופיעים בעמוד ההגדרה.
מה נבדק
Section titled “מה נבדק”לא עניין אותנו רק היעלמות ההתראות של Resume, אלא גם מניעת ההפעלה הרגילה של התהליך הנפרד שלו בעת הכניסה ל-Windows. אלה תוצאות שונות: התוכנה יכולה לפעול ולהסתיים מיד, להמשיך לפעול ללא התראות, או כלל לא לקבל בקשה להפעלה.
Microsoft מתארת את DisableCrossDeviceResume כמדיניות משתמש
המשביתה התראות על המשך עבודה מהטלפון, ומציינת את הצורך
באתחול מחדש. מתועד: ייעוד המדיניות ומועד החלתה.
נצפה בניסוי שלנו: היעדר הפעלה של התהליך הנפרד.
תיאור Microsoft.
תחום המחקר
Section titled “תחום המחקר”| תנאי | סביבה שנבדקה |
|---|---|
| מערכת | Windows 11 Pro 25H2, build 26200.9445 |
| רכיב | CrossDeviceResume 2607.27000.0.0 |
| מתקן | מכונה וירטואלית אחת של VMware |
| תרחיש | אתחול מחדש וכניסה אינטראקטיבית של אותו משתמש |
| תצפית | רשימת תהליכים וביקורת יצירתם, אירועים 4688 |
| תאריך הניסוי | 2026-09-17 |
זהו ניסוי פונקציונלי, ולא בדיקת FPS או צריכת זיכרון. דגם ה-CPU הפיזי, תצורת המשאבים הווירטואליים וגרסאות מנהלי ההתקנים אינם כלולים במדגם שפורסם. אין להעביר את התוצאה למחשבים פיזיים, ל-builds אחרים או לדרכי הפעלה אחרות ללא בדיקה.
כיצד בוצעה הבדיקה
Section titled “כיצד בוצעה הבדיקה”תחילה תיעדנו את התהליך הפעיל ואת מצב המדיניות ההתחלתי. לאחר מכן החלנו מדיניות אוסרת דרך מנגנון הניהול המקומי של Windows, בדקנו את הצלחת הפעולה וקראנו את המצב בחזרה. לאחר אתחול מחדש המתנו לכניסה אינטראקטיבית ולתחילת עבודת המעטפת, בדקנו תהליכים ואת יומן יצירתם.
לצורך בקרת נגד התרנו את Resume וחזרנו על אתחול מחדש עם כניסה. בנפרד השבתנו שוב את התכונה, סיימנו במפורש את התהליך שכבר פעל וצפינו בהפעלה חוזרת אפשרית. סיום התהליך היה פעולה עצמאית, ואין לייחס אותו למדיניות.
מדוע רישום ב-Registry עדיין אינו מוכיח השבתה
Section titled “מדוע רישום ב-Registry עדיין אינו מוכיח השבתה”נוכחות המספר הנדרש ב-Registry אינה מאשרת ש-Windows קיבלה אותו כמדיניות MDM פעילה. לכן המצב “הערך נרשם, אך CrossDeviceResume עדיין מופעל” אינו סותר את תוצאת מחקר זה.
בתיעוד שפורסם אין התאמה מוכנה של מדיניות זו להגדרת Registry רגילה. בסדרה שלנו אין השוואה מבוקרת נפרדת של כל אפשרויות הרישום הישיר. רישום ישיר לא אושר כתחליף להחלת המדיניות, אך גם אין יסוד לטעון שכל שינוי ב-Registry תמיד חסר תועלת. התוצאה המעשית הושגה דרך מנגנון ניהול המדיניות, עם בדיקת המצב וההפעלה בפועל לאחר הכניסה.
תפקיד ה-DLL המערכתי והעקיפה במעבדה
Section titled “תפקיד ה-DLL המערכתי והעקיפה במעבדה”בניסוי השתמשנו ב-mdmlocalmanagement.dll המובנה. הוא מספק
ממשק ניהול מקומי: RegisterDeviceWithLocalManagement ו-ApplyLocalManagementSyncML. ההצהרות שלהם זמינות ב-
כותרת ציבורית של Windows SDK.
ספריית המערכת קיבלה את הבקשה להחיל את המדיניות; לא היה צורך להוריד DLL
של צד שלישי, להחליף קבצי Windows או לעשות patch לקוד ההרצה.
Intune וניהול בענן לא שימשו בניסוי.
רישום מקומי רגיל על Windows Pro שנבדקה החזיר “לא נתמך”. במעבדה הצלחנו לעבור מגבלה זו באמצעות הפעלה זמנית של Embedded Mode, ולאחר מכן להחיל את המדיניות ולשחזר את פרמטר המצב המקורי. Microsoft מתארת את Embedded Mode בהקשר של התקנים ייעודיים Windows IoT. שימוש כזה ב-Pro אינו תרחיש תמיכה מאושר על ידי Microsoft.
שחזור המצב הזמני לא הסיר את הרישום המקומי של הניהול ואת המדיניות שהוחלה. תופעות לוואי של הפעלה זמנית של המצב מחוץ לתרחיש שנבדק לא נחקרו. כאן מתואר עקרון הניסוי; הפקודות, תוכן הבקשה ורצף השחזור של העקיפה אינם מפורסמים.
תוצאות
Section titled “תוצאות”| בדיקה | תוצאה וגבול המסקנה |
|---|---|
| החלת מדיניות אוסרת | הפעולה הצליחה, קריאה חוזרת אישרה את המצב |
| תהליך שכבר פעל | לא הסתיים אוטומטית |
| אתחול מחדש וכניסה עם איסור | התהליך נעדר; במשך 153 שניות לאחר עליית המעטפת לא נרשמו הפעלות שלו |
| התרה, אתחול מחדש וכניסה | התהליך הופיע, היצירה אושרה ביומן |
| איסור חוזר וסיום נפרד של התהליך | לאחר 10 שניות התהליך נעדר; הפעלה חוזרת במשך 120 שניות תצפית לא התגלתה |
| החזרה מלאה של המתקן | המצב ההתחלתי שוחזר באמצעות snapshot של VM ונבדק |
במדגם מכונת VM אחת ורצף בדיקות אחד. תצפיות חוזרות בתוך מרווח של 120 שניות אינן ניסויים בלתי תלויים. אין שחזור בלתי תלוי במחשב שני.
מה אושר
Section titled “מה אושר”- בתרחיש שנבדק המדיניות מנעה את ההפעלה הרגילה של התהליך הנפרד לאחר אתחול מחדש וכניסה.
- התרה חוזרת של התכונה החזירה את ההפעלה באותו מתקן.
- החלת המדיניות כשלעצמה אינה סוגרת תהליך שכבר פעל.
- לצורך התוצאה שהתקבלה לא נדרשו החלפת DLL מערכתיים או patch ל-EXE.
ההפעלה שנמנעה שוללת את פעולת התהליך הזה בתרחיש הנצפה. זהו אפקט קונקרטי של השבתת פונקציית רקע מיותרת, גם ללא מדידת FPS.
מה לא אושר
Section titled “מה לא אושר”לא נמדדו עלייה ב-FPS, שינוי ב-frametime, עומס CPU כולל וחיסכון ב-RAM.
לא נבדקו הפעלה ידנית של EXE, כל דרכי ההפעלה החלופיות, מיקום
Resume בתוך ShellHost ופעולה מחשבון אחר או מ-SYSTEM.
לא היה ניסוי מזווג נפרד של החלה דרך הממשק המוכן של BoosterX בסדרה
זו: הטבלה מתארת את מנגנון Windows במעבדה.
מגבלות
Section titled “מגבלות”בתאריך הבדיקה Microsoft מסמנת את המדיניות כישימה ל-Windows Insider Preview. תצפית על Windows 11 Pro 25H2 הנקובה אינה מחליפה את מטריצת התמיכה הרשמית. בדיקה על VM אחר שתוכנן לא התקיימה, ולכן אין עבורו תוצאות. היעדר אירועים במשך 153 שניות אינו אומר איסור על כל הפעלה לנצח: האפקט המאושר נוגע להפעלה הרגילה לאחר אתחול מחדש וכניסה, והפעלת התהליך בדרכים אחרות לא נחקרה במחקר זה.
המאמר אינו קובע באיזו דרך BoosterX מחילה את ההגדרה שלה. הקשר בין הכרטיס של BoosterX לבין מדיניות ה-MDM שנבדקה כאן לא היה בתוכנית הניסוי; קביעה אם התוכנה משתמשת באותו מנגנון מחייבת בדיקה נפרדת לפי התנהגות האפליקציה בפועל.
ההשבתה נוגעת ל-Resume. אין לתאר אותה כהשבתה של כל “הקישור לטלפון” או של כל התשתית הבין-מכשירית של Windows.
מסקנה מעשית
Section titled “מסקנה מעשית”אם אינכם משתמשים בהמשך עבודה מהטלפון, השבתת Resume מוצדקת. במתקן שנבדק מדיניות ה-MDM איפשרה להימנע מההפעלה הרגילה שלו. למשתמש פשוט יותר לבחור את ההגדרה הקיימת ב-BoosterX ולאתחל את המחשב, מאשר להתנסות ידנית במאגר המדיניות. בדקו את התוצאה בגרסת Windows שלכם.
שחזור המצב
Section titled “שחזור המצב”בניסוי התרה התכונה ואתחול מחדש נוסף החזירו את הפעלת התהליך. לאחר מכן ה-VM שוחזר במלואו מ-snapshot מקורי: נבדקו היעדר המדיניות שהוחלה במהלך הבדיקה, המצב ההתחלתי של המצב, ביטול הכניסה האוטומטית הזמנית וחזרת התהליך.
ב-BoosterX הפעלה באותו כרטיס מתירה את Resume לאחר ההחלה והאתחול מחדש. זה אינו מקביל מלא להחזרת snapshot: הרישום המקומי של הניהול, שנוצר על ידי החלת המדיניות במעבדה, נשמר, כמו גם מגבלות שהוחלו קודם על ידי כלים אחרים. פרטי ההחזרה מופיעים בעמוד ההגדרה.
מקורות ראשוניים ציבוריים
Section titled “מקורות ראשוניים ציבוריים”- Microsoft: Connectivity / DisableCrossDeviceResume: ייעוד המדיניות, תחום המשתמש ואתחול מחדש; לא הוכחה לתוצאות ה-VM שלנו.
- Microsoft Windows SDK: mdmlocalmanagement.h: הצהרות ממשק הניהול המקומי; לא הבטחה לזמינות בכל מהדורה.
- Microsoft: Embedded Mode: הקשר של Windows IoT; לא הוראה להחלה נתמכת ב-Pro.
המחקר והכלים שבשימוש שייכים למפתח BoosterX, ולכן למפתח יש אינטרס ישיר בתוצאות. המתודולוגיה וגבולות היישום מתוארים לעיל, ואת המסקנות ניתן לבדוק לפי הנתונים הפתוחים והמקורות הציבוריים המפורטים. Microsoft אינה מחברת המחקר ולא אישרה את מסקנותיו.
תאריך הבדיקה והיסטוריית שינויים
Section titled “תאריך הבדיקה והיסטוריית שינויים”2026-09-17: גרסה ראשונה; נבדקו מקורות ציבוריים, פורסמו תוצאות של VM אחת, גבולות המסקנה ובדיקת ההפעלה החוזרת.
2026-09-19: לאחר בדיקה בלתי תלויה תוקנה מסגרת המסקנה: הוסרה הטענה על מנגנון ספציפי של BoosterX. המחקר בודק את מדיניות ה-MDM הציבורית של Windows ואת נתיב ההחלה שלה במעבדה, ולא את מימוש ההגדרה בתוכנה; תוצאות הניסוי, גבולות המסקנה והמקורות נשמרו, והובהרו ההסתייגויות לגבי גבולות האפקט המאושר.
2026-09-20: כתב הוויתור על ניגוד עניינים חוזק: הוכר במפורש האינטרס הישיר של המפתח, שלו שייכים המחקר והכלים; קוצר ה-description.