Sleep से resume पर टूटने वाले apps — Windows power events कैसे काम करते हैं और उनसे बचने वाले business apps कैसे बनाएँ

“मैंने laptop बंद किया, अगली सुबह खोला, और business app errors से भरा था।” “Device-monitoring app केवल दोपहर के बाद data गिराती है।” “Excel में export करने वाला resident tool कभी-कभी connection error पर रुक जाता है।” — इन tickets का एक ही संदिग्ध है। Sleep।

उस युग के business apps जब desktop PC mainstream थे, इस अनकही धारणा पर लिखे गए कि “PC चालू रहता है”। आज का मुख्य युद्धक्षेत्र laptop है, और default पर कुछ minutes idle के बाद वह सो जाता है। Modern Standby-capable machine पर sleep के अर्थ खुद traditional model से बदल गए हैं। Windows पर business apps और device-control software लिखने वाले developers के लिए, यह लेख primary sources से व्यवस्थित करता है कि sleep के पहले और बाद OS app को क्या notify करता है, क्या टूटता है, और resume से बचने वाला app कैसे लिखें।

1. निष्कर्ष पहले

• Sleep वह event है जिसे app को “reject करने का अधिकार नहीं”। ठीक पहले WM_POWERBROADCAST (PBT_APMSUSPEND) से notification मिलती है, पर छूट लगभग 2 seconds है, और emergency suspend पर notification आती ही नहीं।¹²
• Suspend से resume पर PBT_APMRESUMEAUTOMATIC आता है, और user-initiated resume पर PBT_APMRESUMESUSPEND भी आता है। Reconnect जैसे ज़रूरी काम नियमतः पहले वाले पर रखें। Modern Standby के low-power idle में enter और exit इन notifications से हमेशा मेल नहीं खाते, इसलिए notifications को auxiliary मानें।³⁴
• इस धारणा पर design करें कि TCP connections, serial ports, और device handles resume पार नहीं बचते। Resume notification या communication error पर उन्हें दोबारा बनाने वाला reconnect logic मुख्य घटना है।
• Timer और time के सँभाल पर नज़र रखें। Periodic काम sleep के दौरान रुकता है, और resume के तुरंत बाद कैसे fire होता है यह timer API और runtime से भिन्न होता है। “बीते समय में विशाल छलांग” भी होती है, इसलिए सुरक्षित तरीका है resume पर schedule दोबारा बनाना।
• जिन intervals में sleep नहीं चाहिए, sleep स्पष्ट रूप से suppress करें। SetThreadExecutionState (ES_SYSTEM_REQUIRED) या power request (PowerSetRequest) use करें, और काम खत्म होने पर हमेशा clear करें।⁴⁵
• Modern Standby machine पर system sleep के दौरान भी रुक-रुक कर चलता है, पर desktop apps रुके रहते हैं। यह अपेक्षा न रखें कि “हमारा app sleep के दौरान चलता रहे”।⁶
• Standard जाँच tools powercfg (/requests, /lastwake, /sleepstudy) और event log का Kernel-Power हैं।

2. Sleep के आसपास क्या होता है — power event का flow

OS power-state change हर app को WM_POWERBROADCAST message के रूप में broadcast करता है।² Sleep और resume से जुड़े तीन मुख्य events हैं।

PBT_APMSUSPEND sleep से ठीक पहले की notification है, और यहाँ files बंद कर state save कर तैयारी कर सकते हैं। दो शर्तें हैं, पर। पहली, processing के लिए दिया समय per app लगभग 2 seconds है, और यदि आप पार करें तो system wait किए बिना आगे बढ़ता है।¹ दूसरी, critically low battery जैसे emergency suspend पर बिना advance notification के तुरंत सो जाता है।² “Sleep से पहले पूरा करना ही होगा” वाला design टिकता नहीं। Notification को “यदि पहुँच गए तो कर लें” का अवसर मानें, और मुख्य काम resume पक्ष पर रखें।

Resume पक्ष दो चरण हैं। Suspend transition से resume पर PBT_APMRESUMEAUTOMATIC आता है। उसके ऊपर, यदि machine power button या key दबाने जैसी user action से जागी (या बाद में user presence पता चली), तो PBT_APMRESUMESUSPEND आता है। इसके उल्टे, network पर remote wake या maintenance के लिए बिना-presence वाला resume केवल PBT_APMRESUMEAUTOMATIC देता है।³ ये दो चरण खुद काम बाँटने का संकेत हैं — connection दोबारा बनाने जैसी mechanical recovery PBT_APMRESUMEAUTOMATIC पर करें, और screen update या re-login prompt जैसे user-facing काम PBT_APMRESUMESUSPEND पर।

sequenceDiagram
    accTitle: Sleep और resume की notification flow
    accDescr: Sleep से ठीक पहले लगभग 2 seconds की छूट के साथ PBT_APMSUSPEND आता है; resume पर PBT_APMRESUMEAUTOMATIC हमेशा आता है, और PBT_APMRESUMESUSPEND केवल user-initiated resume पर आता है
    participant OS as OS
    participant A as App
    OS->>A: PBT_APMSUSPEND（लगभग 2 seconds की छूट）
    A->>A: State save करें और connection बंद करें
    Note over OS: Sleep（code नहीं चलता）
    OS->>A: PBT_APMRESUMEAUTOMATIC（resume पर आता है）
    A->>A: Reconnect और state restore करें
    OS->>A: PBT_APMRESUMESUSPEND（केवल user-initiated）
    A->>A: Screen update और अन्य user-facing काम

चित्र 1: Notifications केवल “ठीक पहले एक शब्द, और resume के बाद एक या दो शब्द” हैं। Recovery का नायक resume पक्ष का काम है।

flowchart TB
    accTitle: साधारण sleep और emergency suspend का अंतर
    accDescr: साधारण sleep ठीक पहले लगभग 2 seconds की तैयारी के साथ PBT_APMSUSPEND देती है, पर गंभीर battery जैसे emergency suspend बिना advance notification रुक जाता है, इसलिए advance notification पर depend करने वाला design नहीं टिकता
    n2["साधारण sleep"] --> pre["PBT_APMSUSPEND（लगभग 2 seconds छूट）"]
    pre --> s1["तैयारी, फिर रुकना"]
    e2["Emergency suspend（critically low battery）"] --> s2["बिना advance notification रुकना"]
    s2 -.-> l2["Notification आएगी मानने वाला design नहीं टिकता"]

चित्र 2: Emergency suspend बिना warning आता है। इसलिए तैयारी “यदि पहुँच गए तो bonus” है, और मुख्य काम resume पक्ष पर जाता है।

ध्यान दें कि WM_POWERBROADCAST low-power state के प्रकार (sleep बनाम hibernation) में भेद नहीं करता।⁴ App के लिए सही abstraction इसे एक प्रकार का event मानना है: “रुका, और वापस आया”। बिना-window services और console apps callback रूप (DEVICE_NOTIFY_CALLBACK) में RegisterSuspendResumeNotification use कर वही notifications पा सकते हैं।⁷

flowchart TB
    accTitle: दो resume चरणों पर काम बाँटना
    accDescr: Resume पर आने वाले PBT_APMRESUMEAUTOMATIC पर reconnect जैसी mechanical recovery रखें; केवल user-initiated resume पर आने वाले PBT_APMRESUMESUSPEND पर screen update या re-login prompt जैसे user-facing काम रखें
    ra["PBT_APMRESUMEAUTOMATIC（resume पर）"] --> m["Mechanical recovery"]
    rs["PBT_APMRESUMESUSPEND（user-initiated）"] --> u["User-facing काम"]
    m -.-> m1["Reconnect और handle फिर खोलें"]
    u -.-> u1["Screen update और re-login prompt"]

चित्र 3: बिना-presence resume पर बाद वाला नहीं आता, इसलिए ज़रूरी recovery बाद वाले पर रखने से छूट जाएगी।

3. Modern Standby — “Sleep” का अर्थ बदल गया है

आधुनिक तथ्य जो समझना चाहिए वह Modern Standby है। Traditional S3 sleep सरल model था जो “system को समग्र रूप से रोकता था”; Modern Standby machine पर sleep smartphone जैसा model है जिसमें screen बंद होने के बाद system रुक-रुक कर चलता रहता है।

Business apps के लिए यहाँ महत्व यह है कि desktop apps sleep में enter के पहले चरण पर Desktop Activity Moderator (DAM) से रोके जाते हैं।⁶ System खुद network चालू रखने और notifications पाने के लिए समय-समय पर चलता रहता है, पर उससे लाभ पाने वाले components वे हैं जो इस mechanism में भाग लेते हैं — ordinary desktop-app code नहीं चलता। इसलिए developer की दृष्टि से निष्कर्ष Modern Standby और S3 दोनों के लिए एक है — इस धारणा पर design करें कि sleep के दौरान आपका code नहीं चलता।

flowchart TB
    accTitle: Traditional sleep और Modern Standby का अंतर
    accDescr: Traditional S3 sleep पूरे system को रोकता है, जबकि Modern Standby में screen बंद होने के बाद system रुक-रुक कर चलता है। दोनों में desktop apps DAM से रुके रहते हैं, इसलिए app का code नहीं चलता
    s3["Traditional S3 sleep: पूरा system रुकता है"] --> conc["App का code नहीं चलता"]
    ms["Modern Standby: system रुक-रुक कर चलता है"] --> dam["Desktop apps DAM से रुके रहते हैं"]
    dam --> conc

चित्र 4: Model बदल गया है, पर desktop apps के लिए निष्कर्ष एक है: “sleep के दौरान नहीं चल सकते”।

दूसरी सावधानी है notifications पर कितना भरोसा रखें। Modern Standby में low-power idle में enter और exit traditional suspend transition से मेल नहीं खाते, और बिना notification आए connection पहले ही टूट सकता है। Resume notification को auxiliary मानें, और error-detect से चालित reconnect (अध्याय 5) को मुख्य recovery path पर रखें।

दूसरा अंतर behaviour का “फिसलन” एहसास है। Sleep की गहराई तक पहुँचना चरणबद्ध है, और disconnect व रुकने का समय S3 जितना तीखा नहीं। “Screen अभी बंद हुई” और “सो गया” का भेद user को भी दिखना कठिन है, इसलिए लक्षण लेते समय confirm करें “क्या lid बंद किया” और “कितने minutes idle छोड़ा”।

4. क्या टूटता है — classic लक्षण

TCP connection मर चुका है। Sleep के दौरान साथी पक्ष, NAT, और firewall आपकी चुप्पी को timeout मानकर connection त्याग देते हैं। बदतर, इस पक्ष का socket error नहीं जानता, इसलिए वह केवल resume के बाद भेजने या पाने पर fail होता है। या और बदतर, receive-wait कभी error देती ही नहीं (इसीलिए keepalive चाहिए)। Database connection और WebSocket का रूप वही है।

Serial-port और USB-device handles invalid हो जाते हैं। USB-जुड़ा device resume पर ऐसा लग सकता है मानो एक बार “निकाला और फिर लगाया” गया, और जो handle खुला था वह errors लौटाने लगता है। यही device-control app का typical pattern है जो “केवल दोपहर के बाद communication error पाता है”। Reconnect design serial-communication लेख में भी है।

Time की continuity टूटती है। “हर 10 seconds poll करें” जैसा timer-driven काम sleep के दौरान fire नहीं होता। Resume के तुरंत बाद कैसे fire होता है (समाप्त due काम एक बार तुरंत चलता है, अगली अवधि तक कुछ नहीं, आदि) आपके timer API और runtime से भिन्न होता है, इसलिए छूटे tick का सँभाल implicit behaviour पर न छोड़ें — सुरक्षित तरीका है resume notification पर schedule दोबारा बनाना। साथ ही, elapsed-time गणनाएँ (पिछले timestamp से अंतर) अचानक “8 hours जितनी” हो जाती हैं, और average गणना या timeout निर्णय टूटते हैं। “हर रात 2 बजे चलाएँ” जैसा scheduled काम यदि उस समय PC सोया हो तो चलता ही नहीं (यदि चाहिए तो Task Scheduler की sleep-from-wake सुविधा से जगाएँ)।

flowchart TB
    accTitle: Time की continuity टूटने के तीन रूप
    accDescr: Periodic काम sleep में रुकता है और resume-बाद firing API से भिन्न है, इसलिए resume पर schedule दोबारा बनाएँ; पिछले timestamp से अंतर resume बाद विशाल हो जाता है, इसलिए guard लगाएँ; scheduled काम सोए रहने पर नहीं चलता, इसलिए Task Scheduler की sleep-from-wake पर विचार करें
    t1["Periodic काम: रुकता है"] -.-> g1["Schedule दोबारा बनाएँ"]
    t2["Elapsed time: फट जाता है"] -.-> g2["Abnormal अंतर guard करें"]
    t3["Scheduled: चला ही नहीं"] -.-> g3["Sleep-from-wake"]
    g1 ~~~ t2
    g2 ~~~ t3

चित्र 5: Timer और time का सँभाल इस धारणा पर लिखें कि “समय छलांग लगाता है”। तीन रूपों में से प्रत्येक का उपाय-प्रकार है।

flowchart TB
    accTitle: Sleep पार टूटने वाली तीन चीजें
    accDescr: Sleep पार, TCP connection साथी पक्ष के timeout ने त्याग दिया होता है, USB device का handle reconnect के रूप में invalid होता है, और elapsed-time based काम विशाल time-jump देखता है। प्रत्येक को reconnect, फिर खोलना, और अंतर-guard से recover करें
    sleep["Sleep interval"] --> tcp["TCP: साथी ने त्याग दिया"]
    sleep --> more{"USB या elapsed time?"}
    more --> usb["USB: handle invalid"]
    more --> time["Elapsed time: छलांग"]
    tcp -.-> r1["Detect + reconnect"]
    usb -.-> r2["Device फिर खोलें"]
    time -.-> r3["Abnormal अंतर guard करें"]

चित्र 6: जो टूटता है तीन families में पड़ता है — “connection”, “handle”, और “time की continuity” — और प्रत्येक की recovery का प्रकार तय है।

Shared resources पर re-authentication। Network drive और VPN अक्सर resume के बाद फिर स्थापित करने पड़ते हैं, और resume के तुरंत बाद कुछ से कई दस seconds की “startup valley” होती है जिसमें पहुँच fail होती है। Resume के तुरंत बाद सब कुछ एक साथ retry न करना, थोड़ा wait कर चरणों में retry करना अधिक सुरक्षित है।

5. Resume से बचने वाले apps बनाना

सिद्धांत एक बात है। मानें कि “connection और handle sleep पार नहीं बचते”, और app ऐसी structure दें कि हमेशा recover कर सकें।

Resume पकड़ें और recover करें। Top-level window का WM_POWERBROADCAST जब PBT_APMRESUMEAUTOMATIC पाए, तो रखे connections त्यागें और उन्हें दोबारा बनाएँ। बिंदु यह है कि केवल resume notification पर भरोसा न करें। छूटी notifications और notification से पहले होने वाला communication दोनों वास्तविक हैं, इसलिए हमेशा उस path से जोड़ें जो “communication error पता चलने पर reconnect करता है”, और resume notification को केवल वह trigger मानें जो उसे जल्दी शुरू करता है।

// C#: funnel both the resume notification and communication errors into the same reconnect path
protected override void WndProc(ref Message m)
{
    const int WM_POWERBROADCAST = 0x0218;
    const int PBT_APMRESUMEAUTOMATIC = 0x0012;
    if (m.Msg == WM_POWERBROADCAST && (int)m.WParam == PBT_APMRESUMEAUTOMATIC)
    {
        _connectionManager.RequestReconnect();   // idempotent reconnect request
    }
    base.WndProc(ref m);
}

Reconnect काम खुद idempotent बनाएँ (जितनी बार बुलाएँ सुरक्षित), failure पर exponential backoff से retry करें, और स्थिर state में keepalive से मरा connection जल्दी पकड़ें — ये तीन एक set के रूप में लें, तो न केवल sleep से resume, बल्कि संक्षिप्त network गिरावट या device reboot भी बचेंगे।

flowchart TB
    accTitle: Resume-सह reconnect design
    accDescr: Resume notification, communication error, और keepalive failure सभी एक ही idempotent reconnect काम में आते हैं, जो failure पर exponential backoff से retry करता है
    e1["Resume notification（PBT_APMRESUMEAUTOMATIC）"] --> r["Idempotent reconnect काम"]
    e2["Communication-error detect"] --> r
    e3["Keepalive failure"] --> r
    r --> ok{"सफल?"}
    ok -->|"हाँ"| run["Normal operation पर लौटें"]
    ok -->|"नहीं"| back["exponential backoff बाद retry"]
    back --> r

चित्र 7: Reconnect को एक idempotent path में केंद्रित करें, और उसी सड़क पर resume notification, error-detect, या keepalive से प्रवेश करें।

Time के सँभाल पर फिर सोचें। “पिछली बार से बीता समय” use करने वाले काम पर ऐसा guard लगाएँ जो abnormally बड़े अंतर पर interval invalid करे (average में न मिलाएँ, timeout न मानें)। Resume पार elapsed time मापने के लिए sleep के दौरान आगे बढ़ने वाली घड़ी (wall-clock time) और वास्तव में काम पर बिताए समय में भेद रखना पड़ता है।

जिन intervals में sleep नहीं चाहिए, sleep स्पष्ट रूप से suppress करें। Data migration, device से सतत communication आदि — जो काम सोया नहीं जा सकता — के दौरान SetThreadExecutionState(ES_CONTINUOUS | ES_SYSTEM_REQUIRED) से system जगा रख सकते हैं (screen भी चालू रखनी हो तो ES_DISPLAY_REQUIRED जोड़ें)।⁴⁵ अधिक शिष्ट विधि power-request API (PowerCreateRequest + PowerSetRequest) है, जो reason string जोड़ सकती है, और तब powercfg /requests दिखाएगा “कौन रोक रहा है और क्यों”।⁸ ध्यान दें कि SetThreadExecutionState से suppress per thread है, और उसे उसी thread से clear करें जिसने set किया। async/await जैसे काम जो thread बदलते हैं, handle से managed power-request पक्ष use करें। सावधानियाँ हैं। पहली, ये जो suppress करते हैं वह automatic idle sleep है। Lid बंद करना या Start menu से Sleep चुनना जैसी explicit user action नहीं रोक सकते, इसलिए suppress चालू रहते भी इस अध्याय का reconnect design नहीं छोड़ सकते। दूसरी, Modern Standby machine पर battery पर, sleep timeout बीतने के कुछ समय बाद ये power requests भी काट दी जाती हैं। जो काम interrupt नहीं हो सकता उसे AC power या operations से guarantee दें।⁸ तीसरी, काम खत्म होने पर हमेशा clear करें। छूटा clear नया bug बनता है: “यह PC, किसी कारण, सोता नहीं”।

flowchart TB
    accTitle: Sleep suppress करने के दो साधन
    accDescr: चाहे सुविधाजनक SetThreadExecutionState use करें या reason string जोड़ सकने वाली और powercfg से admin को दिखने वाली power-request API, काम खत्म होने पर हमेशा clear करें
    need["वह काम interval जो सोया नहीं जा सकता"] --> a["SetThreadExecutionState"]
    need --> b["Power request（PowerSetRequest）"]
    a -.-> a1["सुविधाजनक — केवल flags"]
    b -.-> b1["Reason सहित — powercfg में दिखता है"]
    a --> off["काम खत्म होने पर हमेशा clear करें"]
    b --> off

चित्र 8: किसी भी साधन के लिए, “खत्म होने पर clear करें” परम शर्त है। Reason दिखा सकने वाली power request operations के लिए दयालु है।

Services और बिना-window apps RegisterSuspendResumeNotification (DEVICE_NOTIFY_CALLBACK) से callback notifications पाते हैं।⁷ यदि सतत operation सच्ची requirement हो, मूल समाधान है सो जाने वाले client PC पर काम resident रखने वाले design पर फिर सोचना, और उसे server पक्ष या बिना-sleep operated machine पर ले जाना।

6. जाँच — powercfg और event log

Power के आसपास की जाँच OS के साथ आने वाले tools से अच्छी चलती है।

• सोता नहीं: powercfg /requests उन processes और drivers की list देता है जिन्होंने power request जारी की। “App SetThreadExecutionState clear करना भूल गया” यहाँ भी दिखता है।
• अपने आप जागता है: powercfg /lastwake सबसे हाल का wake कारण दिखाता है, और powercfg /waketimers अभी machine जगाने के लिए reserved timers दिखाता है।
• Modern Standby quality: powercfg /sleepstudy per sleep interval power consumption और activity की report बनाता है।⁹
• Timeline confirm: Event log (System) का Kernel-Power source sleep में enter और resume के records रखता है। उन्हें app के log से मिलाकर वस्तुनिष्ठ confirm होती है कि “error से ठीक पहले resume था”।

flowchart TB
    accTitle: Power-problem लक्षणों का जाँच command से मेल
    accDescr: सोता-नहीं लक्षण के लिए powercfg /requests से देखें कौन power request पकड़े है; अपने-आप-जागता लक्षण के लिए /lastwake और /waketimers से wake कारण देखें; timeline के लिए event log का Kernel-Power
    s1["सोता नहीं"] --> c1["powercfg /requests"]
    s2["अपने आप जागता है"] --> c2["powercfg /lastwake और /waketimers"]
    s3["Timeline confirm करनी है"] --> c3["Event log का Kernel-Power"]
    c1 -.-> note["भूला sleep-suppress भी दिखता है"]

चित्र 9: लक्षण जाँच commands से तीन families में मेल खाते हैं। पहले confirm करें “क्या अभी सोया”, फिर बाँटें।

Ticket सँभालते समय, पहले यही पूछना कि “क्या PC ठीक पहले सोया था (क्या lid बंद किया)” isolation बहुत तेज़ करता है।

7. सारांश

• Sleep reject नहीं हो सकती। Advance notification (PBT_APMSUSPEND) लगभग 2 seconds की छूट वाला best-effort है, और emergency में नहीं आती। मुख्य design resume पक्ष पर रखें।
• Resume notifications PBT_APMRESUMEAUTOMATIC (suspend से resume पर) + PBT_APMRESUMESUSPEND (user action पर) हैं। Notification न आने की स्थिति के लिए error-driven reconnect मुख्य path पर रखें।
• मानें कि connections और handles resume पार नहीं बचते, और idempotent reconnect + exponential backoff + keepalive का तीन-टुकड़ा set लागू करें।
• Elapsed-time based काम पर “abnormal अंतर” का guard लगाएँ। Scheduled काम इस धारणा पर design करें कि sleep के दौरान नहीं चलता।
• जो interval सोया नहीं जा सकता, SetThreadExecutionState या power request से sleep स्पष्ट suppress करें, और खत्म होने पर हमेशा clear करें।
• जाँच powercfg (/requests, /lastwake, /sleepstudy) और Kernel-Power event log है। Ticket सँभालते समय पहले पूछें “क्या ठीक पहले सोया”।

App की दृष्टि से sleep वह event है जिसमें “समय बिना warning छलांग लगाता है, आसपास के connections कटते हैं, और फिर वापस आता है”। क्या आपने उसे abnormal स्थिति के बजाय रोज़मर्रा के हिस्से के रूप में design में बुना है — यही laptop युग में business apps की स्थिरता बाँटता है।

संबंधित लेख

• Serial communication app की गलतियाँ — reconnect और log design तक
• आपके app की दृष्टि से Windows shutdown — exit notifications, restart, और power हानि सही सँभालना
• Windows Efficiency Mode क्या है? — हरी पत्ती icon और उसे बंद करने का तरीका
• Windows पर Sleep(1) के बजाय Event Wait क्यों चुनें
• “Not Responding” वास्तव में क्या है — Windows app के hang का निर्णय कैसे करता है, और न hang करने वाले apps कैसे design करें

संबंधित परामर्श क्षेत्र

KomuraSoft LLC “sleep से resume के बाद communication टूटता है” और “दोपहर के बाद device से connection गिरता है” जैसे bugs की root-cause जाँच, मौजूदा app पर reconnect logic और power-event सँभाल जोड़ना, तथा laptop operations मानने वाले business apps और device-control software की design review सँभालता है।

• बग और कारणों की जाँच
• Windows app development
• तकनीकी परामर्श और design review
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

संबंधित विषय

ये पृष्ठ विषय को सेवाओं और निर्णयों के व्यापक संदर्भ में रखते हैं।

इस विषय से जुड़ी सेवाएँ

यह लेख निम्नलिखित सेवाओं से सीधे जुड़ा है।

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

क्या app sleep के बारे में पहले से जान सकता है और उसे reject कर सकता है?

वर्तमान Windows पर आप notification पा सकते हैं, पर reject नहीं कर सकते। Sleep से ठीक पहले WM_POWERBROADCAST message PBT_APMSUSPEND event पहुँचाता है, और यहाँ files बंद कर state save कर तैयारी कर सकते हैं, पर processing के लिए दिया समय per app लगभग 2 seconds है, और यदि आप पार करें तो system wait किए बिना आगे बढ़ता है। Critically low battery जैसे emergency suspend पर advance notification खुद नहीं आती। इसलिए "sleep से पहले पूरा करना ही होगा" वाला design टिकता नहीं; ऐसा design चाहिए जो cut जब भी आए, resume पर वापस आ सके। जिस काम के दौरान आप सच में sleep नहीं चाहते, SetThreadExecutionState या power request (PowerSetRequest) से sleep स्पष्ट रूप से suppress करें।

Machine के resume होने का पता कैसे लगाऊँ?

यदि app के पास window हो, तो WM_POWERBROADCAST सँभालें। Suspend से resume पर PBT_APMRESUMEAUTOMATIC आता है, और यदि resume user action (power button या key दबाना) से हुआ हो, तो उसके बाद PBT_APMRESUMESUSPEND आता है। बिना-presence वाला resume जो तुरंत फिर सो जाता है केवल PBT_APMRESUMEAUTOMATIC देता है, इसलिए बुनियादी विभाजन यह है कि reconnect जैसे ज़रूरी काम PBT_APMRESUMEAUTOMATIC पक्ष पर रखें और screen update जैसे user-facing काम PBT_APMRESUMESUSPEND पक्ष पर। बिना-window services और console apps वही notifications DEVICE_NOTIFY_CALLBACK के साथ RegisterSuspendResumeNotification से callback द्वारा पा सकते हैं।

क्या sleep के दौरान app चलता रह सकता है?

नियमतः नहीं। Sleep के दौरान CPU execution खुद रुकता है (Modern Standby machine पर desktop apps Desktop Activity Moderator से रोके जाते हैं), और app का code नहीं चलता। दो विकल्प हैं। एक है काम चलते समय ही sleep suppress करना। SetThreadExecutionState पर ES_SYSTEM_REQUIRED specify करना, या PowerCreateRequest/PowerSetRequest से power request जारी करना, उस interval के लिए automatic idle sleep suppress करता है (powercfg /requests से confirm कर सकते हैं)। वह फिर भी lid बंद करने जैसी explicit sleep action नहीं रोक सकता, इसलिए suppress चालू रहते भी resume की तैयारी चाहिए। दूसरा है sleep स्वीकार कर "resume के बाद पकड़ना" design करना। Night batch जैसे scheduled काम के लिए Task Scheduler के "इस task को चलाने के लिए computer जगाएँ" से PC जगा भी सकते हैं। जो काम सच में continuously चलना चाहिए वह server पर, या बिना-sleep configure service पर, रहता है।

Resume के बाद TCP connections और serial port काम क्यों नहीं करते?

क्योंकि network adapter और USB devices भी sleep के दौरान low-power state में गिरते हैं। TCP connection साथी पक्ष या NAT या firewall timeout ने पहले ही त्याग दिया होता है, और resume के बाद भेजना/पाना error लौटाता है (अक्सर error आने तक पता नहीं चलता)। USB-to-serial adapter आदि resume पर कभी device निकालना और फिर लगाना माने जाते हैं, और जो handle खुला था वह invalid हो जाता है। दोनों के लिए सही धारणा है कि "handle और connection resume पार नहीं बचते", और सही जवाब है resume notification या communication error पर connection दोबारा बनाने वाला reconnect logic लागू करना। Periodic keepalive को failure पर exponential backoff वाले retry से जोड़ना established pattern है।

Unexpected sleep या unexpected resume की जाँच कैसे करें?

powercfg command पहला tool है। "सोता नहीं" दिशा में, powercfg /requests उन processes और drivers की list देता है जिन्होंने sleep रोकने वाली power request जारी की है। "अपने आप जागता है" दिशा में, powercfg /lastwake सबसे हाल का wake कारण दिखाता है और powercfg /waketimers वे timers दिखाता है जो अभी machine जगाने के लिए reserved हैं। Modern Standby machine पर powercfg /sleepstudy sleep के दौरान consumption और activity की report बनाता है। Sleep और resume history event log में भी दर्ज होता है (System log का Kernel-Power source), इसलिए timeline पर confirm कर सकते हैं "कब सोया, और कब और क्यों जागा"।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच में विशेषज्ञ, विशेष रूप से मौजूदा सिस्टम वाली परियोजनाओं और पुनरुत्पादन में कठिन बग में।