السكون والإسبات وModern Standby والتطبيقات طويلة التشغيل ── منع «التوقّف في منتصف الليل» بالتصميم

«كان من المفترض أن يعمل تطبيق المراقبة طوال الليل، لكن عند النظر صباحاً وجدنا الرسم البيانيّ متوقّفاً عند الساعة الواحدة صباحاً» أو «أداة التجميع التي كانت مستقرّة لأشهر على حاسوب مكتبيّ بدأت السجلّات تفقد أجزاءً منها فور استبدالها بحاسوب محمول» ── هذا العرض من أكثر ما يتكرّر في استشارات تطبيقات الأعمال طويلة التشغيل. عند فحص السجلات لا نجد استثناءً ولا انهياراً، بل فقط انقطاعاً كاملاً لسجلّات عدّة ساعات. والمذنب في أغلب الأحيان ليس خللاً في التطبيق، بل إدارة الطاقة في Windows.

والمعضلة أنّ «السكون» ليس نوعاً واحداً رغم أنّه يُذكر ككلمة واحدة. سكون S3 التقليديّ، وحالة الإسبات (S4)، وModern Standby (S0 low power idle) السائد في الحواسيب المحمولة حديثاً، يختلف فيها شكل التوقّف كما يراه التطبيق، كما يختلف مدى فاعليّة سبل التعامل معها. وModern Standby على وجه الخصوص يُساء فهمه غالباً بسبب الترويج له بأنّ «النظام يستمرّ بالعمل حتّى أثناء السكون»، بينما الحقيقة أنّ تطبيقات سطح المكتب تُوقَف فيه بفعّاليّة أكبر.

في هذا المقال نثبت الحدّ الأدنى من أنواع السكون وسلوك التطبيق أثناءه، ثمّ نرتّب كيف نميّز بين ثلاثة تصاميم: «منع السكون»، و«افتراض السكون»، و«الإيقاظ في وقت محدّد»، مع أمثلة تنفيذ وجدول قرار.

1. الخلاصة أوّلاً

الخلاصات كثيرة، فنضعها في ثلاثة: الافتراضات (1.1)، وتصميم «منع» السكون (1.2)، وتصميم «متابعة» السكون (1.3). أقصر طريق أن تقرأ 1.1 ثمّ تقرّر إن كان تطبيقك في جهة 1.2 أو 1.3 قبل متابعة المتن (جدول القرار في الفصل 7).

1.1. الافتراضات ── أنواع السكون، وما يحدث أثناء التوقّف

• في سكون Windows سكون S3 التقليديّ، وحالة الإسبات (S4)، وModern Standby (S0 low power idle)، والأجهزة المتوافقة مع Modern Standby لا تدعم S1 إلى S3. نوع حاسوبك يُعرَف بـ powercfg /a.¹²³
• تطبيقات سطح المكتب لا تواصل العمل أثناء Modern Standby أيضاً. يعلّق DAM (Desktop Activity Moderator) خيوط عمليّات سطح المكتب (خدمات الجلسة 0 تُخفَّض سرعتها). لا تصمّم على افتراض «S0 إذن سيعمل».⁴
• أثناء السكون لا تُنفَّذ الخيوط، وطريقة عدّ أجل المؤقّت تختلف حسب جيل واجهة البرمجة. منذ Windows 8، المؤقّتات والانتظار بالنسبية (SetWaitableTimer بالنسبية، وSleepEx ونحوهما) لا يتقدّم العدّ أثناء السكون، ويُرحَّل الوقت المتبقّي بعد العودة.⁵⁶ مؤقّتات .NET حتّى .NET 10 تنفيذ يعدّ زمن السكون (إن جاء الأجل أثناء السكون تُطلَق فور العودة)، ومن المقرَّر أن تتغيّر من .NET 11 إلى أسلوب لا يعدّ (.NET 11 غير صادر وقت كتابة هذا المقال. انظر حاشية 3.1).⁶ وواجهات قياس الزمن المنقضي أيضاً مختلطة بين ما يشمل زمن السكون (GetTickCount، QueryPerformanceCounter = Stopwatch) وما لا يشمله (QueryUnbiasedInterruptTime).⁷⁸
• اتّصال TCP الذي صار خاملاً أثناء السكون قد يُسقط بصمت بمهلة خمول أجهزة وسيطة مثل NAT وجدار الحماية وموازن التحميل (مثال: افتراضيّ Azure Load Balancer إسقاط بلا إشعار بعد 4 دقائق). صمّم بعد العودة على افتراض إعادة الاتّصال.⁹⁴

1.2. تصميم «منع» السكون (الفصل 4)

• الأسلوب المستقيم لكبح السكون هو SetThreadExecutionState(ES_CONTINUOUS | ES_SYSTEM_REQUIRED). لكنّه يعمل فقط على السكون التلقائيّ الناتج عن مهلة عدم النشاط، ولا يمنع السكون الذي يطلبه المستخدم بزرّ الطاقة أو إغلاق الغطاء. اضبطه في الفترة اللازمة فقط، وامسحه حتماً عند الانتهاء.¹⁰¹¹
• فاعليّة الكبح تُتحقَّق بـ powercfg /requests. واجهات عائلة PowerCreateRequest تسمح بإرفاق سلسلة سبب بالطلب، فتظهر في هذه القائمة وتقوّي تحقيق التشغيل.¹²¹³¹⁴
• إن كان المتطلّب «منع السكون أصلاً» كما في حاسوب جهاز يعمل 24 ساعة، الأصل التعطيل بإعدادات الطاقة لا واجهة كبح التطبيق (مواضع الضبط الملموسة في 7.1).

1.3. تصميم «متابعة» السكون (الفصلان 5 و6)

• إن افترضت السكون، الرصد في .NET عبر SystemEvents.PowerModeChanged، وفي Win32 عبر WM_POWERBROADCAST (PBT_APMSUSPEND / PBT_APMRESUMEAUTOMATIC). مهلة إشعار التعليق نحو ثانيتين لكلّ تطبيق، وقد يحدث سكون بلا إشعار عند ضيق البطاريّة.^15161718
• تطبيقات وحدة التحكّم والخدمات بلا نافذة تستطيع تلقّي الإشعار نفسه بلا HWND عبر PowerRegisterSuspendResumeNotification (مثال أدنى في 5.1).¹⁹
• للتشغيل المضمون في وقت محدّد، الخيار الأوّل هو «إيقاظ الحاسوب من السكون عند تنفيذ المهمّة» (WakeToRun) في جدولة المهام. يُبقي النظام مستيقظاً حتّى اكتمال المهمّة. لكنّه يعتمد على السماح بمؤقّتات الإيقاظ في خيارات الطاقة، لذلك التحقّق من الاستيقاظ على الجهاز الفعليّ إلزاميّ.²⁰²¹

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 19، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

2. سكون Windows ليس نوعاً واحداً

أوّلاً نثبت الحالات الثلاث التي تشكّل افتراض التفكير في المعالجة.

S3 وS4 «حالة يبدو فيها النظام مطفأً، لا ينفّذ أيّ مهمّة حساب».¹ أمّا Modern Standby فأسلوب قريب من نموذج طاقة الهاتف الذكيّ: ينتظر بطاقة منخفضة مع الإبقاء على الاتّصال الشبكيّ والشاشة مطفأة، ويعود في أقلّ من ثانية من زرّ الطاقة. الأجهزة التي تدعم Modern Standby لا تستخدم S1 إلى S3.²²²

المهمّ هنا DAM (Desktop Activity Moderator) المحمول على أجهزة Modern Standby. DAM آليّة تخفض تنفيذ تطبيقات سطح المكتب عند دخول الاستعداد إلى ما يعادل سكون S3: عمليّات الجلسة التفاعليّة تُعلَّق كلّ خيوطها، وخدمات الجلسة 0 تُخفَّض سرعتها (معلَّقة معظم الوقت، وتُنفَّذ على فترات فقط).⁴ أي أنّ توقّع «Modern Standby إذن سيعمل التطبيق أثناء السكون» معكوس: من منظور التطبيق يتوقّف كما في S3، بل بخلاف S3 «النظام نفسه يعمل والتطبيق وحده يتوقّف»، فيظهر كانزياح في الوقت أو عدم اتّساق في سلوك المؤقّت. هذا الفهم الآمن.⁴

نوع حاسوبك (وحاسوب ميدان العميل) يُعرَف بلا صلاحيات مدير بالأمر التالي.³

> powercfg /a
以下のスリープ状態がこのシステムで利用可能です:
    スタンバイ (S0 低電力アイドル) ネットワークに接続されています
    休止状態
    ...

إن ظهر スタンバイ (S3) فالجهاز جهاز S3، وإن ظهر S0 低電力アイドル فجهاز Modern Standby. في استشارة «بعد التحويل إلى حاسوب محمول بدأت السجلّات تفقد أجزاءً»، يُتحقَّق من هذا أوّلاً.

3. ماذا يحدث للتطبيق أثناء السكون وبعد العودة؟

3.1. الخيوط والمؤقّتات

أثناء السكون (S3/S4، وتعليق DAM) لا تُنفَّذ الخيوط.¹⁴ ما يسهل إغفاله هو كيف يعدّ المؤقّت والانتظار «الأجل» لزمن السكون، وهذا ينقسم حسب طبقة واجهة البرمجة. بالشكل نفسه لجدول واجهات الزمن المنقضي في الفصل التالي، يكون كالتالي.

وثيقة تغيير الصفّ الثالث مشروحة كتغيير مدمِّر بسبب تغيّر أساس Environment.TickCount64، والوثيقة نفسها تحذّر من أنّ «قد يوجد شيفرة تتوقّف عن إطلاق المؤقّت فور العودة».⁶

بخصوص ما كُتب عن .NET 11

.NET 11 غير صادر بعد وقت كتابة هذا المقال (يوليو 2026). يتبع .NET دورة إصدار سنويّة في نوفمبر من كلّ عام، وأقرب إصدار .NET 10 صدر في 11 نوفمبر 2025.²⁴ سلوك .NET 11 في هذا المقال مقرَّر استناداً إلى وثيقة تغيير مدمِّر نشرتها Microsoft (معلومات مرحلة معاينة)، فتحقّق حتماً من أحدث الوثائق بعد الإصدار العامّ.⁶

أي أنّ تطبيق «كان يقيس بـ System.Threading.Timer كلّ 10 ثوانٍ ثمّ نام 8 ساعات» لن يطلق 8 ساعات دفعة واحدة على أيّ حال، لكن هل يُطلَق مرّة فور العودة، أم بعد انتظار المتبقّي، يتبع طبقة الواجهة وإصدار زمن التشغيل. وفي الحالتين عيّنات أثناء السكون مفقودة. لا تبنِ إعادة الترتيب على الاعتماد على «إطلاق فور العودة»، بل أعد الجدولة صراحة بحدث العودة في الفصل 5. هذا أأمن.

3.2. قياس الزمن المنقضي ينزاح

واجهات قياس الزمن المنقضي مختلطة بين ما يشمل زمن السكون وما لا يشمله.

شيفرة «بعد 10 ثوانٍ بـ Stopwatch العيّنة التالية» تصير بعد عبور السكون «بعد 8 ساعات و10 ثوانٍ»، وبالمقابل حكم المنقضي على أساس TickCount يتغيّر سلوكه عند الانتقال إلى .NET 11. «الزمن الذي استغرقته المعالجة» بـ Stopwatch، و«وقت الساعة الجدارية الذي ينبغي الحركة عنده تالياً» بـ DateTime/DateTimeOffset، وإعادة أخذ المرجع عند حدث العودة (الفصل 5) ── بهذا التقسيم للأدوار لا تتلاعب بك السكون ولا تحديث زمن التشغيل. حديث تصميم المؤقّت قصير الدورة نفسه في «لماذا يُفضَّل انتظار الأحداث على Sleep(1) في Windows».

3.3. اتّصال TCP يموت «بصمت»

أثناء السكون لا يستطيع التطبيق الاتّصال فيصير الاتّصال خاملاً. المشكلة في أجهزة المسار. الأجهزة الوسيطة مثل NAT وجدار الحماية وموازن التحميل تُسقط التدفّقات الخاملة بمهلة، وفي كثير من التكوينات تُسقط بصمت دون إشعار الطرفين. مثلاً السلوك الافتراضيّ لـ Azure Load Balancer هو «إسقاط التدفّق بصمت عند بلوغ مهلة الخمول (الافتراضيّ 4 دقائق)».⁹ مهلات من النوع نفسه موجودة أيضاً في موجّهات الشركة ومكدّس TCP المضمَّن في جهة الجهاز.

النتيجة أنّ مقبس التطبيق بعد العودة يبدو سليماً ظاهريّاً، ثمّ يخطئ عند الإرسال التالي أو يتجمّد في انتظار الردّ حتّى المهلة. وثائق DAM أيضاً تنصّ على مراعاة أثر تعليق العمليّة في عمر الاتّصال والمصافحة.⁴ وفي أجهزة Modern Standby، عند التشغيل على البطاريّة يتوقّف نشاط الشبكة نفسه أثناء السكون افتراضيّاً (Adaptive Connected Standby).²⁶ القاعدة المتّبعة: عند استقبال حدث العودة، اشترِ في الاتّصال وأتلفه وأعد الاتّصال. تضييق مشكلة «يبدو حيّاً وهو ميّت» أيضاً في «توقّف اتّصال الكاميرا الصناعيّة بسبب إعادة إرسال TCP: السبب والتضييق».

4. «منع» السكون ── SetThreadExecutionState وطلب الطاقة

عندما يكفي أن يُمنَع السكون لساعات القياس فقط، الأسلوب المستقيم هو SetThreadExecutionState. يُستدعى من C# عبر P/Invoke.

using System.Runtime.InteropServices;

internal static class PowerGuard
{
    [Flags]
    private enum EXECUTION_STATE : uint
    {
        ES_CONTINUOUS       = 0x80000000,
        ES_SYSTEM_REQUIRED  = 0x00000001,
        ES_DISPLAY_REQUIRED = 0x00000002,
    }

    [DllImport("kernel32.dll", SetLastError = true)]
    private static extern EXECUTION_STATE SetThreadExecutionState(EXECUTION_STATE esFlags);

    /// <summary>計測開始時に呼ぶ: 自動スリープを抑止する(Endと同じスレッドから呼ぶこと)</summary>
    public static void Begin() =>
        SetThreadExecutionState(EXECUTION_STATE.ES_CONTINUOUS |
                                EXECUTION_STATE.ES_SYSTEM_REQUIRED);

    /// <summary>計測終了時に必ず呼ぶ: 抑止を解除する(Beginと同じスレッドから呼ぶこと)</summary>
    public static void End() =>
        SetThreadExecutionState(EXECUTION_STATE.ES_CONTINUOUS);
}

المواصفات التي ينبغي تثبيتها كالتالي.

• بإضافة ES_CONTINUOUS يستمرّ الأثر إلى أن تُستدعى مرّة أخرى مع ES_CONTINUOUS. بدونها تُصفَّر مؤقّت الخمول مرّة واحدة فقط، فإن أردت الاستمرار يلزم الاستدعاء دوريّاً.¹⁰
• ES_SYSTEM_REQUIRED يكبح سكون النظام، وES_DISPLAY_REQUIRED يكبح إطفاء الشاشة. للقياس في الخلفية يكفي الأوّل. رفع ES_DISPLAY_REQUIRED أيضاً والشاشة يجوز أن تنطفئ هدر طاقة.¹⁰
• لا يُمنَع السكون الناتج عن ضغط المستخدم زرّ الطاقة أو إغلاق الغطاء. هذه الدالّة تعمل فقط على السكون التلقائيّ الناتج عن مهلة عدم النشاط. الوثائق الرسميّة تنصّ أيضاً على وجوب احترام العملية الصريحة للمستخدم.¹⁰
• يعدّ النظام الخيوط التي استدعت SetThreadExecutionState، ويدخل السكون إن صار العدّ صفراً ولم يوجد إدخال مستخدم.¹¹ إن انتهت العمليّة على نحو غير طبيعيّ يزول الكبح أيضاً، فلا خوف من «حاسوب لا ينام أبداً لأنّ الكبح نُسي دون مسح» بعد إعادة التشغيل، لكن بالمقابل هذا ليس ضماناً لمقاومة الانهيار.
• كما يدلّ الاسم، ما تضبطه هذه الدالّة هو حالة تنفيذ الخيط الذي استدعاها.¹⁰ اضبط وامسح من الخيط نفسه. استمرار async/await قد يُنفَّذ على خيط مجمع خيوط آخر، لذلك تنفيذ يستدعي Begin() وEnd() وبينهما await قد يُخطئ المسح على خيط غير الذي رفع كبح السكون، فيبقى الكبح طوال حياة الخيط الأصليّ. الآمن التثبيت على خيط مضمون الهويّة مثل خيط الواجهة، وإن لزم عبور الخيوط فاستخدم واجهة طلب الطاقة القائمة على المقبض المذكورة بعد هذا.

منذ Windows 7 توجد أيضاً واجهة أحدث للغرض نفسه: طلب الطاقة (PowerCreateRequest / PowerSetRequest / PowerClearRequest). ميّزتها العمليّة إمكان تمرير سلسلة سبب عبر REASON_CONTEXT عند إنشاء الطلب، وأنواع الطلب تشمل إلى جانب PowerRequestSystemRequired نوع PowerRequestExecutionRequired الذي يكبح تعليق العمليّة على أجهزة Modern Standby.¹⁴¹³ أفضل الممارسات الرسميّة: «Set قبيل السيناريو، وClear فور الانتهاء، وتنظيف المقبض قبل إنهاء العمليّة».¹³

لكن لأجهزة Modern Standby قيداً مهمّاً. على نظام Modern Standby يعمل بالبطاريّة، تُقطَع طلبات SystemRequired/ExecutionRequired بعد 5 دقائق من تجاوز مهلة السكون. وبصرف النظر عن أسلوب الطاقة، عند دخول السكون بعملية مستخدم (زرّ الطاقة، إغلاق الغطاء، السكون من قائمة ابدأ) ينتهي الطلب.¹³ أي أنّ «الاستمرار في العمل على حاسوب محمول، ولو أُغلق الغطاء، ولو على البطاريّة» لا يتحقّق بجهد التطبيق. ذلك المتطلّب يُضمن بإعدادات الطاقة والتشغيل (إعداد عدم السكون عند إغلاق الغطاء، والتغذية من التيّار المتردّد).

فاعليّة الكبح فعليّاً تُتحقَّق من موجه أوامر بصلاحيات مدير.

> powercfg /requests
SYSTEM:
[PROCESS] \Device\HarddiskVolume3\Apps\SensorLogger.exe

powercfg /requests أمر يعدّد طلبات الطاقة التي تمنع السكون أو إطفاء الشاشة، ويُستخدم لتحقيق «حاسوب لا ينام لسبب ما» وللتحقّق من كبح تطبيقك أيضاً.¹² قراءة الإخراج كالتالي.

• الإخراج مفصول بعناوين حسب نوع الطلب. الأساس DISPLAY (كبح إطفاء الشاشة) وSYSTEM (كبح السكون) وAWAYMODE، ويظهر أيضاً قسم EXECUTION المقابل لـ PowerRequestExecutionRequired. في المثال أعلاه، إن ظهر تطبيقك تحت SYSTEM: فحالة كبح سكون النظام قائمة.¹²¹³
• بادئة الصفوف تحت العنوان [PROCESS] / [SERVICE] / [DRIVER] هي نوع مصدر الطلب. هذا النوع والاسم يُمرَّران كما هما كوسائط إلى powercfg /requestsoverride.¹²
• الأنواع التي لا طلب لها يظهر لها صفّ يفيد بعدم وجود طلب (في بيئة إنجليزيّة None.). عند التحقّق من كبح تطبيقك يكفي النظر إلى ظهور عمليّتك تحت SYSTEM فقط.
• إن أرفقت سلسلة سبب بواجهات عائلة PowerCreateRequest، تظهر تلك السلسلة في هذه القائمة، فيفهم جانب التشغيل «لأجل أيّ معالجة يُكبح».¹⁴¹³

وبالمقابل، اعلم أنّ المسؤول يستطيع إدخال إعداد يتجاهل طلب عمليّة معيّنة عبر powercfg /requestsoverride.¹² افتراض التصميم أنّ واجهة الكبح «طلب» وليست مطلقاً.

أخيراً حديث السلوك الحسن. تنفيذ يرفع ES_CONTINUOUS | ES_SYSTEM_REQUIRED طوال تشغيل التطبيق يعني أنّ تطبيقاً مقيماً يقتل خطّة الطاقة التي ضبطها المستخدم قتلاً دائماً. على الحاسوب المحمول يستنزف البطاريّة، وعلى الحاسوب المشترَك يؤثّر في استعمالات أخرى. المبدأ تضييق الكبح إلى «الفترة التي تجري فيها فعلاً معالجة لا يجوز أن يقطعها السكون» (مثال الوثائق الرسميّة أيضاً «ضبط عند بدء التسجيل، ومسح عند اكتماله»¹⁰). وكوسيلة تجنّب مؤقّتة من جهة المستخدم يوجد PowerToys Awake، وهو أيضاً يعمل داخليّاً بالآليّة نفسها (خيط يطلب حالة التنفيذ).²⁷ يمكن استخدامه أيضاً كخطّ فصل بين تنفيذ الكبح في التطبيق وتركه لأداة تشغيل.

5. «افتراض» السكون ── الرصد وإعادة الاتّصال وتسجيل الفقد

كثير من تطبيقات المراقبة والتجميع المقيمة يصبح تصميم التعايش مع السكون أقوم من منعه. اللازم ثلاث نقاط: «اعرف قبل الدخول»، و«اعرف العودة»، و«أعد الترتيب بعد العودة».

في .NET المدخل Microsoft.Win32.SystemEvents.PowerModeChanged.¹⁵

using Microsoft.Win32;

SystemEvents.PowerModeChanged += OnPowerModeChanged;

private void OnPowerModeChanged(object sender, PowerModeChangedEventArgs e)
{
    switch (e.Mode)
    {
        case PowerModes.Suspend:
            // 猶予は短い: バッファをフラッシュし、計測停止時刻を記録するだけに絞る
            _logger.Info("suspend at {0:O}", DateTimeOffset.Now);
            _collector.Pause();
            break;

        case PowerModes.Resume:
            // 1) 欠測区間をデータとして残す
            _logger.Info("resume at {0:O}", DateTimeOffset.Now);
            // 2) 接続は死んでいる前提で破棄して再接続
            _connection.Reset();
            // 3) 壁時計基準でスケジュールを再計算してタイマーを張り直す
            _scheduler.Rebase(DateTimeOffset.Now);
            // 4) 立て直しが済んでから収集を明示的に再開する(Pauseしたままにしない)
            _collector.Resume();
            break;
    }
}

لهذا الحدث ملاحظتان منصوص عليهما رسميّاً. لا يحدث إن لم تكن مضخّة الرسائل دائرة (في خدمة Windows تلزم نافذة مخفيّة ونحوها)، وحدث static لذلك إهمال إلغاء الاشتراك يسرّب.¹⁵ في تطبيق واجهة يُستخدم بصراحة، أمّا في أداة تجميع من نوع وحدة تحكّم / خدمة فتجهّز بنفسك نافذة رسائل تستقبل WM_POWERBROADCAST في Win32، أو تستخدم PowerRegisterSuspendResumeNotification التي تستقبل ردّ النداء بلا HWND (إشعارات بيئة DAM أيضاً بهذا المسار).⁴¹⁶

5.1. تلقّي العودة في تطبيق بلا نافذة

في تطبيق بلا نافذة مثل أداة تجميع أو خدمة Windows، PowerRegisterSuspendResumeNotification أقلّ جهداً من صنع نافذة رسائل. تحدّد هذه الدالّة DEVICE_NOTIFY_CALLBACK في Flags، وتمرّر في Recipient مؤشّراً إلى DEVICE_NOTIFY_SUBSCRIBE_PARAMETERS يضمّ ردّ النداء والسياق، وعند النجاح تُرجع ERROR_SUCCESS (0). تُستخدم من Windows 8 / Windows Server 2012 فصاعداً.¹⁹²⁸

using System;
using System.Collections.Generic;
using System.Runtime.InteropServices;

// ウィンドウを持たないコンソール/サービスでサスペンド・復帰を受け取る最小例
// メッセージポンプは不要。Windows 8 / Windows Server 2012 以降
internal sealed class SuspendResumeNotifier : IDisposable
{
    private const uint DEVICE_NOTIFY_CALLBACK  = 2;      // powrprof.h
    private const uint PBT_APMSUSPEND          = 0x0004; // winuser.h
    private const uint PBT_APMRESUMEAUTOMATIC  = 0x0012; // winuser.h
    private const uint ERROR_SUCCESS           = 0;

    // ULONG DeviceNotifyCallbackRoutine(PVOID Context, ULONG Type, PVOID Setting)
    private delegate uint DeviceNotifyCallbackRoutine(IntPtr context, uint type, IntPtr setting);

    [StructLayout(LayoutKind.Sequential)]
    private struct DEVICE_NOTIFY_SUBSCRIBE_PARAMETERS
    {
        public IntPtr Callback;
        public IntPtr Context;
    }

    [DllImport("powrprof.dll")]
    private static extern uint PowerRegisterSuspendResumeNotification(
        uint flags,
        ref DEVICE_NOTIFY_SUBSCRIBE_PARAMETERS recipient,
        out IntPtr registrationHandle);

    [DllImport("powrprof.dll")]
    private static extern uint PowerUnregisterSuspendResumeNotification(IntPtr registrationHandle);

    // デリゲートはフィールドで保持する(ローカル変数のままだとGCに回収され、通知時に落ちる)
    private readonly DeviceNotifyCallbackRoutine _callback;
    private IntPtr _registration;

    // 解除に失敗した登録はOS側に残る。そのデリゲートだけはプロセスが終わるまで
    // 生かしておく置き場(下の Dispose を参照)
    private static readonly List<DeviceNotifyCallbackRoutine> AbandonedCallbacks = new();

    public SuspendResumeNotifier()
    {
        _callback = OnPowerNotification;

        var parameters = new DEVICE_NOTIFY_SUBSCRIBE_PARAMETERS
        {
            Callback = Marshal.GetFunctionPointerForDelegate(_callback),
            Context  = IntPtr.Zero,
        };

        uint result = PowerRegisterSuspendResumeNotification(
            DEVICE_NOTIFY_CALLBACK, ref parameters, out _registration);

        if (result != ERROR_SUCCESS)
        {
            throw new InvalidOperationException(
                $"PowerRegisterSuspendResumeNotification failed with {result}.");
        }
    }

    private uint OnPowerNotification(IntPtr context, uint type, IntPtr setting)
    {
        // このメソッドはOS(ネイティブ)から直接呼ばれます。managed の例外を
        // ここから外へ出すと、受け止める呼び出し元が managed 側に居ないため、
        // プロセスごと落ちます。ログの書き込み先が一杯、collector が破棄済み、
        // といった「起こりうる」失敗でスリープのたびにアプリが死ぬので、
        // 中で完結させ、必ずコードを返します
        try
        {
            switch (type)
            {
                case PBT_APMSUSPEND:
                    // 猶予は約2秒。バッファのフラッシュと停止時刻の記録だけに絞る
                    _logger.Info("suspend at {0:O}", DateTimeOffset.Now);
                    _collector.Pause();
                    break;

                case PBT_APMRESUMEAUTOMATIC:
                    // 無人復帰でも必ず届く。重い立て直しはコールバックの外へ逃がす
                    _logger.Info("resume at {0:O}", DateTimeOffset.Now);
                    _recovery.RequestRebuild();
                    break;
            }
        }
        catch (Exception ex)
        {
            // ログ出力そのものが失敗していることもあるので、ここも守る
            try { _logger.Error("power notification failed: {0}", ex); }
            catch { /* ここで投げ直したら、上の try の意味が無くなる */ }
        }

        return ERROR_SUCCESS; // Windowsのエラーコードを返す
    }

    public void Dispose()
    {
        if (_registration == IntPtr.Zero)
        {
            return;
        }

        uint result = PowerUnregisterSuspendResumeNotification(_registration);
        if (result != ERROR_SUCCESS)
        {
            // 解除できていないのにハンドルを捨てると、登録はOS側に生きたまま
            // 追跡できなくなる。そのままこのインスタンスが回収されると _callback も
            // 消え、OSは解放済みの関数ポインターを呼ぶ。次のサスペンドで
            // プロセスごと落ちるので、デリゲートだけは生かしておく
            lock (AbandonedCallbacks)
            {
                AbandonedCallbacks.Add(_callback);
            }

            _logger.Error("PowerUnregisterSuspendResumeNotification failed with {0}.", result);
            return;   // 解除できていない以上、ハンドルは捨てない
        }

        _registration = IntPtr.Zero;
    }
}

ملاحظات التنفيذ ثلاث (مع رابعة لمسار النافذة).

• لا تُخرج الاستثناء خارج ردّ النداء. هذه الدالّة تُستدعى مباشرة من نظام التشغيل، فإن عبر استثناء مُدار الحدود لا يوجد مستدعٍ في الجانب المُدار يلتقطه فتسقط العمليّة كلّها. فشل كتابة السجلّ أو الوصول إلى كائن أُتلف، وهي إخفاقات تحدث فعلاً، تميت التطبيق عند كلّ سكون. أحِط الجسم كلّه بـ try / catch وأرجع رمزاً حتماً.
• يُستدعى ردّ النداء من خيط جهة النظام. مهلة PBT_APMSUSPEND نحو ثانيتين هي نفسها عبر النافذة، فلا تُعد الاتّصال ولا تنظيفاً عبر الشبكة هنا.¹⁷¹⁸ معالجة العودة أيضاً أأمن برفع علامة وتركها لخيط آخر.
• لا تنسَ إلغاء التسجيل. مرّر مقبض التسجيل إلى PowerUnregisterSuspendResumeNotification.²⁹ وانظر قيمة الإرجاع أيضاً. إن رميت مقبض التسجيل دون نجاح الإلغاء، يبقى التسجيل حيّاً في جهة نظام التشغيل وتضيع وسيلة التتبّع فقط. إن استُعيد المثيل في تلك الحالة يزول مفوَّض ردّ النداء أيضاً، فيستدعي نظام التشغيل مؤشّر دالّة محرَّراً.
• إن أردت التلقّي بمقبض نافذة، يوجد أيضاً تمرير DEVICE_NOTIFY_WINDOW_HANDLE إلى RegisterSuspendResumeNotification في user32.dll (هنا يصل WM_POWERBROADCAST كالمعتاد).³⁰

عند البناء كخدمة Windows، يمكن أيضاً ضبط CanHandlePowerEvent في ServiceBase إلى true وتجاوز OnPowerEvent(PowerBroadcastStatus). يصل حدث الطاقة نفسه عبر مدير التحكّم في الخدمات، فتُكتب بلا P/Invoke.³¹

5.2. معنى الأحداث على مستوى Win32

سواء عبر النافذة أو عبر ردّ النداء، معنى الأحداث الواصلة مشترك. ثبّت هذا.

• PBT_APMSUSPEND: إشعار قبيل السكون. المهلة نحو ثانيتين لكلّ تطبيق، وقد يقاطعه النظام عند التجاوز. ما يُفعل هنا يُضيَّق إلى تفريغ وكتابة وقت، ولا تُكتب معالجة تستغرق وقتاً مثل تنظيف عبر الشبكة.¹⁷¹⁸
• PBT_APMRESUMEAUTOMATIC: إشعار يصل حتماً عند كلّ عودة. إعادة الاتّصال وإعادة الجدولة تُكتبان هنا.³²
• PBT_APMRESUMESUSPEND: يصل بعد PBT_APMRESUMEAUTOMATIC عند العودة بعملية مستخدم (أو بعودة المستخدم). لا يصل في العودة الآليّة مثل الإيقاظ عن بُعد، لذلك إن كتبت «معالجة العودة» هنا فقط لا تجري إعادة الترتيب عند العودة بلا مراقب.³³
• وعلاوة على ذلك، في دخول سكون حرج مثل ضيق البطاريّة لا يأتي الإشعار المسبق أصلاً.¹⁸ اكتب جهة Resume متماثلة حتّى تقوم معالجة العودة أيضاً في حالة عدم تلقّي حدث Suspend.

5.3. سجّل الفقد بوصفه فقداً

أمر آخر لا يقلّ أهمّيّة عن معالجة العودة هو تسجيل الفقد بوصفه فقداً. بيانات التجميع التي عبرت السكون ليست «لا قيمة» بل «لم تُقَس لأنّ النظام توقّف»، فإن أبقيت تلك الفترة في السجلّ والبيانات معاً بأوقات suspend/resume، لا يخلط من رأى فراغ الرسم لاحقاً بينها وبين عطل. منظور ما ينبغي إبقاؤه في سجلّ تطبيق طويل التشغيل نعالجه أيضاً في «تحقيق تعطّل الكاميرا الصناعيّة بعد تشغيل طويل: فصل handle leak».

وثمّة أيضاً، كمشكلة شبيهة بالسكون من نوع «انتبهت فإذا هو قد صار بطيئاً»، الكبح بوضع الكفاءة (EcoQoS) في Windows 11. هذا في «ما هو وضع الكفاءة في Windows - معنى أيقونة الورقة الخضراء في Windows 11 وكيفيّة إيقافها».

6. التشغيل المضمون في وقت محدّد ── إيقاظ جدولة المهام

تحقيق معالجة منطلقة من الوقت مثل «تجميع الساعة الثانية ليلاً ثمّ النقل» بمؤقّت تطبيق مقيم + كبح السكون ليس قويم المسار. لأنّه يقتل السكون طوال الليل. هذا الغرض مرشّحه الأساس «إيقاظ الحاسوب من السكون عند تنفيذ المهمّة» (WakeToRun) في جدولة المهام.

المهمّة التي فُعِّل فيها WakeToRun توقظ الحاسوب من السكون أو الإسبات في وقت التنفيذ، وتبقي النظام مستيقظاً حتّى اكتمال المهمّة (إن كان مستيقظاً بالفعل تطلب الإبقاء حتّى الاكتمال أيضاً). قد تبقى الشاشة مطفأة عند الاستيقاظ، وذلك سليم.²⁰

لكن لقيام الاستيقاظ شروطاً. كما تورد إجراءات استكشاف الأخطاء الرسميّة، الافتراض تفعيل «السماح بمؤقّتات الإيقاظ» (Allow Wake Timer) في خيارات الطاقة، وتفعيل إعداد الإيقاظ في جهة BIOS، وفي الحواسيب المحمولة الحديثة ليس نادراً تكوين لا يسمح بالإيقاظ لتصميم توفير الطاقة.²¹ يمكن تعداد مؤقّتات الإيقاظ السارية بـ powercfg /waketimers،¹² لذلك تحقّق حتماً على الجهاز الفعليّ في موضع الإدخال من «هل يستيقظ حقّاً». إن أردت الإيقاظ من تطبيقك، توجد أيضاً وسيلة مؤقّت قابل للإيقاظ بتمرير TRUE إلى fResume في SetWaitableTimer. عندها يبقى النظام مستيقظاً بعد الاستيقاظ الآليّ خلال مؤقّت الخمول بلا مراقب فقط (دقيقتان على الأقلّ)، ويعود سريعاً إلى السكون إن لم يعلن التطبيق «قيد الاستخدام» بـ SetThreadExecutionState. إن طالت المعالجة بعد الاستيقاظ، الجمع الصحيح هو الاقتران بكبح الفصل 4.²³

تصميم تشغيل حساب تنفيذ المهمّة نفسها، ومشكلة الانتهاء بـ 0x1، ومنع التشغيل المتعدّد، مجموع في «لماذا لا تُنفَّذ مهامّ Task Scheduler أو تنتهي بالرمز 0x1 ── تشخيص الأسباب وتصميم تشغيل آمن».

7. جدول القرار ── كبح، أم معالجة عودة، أم إيقاظ؟

التصاميم الثلاثة ليست مانعة، بل تُركَّب بتحديد رئيس وتابع حسب نوع التطبيق.

محورا الحكم اثنان. «هل توجد فترة يجوز التوقّف فيها» (إن وُجدت فجدولة المهام، وإلّا فإعدادات الطاقة) و«على حاسوب من يعمل» (كلّما عمل التطبيق على محمول شخصيّ أو مشترك للمستخدم، مِل إلى معالجة العودة لا الكبح).

7.1. مضمون «تعطيل السكون نفسه بإعدادات الطاقة»

«التعطيل بإعدادات الطاقة» الذي ظهر مرّات في الجدول هو العمليّات التالية. عندما يُوقَف السكون بالتشغيل لا بالتطبيق كما في حاسوب تحكّم أجهزة، لا يُضمن إلّا بعد فعل هذا.

لأجهزة Modern Standby تنبيه إضافيّ. الجهاز المتوافق مع Modern Standby يدخل الاستعداد عندما تنطفئ الشاشة. الوثائق الرسميّة تعدّ من محفّزاته زرّ الطاقة وإغلاق الغطاء والسكون من قائمة ابدأ، إضافة إلى «عندما يخرج النظام بمهلة خمول».³⁵ أي أنّ التفكير بإحساس جهاز S3 «يكفي قطع مهلة السكون فقط» يُبقي مسار الدخول إلى الاستعداد من إطفاء الشاشة. أدخل في الإجراء مراجعة مهلتَي السكون وإطفاء الشاشة كليهما، والتحقّق من الأسلوب بـ powercfg /a، والتأكيد على الجهاز الفعليّ بتركه ليلة أنّه لا يتوقّف.

التعامل عند التشغيل على البطاريّة أيضاً يسهل نسيانه. standby-timeout-ac إعداد وقت التغذية من التيّار المتردّد، وعلى البطاريّة يُستخدم standby-timeout-dc. إن كان حاسوب الجهاز محمولاً، الأمان النصّ على التغذية من التيّار المتردّد كشرط (كما في الفصل 4، على جهاز Modern Standby يعمل بالبطاريّة يُقطع طلب الطاقة نفسه بعد 5 دقائق).¹³

8. الخلاصة

• للسكون S3 والإسبات (S4) وModern Standby (S0 low power idle)، ويُميَّز بـ powercfg /a. حتّى على جهاز Modern Standby تعلّق تطبيقات سطح المكتب بـ DAM، فلا يقوم افتراض «يعمل أثناء السكون».
• أثناء السكون لا تتقدّم الخيوط ولا المؤقّتات. منذ Windows 8 لا تعدّ المؤقّتات النسبيّة والانتظار زمن السكون وترحل المتبقّي، ومؤقّتات .NET أيضاً تصير السلوك نفسه من .NET 11 (حتّى .NET 10 قد تُطلَق فور العودة). واجهات الزمن المنقضي مختلطة بين شامل لزمن السكون وغير شامل. احمل المنقضي بـ Stopwatch والساعة الجدارية بـ DateTime، وأعد أخذ المرجع عند العودة.
• اتّصال TCP يموت بصمت بمهلة خمول الأجهزة الوسيطة. القاعدة إتلافه وإعادة الاتّصال عند حدث العودة.
• الكبح بـ SetThreadExecutionState(ES_CONTINUOUS | ES_SYSTEM_REQUIRED) في الفترة اللازمة فقط. سكون عملية المستخدم لا يُمنَع، وعلى البطاريّة في جهاز Modern Standby يُقطع بعد 5 دقائق. التحقّق بـ powercfg /requests.
• معالجة العودة بـ SystemEvents.PowerModeChanged / WM_POWERBROADCAST. مهلة إشعار التعليق نحو ثانيتين، ويوجد سكون بلا إشعار، فاكتب جهة Resume متماثلة وسجّل فترة الفقد.
• التنفيذ في وقت محدّد مرشّحه WakeToRun في جدولة المهام. صمّم بما فيه إعداد طاقة مؤقّت الإيقاظ والتحقّق من الاستيقاظ على الجهاز الفعليّ.

مقالات ذات صلة

• لماذا لا تُنفَّذ مهامّ Task Scheduler أو تنتهي بالرمز 0x1 ── تشخيص الأسباب وتصميم تشغيل آمن
• لماذا يُفضَّل انتظار الأحداث على Sleep(1) في Windows
• توقّف اتّصال الكاميرا الصناعيّة بسبب إعادة إرسال TCP: السبب والتضييق
• تحقيق تعطّل الكاميرا الصناعيّة بعد تشغيل طويل: فصل handle leak
• ما هو وضع الكفاءة في Windows - معنى أيقونة الورقة الخضراء في Windows 11 وكيفيّة إيقافها

مجالات الاستشارة ذات الصلة

تتولّى شركة كومورا سوفت ذ.م.م. تصميم وتنفيذ تطبيقات Windows طويلة التشغيل مثل القياس والمراقبة وتجميع البيانات، وتحقيق أعطال التشغيل الطويل الخاصّة مثل «توقّف في منتصف الليل» و«السجلّات تفقد أجزاءً». يمكن أيضاً استشارتنا في تضييق أعراض يصعب إعادة إنتاجها تتداخل فيها السكون وإدارة الطاقة.

• تطوير تطبيقات Windows
• تحقيق الأعطال وتحليل الأسباب
• الاستشارة التقنيّة ومراجعة التصميم
• الاتّصال بنا

روابط مرجعية

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

كيف نمنع الحاسوب من الدخول في السكون فقط أثناء تشغيل التطبيق؟

الأساس هو استدعاء SetThreadExecutionState(ES_CONTINUOUS | ES_SYSTEM_REQUIRED) عند بدء المعالجة، ومسحه عبر SetThreadExecutionState(ES_CONTINUOUS) عند انتهائها. إذا أردت إبقاء الشاشة مضاءة أيضاً، أضِف ES_DISPLAY_REQUIRED فقط. يعمل هذا فقط على السكون التلقائيّ الناتج عن مهلة عدم النشاط، ولا يمنع السكون الذي يطلبه المستخدم عبر زرّ الطاقة أو إغلاق الغطاء. يمكن التحقّق من فاعليّة الكبح عبر powercfg /requests.

ما هو Modern Standby؟ وما الفرق عن السكون التقليديّ؟

هو أسلوب سكون جديد يُسمّى أيضاً S0 low power idle، تستمرّ فيه المنظومة بالعمل جزئيّاً بطاقة منخفضة، وتتميّز بالعودة الفوريّة. الأجهزة المتوافقة مع Modern Standby لا تدعم سكون S3 التقليديّ. لكنّ «الاستمرار في العمل» يقتصر على الأنشطة التي يسمح بها نظام التشغيل فقط، إذ يعلّق DAM (Desktop Activity Moderator) خيوط تطبيقات سطح المكتب كلّاً على حدة، فتتوقّف من منظور التطبيق كما في S3 تماماً. يمكن معرفة أيّ الأسلوبين يستخدمه حاسوبك عبر powercfg /a.

لماذا يتعذّر استخدام اتّصال TCP بعد العودة من السكون؟

لأنّ التطبيق لا يستطيع الاتّصال أثناء السكون فيصبح الاتّصال خاملاً، وتقوم الأجهزة الوسيطة على المسار مثل NAT وجدار الحماية وموازن التحميل بإسقاط التدفّق عند بلوغ مهلة الخمول. كثير من هذه الأجهزة تُسقط الاتّصال دون إشعار، فيبقى المقبس في جهة التطبيق يبدو سليماً ظاهريّاً، ولا يظهر الخطأ إلّا عند أوّل إرسال أو استقبال بعد العودة، أو يتجمّد حتّى بلوغ المهلة. القاعدة المتّبعة هي الشكّ في الاتّصال وإعادة إنشائه فور استقبال حدث العودة.

لتشغيل دفعة ليليّة بشكل مضمون، أيّهما أفضل: كبح السكون أم جدولة المهام؟

الخيار الأوّل هو ميزة «إيقاظ الحاسوب من السكون عند تنفيذ المهمّة» (WakeToRun) في جدولة المهام. فهي توقظ الحاسوب في وقت التنفيذ وتبقيه مستيقظاً حتّى اكتمال المهمّة، فلا حاجة لقتل السكون طوال الليل. لكن إذا كان مؤقّت الإيقاظ معطّلاً في خيارات الطاقة، فلن يستيقظ الجهاز، لذا فإنّ ضبط «السماح بمؤقّتات الإيقاظ» والتحقّق الفعليّ من الاستيقاظ على الجهاز أمران ضروريّان. أمّا الكبح الدائم للسكون فيهدر الطاقة طوال تلك الفترة، ويُعدّ تصميماً سيّئ السلوك لأنّه يتجاوز إعدادات الطاقة التي حدّدها المستخدم.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.