كيفية تعطيل Cross-Device Resume
على هذه الصفحة
الإجابة المختصرة
Section titled “الإجابة المختصرة”يمكن تعطيل Cross-Device Resume عبر سياسة MDM في Windows. في تجربتنا، بعد تطبيقها وإعادة التشغيل وتسجيل الدخول،
لم يتم تشغيل CrossDeviceResume.exe خلال 153 ثانية من المراقبة.
وعند إعادة تمكين الميزة وإعادة التشغيل مرة أخرى، ظهرت العملية من جديد.
الأسهل هو تطبيق الإعداد عبر BoosterX → التحسين → التويكات → Cross-Device Resume: اختيار التعطيل، الضغط على «تطبيق» وإعادة تشغيل الكمبيوتر. هذه الدراسة اختبرت آلية Windows العامة، وليس تنفيذ BoosterX: كيفية تطبيق البرنامج للإعداد بالتحديد لم تُختبر في هذه السلسلة ولم يُدَّعَ بها في المقال. تفاصيل التطبيق والتراجع موجودة على صفحة الإعداد.
ما الذي تم فحصه
Section titled “ما الذي تم فحصه”لم يكن اهتمامنا مقتصرًا على اختفاء إشعارات Resume، بل أيضًا على منع التشغيل الاعتيادي لعمليته المنفصلة عند تسجيل الدخول إلى Windows. هاتان نتيجتان مختلفتان: فقد تُشغَّل العملية ثم تنتهي فورًا، أو تستمر في العمل دون إشعارات، أو لا تتلقى طلب تشغيل أصلًا.
تصف Microsoft DisableCrossDeviceResume كسياسة مستخدم
تعطّل إشعارات متابعة العمل من الهاتف، وتشير إلى ضرورة
إعادة التشغيل. موثّق: الغرض من السياسة ولحظة تطبيقها.
لوحظ في تجربتنا: غياب تشغيل العملية المنفصلة.
وصف Microsoft.
نطاق الدراسة
Section titled “نطاق الدراسة”| الشرط | البيئة المفحوصة |
|---|---|
| النظام | Windows 11 Pro 25H2، الإصدار 26200.9445 |
| المكوّن | CrossDeviceResume 2607.27000.0.0 |
| المنصة | جهاز افتراضي واحد VMware |
| السيناريو | إعادة التشغيل وتسجيل الدخول التفاعلي لنفس المستخدم |
| المراقبة | قائمة العمليات وتدقيق إنشائها، الأحداث 4688 |
| تاريخ التجربة | 2026-09-17 |
هذه تجربة وظيفية، وليست اختبارًا لـ FPS أو استهلاك الذاكرة. طراز CPU الفيزيائي، وتكوين الموارد الافتراضية وإصدارات التعريفات غير مدرجة في العينة المنشورة. لا يمكن تعميم النتيجة على أجهزة فيزيائية أو إصدارات أخرى أو طرق تشغيل أخرى دون فحص.
كيف أُجري الفحص
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 أو ترقيع الشيفرة التنفيذية.
ولم يُستخدم Intune أو الإدارة السحابية في التجربة.
التسجيل المحلي العادي على Windows Pro المفحوصة أعاد «غير مدعوم». وفي المختبر أمكن تجاوز هذا القيد بتفعيل مؤقت لـ Embedded Mode، ثم تطبيق السياسة واستعادة المعامل الأصلي للوضع. تصف Microsoft Embedded Mode في سياق الأجهزة المتخصصة Windows IoT. وهذا الاستخدام على Pro ليس سيناريو دعم مؤكدًا من Microsoft.
استعادة الوضع المؤقت لم تحذف تسجيل الإدارة المحلي ولا السياسة المعيّنة. ولم تُدرس الآثار الجانبية للتفعيل المؤقت للوضع خارج السيناريو المفحوص. هنا يُوصف مبدأ التجربة؛ أما الأوامر ومحتوى الطلب وتسلسل إعادة إنتاج التجاوز فلا تُنشر.
النتائج
Section titled “النتائج”| الفحص | النتيجة وحد الاستنتاج |
|---|---|
| تطبيق سياسة المنع | العملية ناجحة، والقراءة العكسية أكدت الحالة |
| العملية العاملة بالفعل | لم تنتهِ تلقائيًا |
| إعادة التشغيل وتسجيل الدخول مع المنع | العملية غائبة؛ خلال 153 ثانية بعد بدء الواجهة لم يُسجَّل أي تشغيل لها |
| التمكين وإعادة التشغيل وتسجيل الدخول | ظهرت العملية، وأُكد إنشاؤها بالسجل |
| المنع المتكرر والإنهاء المنفصل للعملية | بعد 10 ثوانٍ كانت العملية غائبة؛ ولم يُكتشف أي إعادة تشغيل خلال 120 ثانية من المراقبة |
| التراجع الكامل عن المنصة | استُعيدت الحالة الأصلية بلقطة VM وفُحصت |
في العينة جهاز افتراضي واحد وتسلسل فحص واحد. والملاحظات المتكررة داخل فاصل 120 ثانية ليست تجارب مستقلة. ولا يوجد إعادة إنتاج مستقلة على حاسوب ثانٍ.
ما الذي تم تأكيده
Section titled “ما الذي تم تأكيده”- في السيناريو المفحوص منعت السياسة التشغيل الاعتيادي للعملية المنفصلة بعد إعادة التشغيل وتسجيل الدخول.
- إعادة تمكين الميزة أعادت التشغيل على المنصة نفسها.
- تطبيق السياسة بحد ذاته لا يغلق عملية عاملة بالفعل.
- النتيجة المحصلة لم تتطلب استبدال مكتبات DLL النظامية أو ترقيع EXE.
التشغيل الممنوع يستبعد عمل هذه العملية في السيناريو المرصود. وهذا تأثير محدد لتعطيل وظيفة خلفية غير ضرورية، حتى دون قياس FPS.
ما الذي لم يتم تأكيده
Section titled “ما الذي لم يتم تأكيده”لم تُقس زيادة FPS، ولا تغير frametime، ولا الحمل الكلي على CPU، ولا توفير RAM.
ولم يُفحص التشغيل اليدوي لـ EXE، ولا جميع طرق التنشيط البديلة، ولا وضع
Resume داخل ShellHost، ولا العمل من حساب آخر أو SYSTEM.
ولم يكن هناك اختبار مزدوج منفصل للتطبيق عبر واجهة BoosterX الجاهزة في هذه
السلسلة: فالجدول يصف آلية Windows المختبري.
القيود
Section titled “القيود”في تاريخ الفحص تصنّف Microsoft السياسة كمنطبقة على Windows Insider Preview. والملاحظة على Windows 11 Pro 25H2 المذكورة لا تحل محل مصفوفة الدعم الرسمية. ولم يجرِ الفحص على جهاز افتراضي آخر كان مخططًا له، لذلك لا توجد نتائج له. وغياب الأحداث خلال 153 ثانية لا يعني منع أي تشغيل إلى الأبد: التأثير المؤكد يتعلق بالتشغيل الاعتيادي بعد إعادة التشغيل وتسجيل الدخول، أما تشغيل العملية بطرق أخرى فلم تدرسه هذه الدراسة.
المقال لا يحدد الطريقة التي يطبّق بها BoosterX إعداده. والعلاقة بين بطاقة BoosterX وسياسة MDM المفحوصة هنا لم تكن ضمن خطة التجربة؛ والحكم على ما إذا كان البرنامج يستخدم الآلية نفسها يتطلب فحصًا منفصلًا وفق السلوك الفعلي للتطبيق.
التعطيل يخص Resume. ولا يجوز وصفه بأنه تعطيل لكامل «الاتصال بالهاتف» أو لكامل البنية التحتية بين الأجهزة في Windows.
الاستنتاج العملي
Section titled “الاستنتاج العملي”إذا كنت لا تستخدم متابعة العمل من الهاتف، فتعطيل Resume مبرر. على المنصة المفحوصة أتاحت سياسة MDM تجنب تشغيله الاعتيادي. وبالنسبة للمستخدم، الأسهل هو اختيار الإعداد الموجود في BoosterX وإعادة تشغيل الكمبيوتر، بدلًا من التجريب اليدوي مع مخزن السياسات. افحص النتيجة على إصدار Windows لديك.
استعادة الحالة
Section titled “استعادة الحالة”في التجربة أعاد تمكين الميزة وإعادة التشغيل تشغيل العملية. ثم استُعيد الجهاز الافتراضي بالكامل من اللقطة الأصلية: فُحص غياب السياسة المعيّنة أثناء الفحص، والحالة الأصلية للوضع، وإلغاء تسجيل الدخول التلقائي المؤقت، وعودة العملية.
في BoosterX، التمكين في البطاقة نفسها يسمح بـ Resume بعد التطبيق وإعادة التشغيل. وهذا ليس مكافئًا كاملًا للتراجع عن لقطة: فتسجيل الإدارة المحلي الذي أنشأه التطبيق المختبري للسياسة يبقى، وكذلك القيود المطبقة سابقًا من أدوات أخرى. تفاصيل التراجع موجودة على صفحة الإعداد.
المصادر الأولية العامة
Section titled “المصادر الأولية العامة”- Microsoft: Connectivity / DisableCrossDeviceResume: الغرض من السياسة، ونطاق المستخدم وإعادة التشغيل؛ وليس دليلًا على نتائج جهازنا الافتراضي.
- Microsoft Windows SDK: mdmlocalmanagement.h: إعلانات واجهة الإدارة المحلية؛ وليس وعدًا بالتوفر على أي إصدار.
- Microsoft: Embedded Mode: سياق Windows IoT؛ وليس دليلًا على تطبيق مدعوم على Pro.
الدراسة والأدوات المستخدمة مملوكة لمطوّر BoosterX، لذلك للمطوّر مصلحة مباشرة في النتائج. وقد وُصفت المنهجية وحدود الانطباق أعلاه، ويمكن التحقق من الاستنتاجات عبر البيانات المفتوحة والمصادر العامة المذكورة. Microsoft ليست مؤلفة الدراسة ولم تؤكد استنتاجاتها.
تاريخ الفحص وسجل التغييرات
Section titled “تاريخ الفحص وسجل التغييرات”2026-09-17: الإصدار الأول؛ فُحصت المصادر العامة، ونُشرت نتائج جهاز افتراضي واحد، وحدود الاستنتاج والفحص العكسي للتشغيل.
2026-09-19: بعد مراجعة مستقلة عُدّل إطار الاستنتاج: أُزيل الادعاء بشأن آلية محددة في BoosterX. فالدراسة تفحص سياسة MDM العامة في Windows والمسار المختبري لتطبيقها، وليس تنفيذ الإعداد في البرنامج؛ وقد حُفظت نتائج التجربة وحدود الاستنتاج والمصادر، ووُضّحت التحفظات بشأن حدود التأثير المؤكد.
2026-09-20: عُزّز إخلاء المسؤولية بشأن تضارب المصالح: أُقرّ صراحةً بالمصلحة المباشرة للمطوّر الذي يملك الدراسة والأدوات؛ واختُصر description.