🎁 🎠 👕 जांच: विंडोज में थ्रेड प्राथमिकताओं से अधिक क्या है? ✋🏾 😞 🌸

यह जांच, कई अन्य लोगों की तरह, इस तथ्य से शुरू हुई कि मैं अपना खुद का व्यवसाय कर रहा था, अपने लिए समस्याओं की तलाश करने की कोशिश नहीं कर रहा था। इस बार, मैंने जो कुछ किया वह लैपटॉप का ढक्कन खोलकर सिस्टम में लॉग इन करने की कोशिश की।

पहले कुछ समय के लिए, जब बीस सेकंड की देरी हुई, तो मैंने इस समस्या को नजरअंदाज कर दिया, उम्मीद है कि यह खुद ही हल हो जाएगी। अगली बार जब मैंने जांच के बारे में सोचा, लेकिन आपके द्वारा लॉग इन करने से पहले ही उत्पन्न होने वाली प्रदर्शन समस्याएं हल करना अधिक कठिन है, और मैं आलसी था।

जब मैंने देखा कि मैं लैपटॉप बंद करने से बच रहा हूं क्योंकि मैं इन बहुत बार देरी से डरता था, तो मुझे एहसास हुआ कि यह गंभीरता से करने का समय है।

सौभाग्य से, मैंने हाल ही में UIforETW रिंग बफर ट्रेस तय कियाइसे विश्वसनीय बनाते हुए, इसलिए मैंने इसे शुरू किया और अगले विलंब की घटना की प्रतीक्षा करने लगा। मुझे लंबा इंतजार नहीं करना पड़ा।

मेरे साथ ETW ट्रेस पूरी तरह से ठीक होने में मुझे कई बार लगे । और चूंकि यह क्षेत्र मेरे लिए अपरिचित था, इसलिए यह पता लगाने में कुछ समय लगा कि क्या हो रहा है। मैंने अभी भी समस्या को पूरी तरह से नहीं समझा, लेकिन 90% ने इसके होने के कारणों को समझा। मैंने बहुत कुछ सीखने में कामयाबी हासिल की, जिसमें विंडोज शेड्यूलर के बारे में कुछ नए विवरण भी शामिल हैं, और मुझे इसका एक प्रभावी समाधान भी मिला।

Microsoft Windows प्रदर्शन विश्लेषक (WPA) में लोड करते समय मैंने जो आदर्श ट्रेस रिकॉर्ड किया था, वह इस तरह दिखता है:

मानक ईवेंट, फ़ोकस और CPU उपयोग में विंडो।

इस तालिका और दो ग्राफ़ में एक टन जानकारी होती है। शीर्ष तालिका ( जेनेरिक इवेंट्स ) UIforETW के लिए दर्ज कीस्ट्रोक्स दिखाती है। मैंने एक कुंजी (वर्चुअल कुंजी कोड 162) को प्रति सेकंड एक बार दबाने की कोशिश की जब तक कि पासवर्ड इनपुट फ़ील्ड प्रकट न हो। चूंकि इन 17 कीस्ट्रोक्स का चयन किया गया है, इसलिए नीचे दिए गए ग्राफ में उन्हें महत्वपूर्ण घटनाओं के निष्पादन समय के सरलीकृत दृश्य के लिए ऊर्ध्वाधर नीली रेखाओं के साथ दिखाया गया है। एक्स-अक्ष सेकंड में समय का प्रतिनिधित्व करता है।

ऊपरी ग्राफ़ ( विंडो इन फ़ोकस ) में क्षैतिज पट्टियाँ दिखाती हैं कि इस दौरान किस प्रक्रिया पर ध्यान केंद्रित किया गया है। कुल छह अलग-अलग प्रक्रियाएं हैं। ट्रेसिंग ऑफ पीरियड वह छोटा समय होता है जिस दौरान लैपटॉप बंद था।

नीचे का ग्राफ़ CPU उपयोग दिखाता है । संदर्भ स्विचिंग डेटा से जानकारी प्राप्त की जाती है, इसलिए इसे पूरी तरह से सटीक और पूर्ण होना चाहिए। इस ट्रेस में, 100% का मूल्य उस क्षण को इंगित करता है जब मेरे चार-कोर आठ-थ्रेड नोटबुक के सभी आठ तार्किक प्रोसेसर का उपयोग किया गया था।

ट्रेस डेटा प्राप्त करने के बाद, मुझे यह पता लगाना था कि कवर बंद होने पर मेरा लैपटॉप गुप्त रूप से क्या करता है और जब तक मैं सिस्टम में वापस नहीं आता।

पतवार से पहले तूफान

जैसा कि हम देख सकते हैं, लैपटॉप के ट्रेस की शुरुआत में लैपटॉप अपेक्षाकृत सरल है, जैसा कि यह होना चाहिए। फिर मैंने उसका ढक्कन बंद कर दिया। ऐसा लगता है कि सीपीयू गतिविधि में स्पाइक और खिड़कियों के फोकस में बदलाव हुआ है। फ़ोकस में विंडो UIforETW से बदलकर Idle, फिर csrss, वापस Idle, LogonUI में, और फिर वापस Idle में बदल गया। किसने सोचा होगा?

इस अंतराल के दौरान, लैपटॉप ने लगभग 17 सेकंड विभिन्न प्रकार के सीपीयू प्रसंस्करण का प्रदर्शन किया। इसका एक हिस्सा काम बंद करने की आवश्यकता है। भाग - ये प्रोग्राम हैं (आंतरिक Google टूल सहित) जो "जब कोई उपयोगकर्ता किसी कार्य केंद्र को बंद करता है" के निष्पादन के लिए टास्क शेड्यूलर में पंजीकृत होता है - तो यह समझ में आता है। मैंने यह भी देखा कि जब उपयोगकर्ता काम करना जारी रखता है तो लॉग इन करने के लिए UI तत्वों को बनाने के लिए काम किया जा रहा है - आपको अग्रिम में तैयार होने की आवश्यकता है, है ना?

सीपीयू के 17 सेकंड - लैपटॉप को सोने के लिए काफी लंबा समय। यहां तक कि चार कोर और आठ धागे वाले मेरे लैपटॉप पर, प्रक्रिया को चार सेकंड से अधिक समय लगता है। मेरे होम लैपटॉप पर, सीपीयू के 13 सेकंड से अधिक समय सो जाता है, और उनमें से लगभग सभी विंडोज कोड पर जाते हैं। क्या लैपटॉप को आराम करने से पहले डायग्नोस्टिक पॉलिसी सेवा को वास्तव में SruDbTableSearches के एक जोड़े को चलाने की आवश्यकता है?

मुझे लगता है कि सोते समय यह अत्यधिक काम करना भी एक समस्या है, लेकिन यह वह समस्या नहीं है जिसकी मुझे तलाश है। इसलिए मैंने सिर्फ अपनी पीठ उसकी तरफ मोड़ने का फैसला किया।

और केवल बहुत बाद में मुझे एहसास हुआ कि यह इस समय के दौरान था कि मेरे बग के विनाश के अनाज फेंक दिए गए थे ...

नींद

लैपटॉप को ब्लॉक करने के बाद, कोई सीपीयू गतिविधि नहीं है। इस विशेष परीक्षण में, लैपटॉप को लगभग 16 सेकंड के लिए बंद कर दिया गया था।

आकुल जागरण

सोने के लिए संक्रमण पर सीपीयू की गतिविधि अतुलनीय है जब वह जागना शुरू हुआ। इस समय के दौरान, मेरे अतिभारित लैपटॉप ने 22.6 सेकंड के लिए लगभग 172 सेकंड का सीपीयू समय (!!!) लिया। यह बहुत काम की चीज है।

इस प्रक्रिया के रहस्यों में से एक गतिविधि के प्रारंभिक प्रकोप के बाद लगभग एक सेकंड के लिए सीपीयू उपयोग में गिरावट है। डाउनटाइम की यह छोटी अवधि असामान्य लगती है, जिसे देखते हुए आस-पास अव्यवस्था हो जाती है। लेकिन मुझे लगता है कि यह सुविधा समस्या से संबंधित नहीं है, इसलिए मैंने इस पर ध्यान नहीं दिया।

एक और रहस्य है कि इतने सारे क्यों हैंइस संक्षिप्त ठहराव के बाद जीवन में कार्यक्रम आते हैं। यह अजीब बात है कि सीपीयू के 172 सेकंड में से 31.6 के लिए जिम्मेदार सबसे गंभीर घुसपैठिया विंडोज प्रदर्शन विश्लेषक (डब्ल्यूपीए) था - बहुत ही प्रोग्राम जो मैं निशान का विश्लेषण करने के लिए उपयोग करता हूं। मेरे द्वारा छोड़ी गई तीन प्रतियाँ मेरे UI को रेंडर करने पर कड़ी मेहनत कर रही हैं, भले ही यह अभी तक दिखाई नहीं दे रही है।

इसके अलावा, लैपटॉप डिवाइस को इनिशियलाइज़ करने की कोशिश करते समय डार्क पैटर्न होते हैं। KeStallExecutionProcessor एक वेटिंग लूप है, और यह देखना अजीब था कि यह पूरे सिस्टम का सबसे निष्पादन योग्य कार्य है। क्या एक दूसरा-अजीब प्रतीक्षा उपकरण शुरू करने का एकमात्र तरीका है? क्या माउस और कीबोर्ड को इनिशियलाइज़ करने के लिए 700 ms CPU समय बिताना वास्तव में आवश्यक है ? क्या Microsoft और Intel को Microsoft की अनुशंसा पर ध्यान नहीं देना चाहिएअधिकतम 50 माइक्रोसेकंड ?

एक प्रतीक्षा चक्र के ड्राइवर। i8042prt.sys Microsoft द्वारा लिखा गया है। निम्नलिखित दो इंटेल द्वारा बनाए गए हैं।

अंततः, इस दौरान कई कार्यक्रम सक्रिय रूप से चल रहे हैं। उनमें से अधिकांश को WPA जैसी ही समस्या का सामना करना पड़ रहा है - वे एक छिपे हुए स्क्रीन पर पिक्सेल खींचने के लिए बेताब हैं, और यह एक विंडोज बग के लिए दृष्टिकोण करता है। लेकिन इस बग एक्सप्लोरर के बिना भी। Exe और अन्य प्रोग्राम सक्रिय रूप से कुछ करना चाहते हैं। लेकिन अंत में, हालांकि यह अत्यधिक सीपीयू उपयोग समस्या का एक आवश्यक हिस्सा है, यह स्वयं समस्या नहीं है । इसलिए फिर से मैंने उसकी तरफ ध्यान देना बंद कर दिया।

फोकस

निशानों का विश्लेषण करते समय, यह पता लगाना महत्वपूर्ण है कि महत्वपूर्ण क्रियाएं कब होती हैं। मुख्य सबूत इनपुट इवेंट था, क्योंकि मैंने पासवर्ड इनपुट फॉर्म दिखाई देने के बाद नियंत्रण पर क्लिक करना बंद कर दिया था। यहां विंडो के फ़ोकस चार्ट में अनुमानित रूप से नियंत्रण कुंजी के अंतिम तीन कीस्ट्रोक्स हैं :

ऐसा लगता है कि महत्वपूर्ण घटनाओं में LockApp.exe का फ़ोकस हो रहा है, जिसके बाद फ़ोकस LogonUI.exe को लगभग तुरंत प्राप्त करता है। संभवतया, मैंने लॉगऑनयूई। Exe में पासवर्ड डाला (यह सुविधाजनक है कि ट्रेस कीबोर्ड की घटनाओं को रोक नहीं पाया), जिसके बाद फ़ोकस संक्षेप में एक्सप्लोरर में बदल गया, और फिर UIforETW पर, जहाँ से मैंने शुरू किया।

यह भी लगता है कि LockApp.exe से पहले LogonUI.exe को फ़ोकस नहीं किया जा सकता है - यह पैटर्न मेरे द्वारा अध्ययन किए गए सभी निशानों में खुद को दोहराता है।

इसलिए, इस पहेली को हल करने के लिए समर्पित एक हजार से अधिक शब्दों के बाद, हमारे पास अंत में एक स्पष्ट सवाल है कि हम जांच कर सकते हैं: डाउनटाइम से बाहर निकलने के बाद LockApp.exe पर ध्यान क्यों जाता है, इसमें बीस सेकंड लगते हैं?

हमारे पास एक सवाल है? महान, इसका जवाब दें

सामग्री स्विचिंग से प्राप्त सीपीयू उपयोग (सटीक) डेटा का उपयोग करते हुए, मैंने जल्दी से पाया कि जागने के बाद बीस सेकंड के भीतर लॉकएप ने सीपीयू समय के एक मिलीसेकंड से कम प्राप्त किया, और 14 सेकंड से अधिक (35.158 एस से 49.827 सेकंड तक) काम नहीं किया। आम तौर पर:

LockApp लंबे समय तक काम नहीं करता है

CPU उपयोग (सटीक) तालिकाओं में कॉलम के अर्थ पर प्रलेखन यहाँ है ।

यदि कोई प्रक्रिया या धागा कुछ समय से नहीं चल रहा है, और आप यह जानना चाहते हैं कि क्यों, आमतौर पर महत्वपूर्ण सुराग पहले संदर्भ स्विच में एक लम्बी ढलान के बाद पाया जा सकता है, जिसका अर्थ है अनुरेखण के 49.827 सेकंड। मैंने इस संदर्भ स्विच से अधिक डेटा दिखाने के लिए स्तंभों को पुन: व्यवस्थित किया:

LockApp तैयार है लेकिन निष्पादित नहीं किया गया है। अजीब ...

गणना, 1 के बराबर का मतलब है कि हम एक एकल संदर्भ स्विच के लिए डेटा को देखते हैं।

अंतिम समय से 38.2 मिलियन माइक्रोसेकंड के बराबर समय का मतलब है कि यह धागा 38.2 सेकंड के भीतर निष्पादित नहीं करेगा। यह अपने आप में अच्छा या बुरा नहीं है। निष्क्रिय प्रवाह ऊर्जा बचाने के लिए, और अंत में लैपटॉप कुछ समय के लिए एक सपने में था।

स्विच-इन टाइम बस हमें बताता है कि वास्तव में थ्रेड सीपीयू में फिट बैठता है - जब संदर्भ उस थ्रेड पर स्विच करता है।

और अब हम तैयार कॉलम पर जाते हैं। वह हमें बताता है कि थ्रेड कब तक निष्पादित करने के लिए तैयार था , लेकिन निष्पादित नहीं हुआ। दूसरे शब्दों में, यह धागा कुछ (लॉक, हैंडल) की प्रतीक्षा कर रहा था और यह कुछ हैमुक्त या आरंभ किया गया था, लेकिन धागा अभी भी 19.493 सेकंड तक नहीं चला । रेडी (हमें)

कॉलम को बेहतर ढंग से समझने के लिए , आप रेडी टाइम (एस) कॉलम पर एक नज़र डाल सकते हैं । वह हमें बताता है कि धारा कब तैयार होती है। हम देखते हैं कि ट्रेसिंग के 30.333 सेकंड के लिए, यह धागा निष्पादन के लिए तैयार किया गया था, लेकिन 49.827 सेकंड तक निष्पादित नहीं किया गया था। यह महत्वपूर्ण प्रतीत होता है। स्तंभों की यह व्यवस्था अन्यथा हमें एक ही संदर्भ स्विच दिखाती है:

नई थ्रेड स्टैक और रेडी थ्रेड स्टैक

तो, इस थ्रेड (जो कि न्यू थ्रेड स्टैक ने उम्मीद की थी कि NtWaitForWorkViaWorkerFactory शो होगा) को जागने का आदेश दिया गया था (सिस्टम प्रक्रिया को Keetetvent कहते हुए) शीघ्र ही मैंने ट्रेसिंग के 30.333 सेकंड के लिए नोटबुक ढक्कन खोला। लेकिन यह तब शुरू नहीं हुआ (जो "अच्छा" होगा), लेकिन 19.494 के बाद, और यह खराब है।

आमतौर पर, जब मैं अपेक्षाओं का ऐसा विश्लेषण करता हूं, तो मुझे यह पता लगाने में बहुत समय लगता है कि धारा क्यों इंतजार कर रही है और किस कारण से यह तैयार नहीं हुई। लेकिन यह पहली बार था जब मैं उम्मीदों का विश्लेषण कर रहा था, जिसमें यह महत्वपूर्ण नहीं था, और सवाल यह था कि इस तैयार धागे को निष्पादित क्यों नहीं किया गया।

मामले ...

ज्यादातर लोग ETW निशान का अध्ययन करने में इतना समय नहीं लगाते हैं, इसलिए यहां स्पष्टीकरण की आवश्यकता है। यह बहुत अजीब है। यदि धागा तैयार है, तो यह आमतौर पर तुरंत शुरू होता है, या कुछ मिलीसेकंड के बाद। धारा की तत्परता, जैसा कि नाम से पता चलता है , का अर्थ है कि धारा निष्पादन के लिए तैयार है और लगभग कुछ भी इसमें हस्तक्षेप नहीं कर सकता है। लेकिन आइए जानें कि समाप्त धागे के निष्पादन को क्या रोका जा सकता है।

थ्रेड प्राथमिकता

सबसे पहले मैंने सुझाव दिया कि यह सीपीयू "भूख" का एक सरल मामला है। दर्जनों प्रक्रियाओं के लिए सीपीयू समय की आवश्यकता होती है, और इस वजह से, लॉकएप को लोड कम होने तक सही एक नहीं मिलता है। हालांकि, यह सिद्धांत लक्षणों के अनुरूप नहीं है , क्योंकि लॉकअप प्रक्रिया को सीपीयू के समय के बिना भी लगभग 18 सेकंड लग सकते हैं ।

सीपीयू भूख सिद्धांत अच्छा है क्योंकि यह सत्यापन योग्य है। मैं टास्क मैनेजर (यूडब्ल्यूपी प्रणाली द्वारा निलंबित नहीं किए जाने के दौरान संक्षिप्त समय में से एक के दौरान) लॉकएप प्रक्रिया की प्राथमिकता को बढ़ाने में सक्षम था, इसलिए, अंतिम ट्रेस में जो मैंने इस पोस्ट के लिए उपयोग किया था, लॉकअप को उच्च प्राथमिकता के साथ निष्पादित किया गया था। एक नियमित विंडोज थ्रेड लगभग 8-10 की प्राथमिकता के साथ चलता है। सर्वोच्च प्राथमिकता जिसके साथ एक नियमित (गैर-वास्तविक समय) विंडोज थ्रेड चल सकता है। 15. मेरे ईटीडब्ल्यू निशान से पता चला है कि लॉकएप ने हमेशा प्राथमिकता 13 या उच्चतर के साथ काम किया।

यहाँ महत्वपूर्ण 19.494 सेकंड के लिए सीपीयू समयरेखा, थ्रेड की प्राथमिकता के आधार पर समूहीकृत और रंगीन ( न्यू इन प्री) हैवर्तमान प्राथमिकता जो थ्रेड को सौंपी गई थी)। हम देखते हैं कि प्राथमिकताएँ 4, 8, 9 और 10 के साथ थ्रेड्स सीपीयू समय के विशाल बहुमत का उपभोग करते हैं, विशेष रूप से अंत में:

प्राथमिकता के आधार पर सीपीयू का उपयोग करना

यहां प्राथमिकताओं के साथ छिपे हुए धागे के साथ एक और छवि है 0-12। हर बार ग्राफ 12.5% से नीचे चला जाता है (जिसका अर्थ है कि मेरे आठ-थ्रेड नोटबुक के CPU समय का एक तार्किक प्रोसेसर), LockApp को लॉन्च किया जाना चाहिए, और यह बिल्कुल अविश्वसनीय हो जाता है कि प्राथमिकता इसे इतनी बार निष्पादित होने से रोकती है जब कई थ्रेड कम या बराबर प्राथमिकता से होते हैं। एक टन समय मिलता है।

प्राथमिकता CPU उपयोग, केवल उच्च प्राथमिकता वाले धागे

प्राथमिकता उलटा हटा दें

अटकलें हैं कि विंडोज प्राथमिकता उलटा एल्गोरिदम अन्य थ्रेड्स के लिए इतना अनुकूल है कि LockApp.exe अवरुद्ध है। लेकिन चूंकि ऊपर दिखाए गए ग्राफ़ यह दर्शाते हैं कि नियोजन निर्णयों में सच्ची प्राथमिकताओं का उपयोग किया जाता है, इसलिए इस धारणा (हमेशा असंबद्ध) को छोड़ना होगा।

स्टैक कोर उतराई

जब मैंने ट्विटर पर इस पहेली के बारे में बात की, तो टिप्पणीकारों में से एक ने सुझाव दिया कि थ्रेड कोर स्टैक उतार दिया गया था । मैं इस स्थिति से परिचित नहीं था, लेकिन जॉन वर्थ के स्पष्टीकरण (वह अपने क्षेत्र में समझता है) के बाद मैंने कर्नेल स्टैक की अदला-बदली को बंद कर दिया और कंप्यूटर को रिबूट किया। कुछ नहीं बदला। वास्तव में, मैंने नहीं सोचा था कि यह मदद करेगा, यह देखते हुए कि मेरे पास 32 जीबी मेमोरी है, और समस्या बार-बार और अक्सर होती है; लेकिन यह सुनिश्चित होना बेहतर था।

प्रक्रिया को रोकें

चूंकि LockApp एक आधुनिक UWP एप्लिकेशन है, यह स्मार्टफोन ऐप के समान प्रतिबंधों के अधीन है। अन्य बातों के अलावा, इसका मतलब यह है कि अग्रभूमि में न होने पर इसे निलंबित किया जा सकता है, और फिर अग्रभूमि में वापस आने पर "अनफ़्रीज़" किया जा सकता है। जेम्स फ़ोरशॉ ने इस पर डेटा प्राप्त करने के लिए माइक्रोसॉफ्ट-विंडोज-कर्नेल-प्रोसेस ईटीडब्ल्यू की रिकॉर्डिंग का प्रस्ताव दिया ।

घटनाओं को अधिकतम भ्रम पैदा करने के लिए डिज़ाइन किया गया है। टास्क प्रोसेस फ्रीज का नाम "डीफ्रॉस्टिंग" और "फ्रीजिंग" दोनों के लिए उपयोग किया जाता है, और जीत का संस्करण : स्टॉप इवेंट का मतलब है कि प्रक्रिया शुरू हो रही है (यह ठंड रुक गई है), और जीत का संस्करण : प्रारंभइसका मतलब है कि प्रक्रिया रुक जाती है (जमने लगती है)। यह सब बेहद तार्किक है, लेकिन बहुत भ्रामक है। यदि घटना के नाम फ्रीज और थाव में विभाजित किए गए थे, तो कम भ्रम होगा।

इन घटनाओं के लिए कोई दस्तावेज नहीं है, लेकिन विश्लेषण के लिए धन्यवाद, मैंने निर्धारित किया कि ये घटनाएं हमेशा पृष्ठभूमि कार्य / ब्रोकर अवसंरचना सेवा द्वारा बनाई जाती हैं । संबंधित प्रक्रिया का नाम और प्रोसेस आईडी फ्रोजेनप्रोसेस फील्ड में इंगित की गई है।

प्रोसेसफ्रीज इवेंट्स (डिफ्रॉस्टिंग के लिए भी इस्तेमाल किया जाता है)

इस प्रदाता की जांच करना दिलचस्प था - इसमें कई आशाजनक घटनाएं हैं - लेकिन अंत में यह पता चला कि लॉकएप ने ट्रेसिंग के दौरान विराम या डीफ्रॉस्ट नहीं किया। हालांकि, यह प्रदाता काफी उपयोगी लग रहा था, इसलिए मैंने UIforETW को संशोधित किया ताकि भविष्य के संस्करणों ने हमेशा इसे लिखा।

हमने पहले ही सब कुछ खारिज कर दिया है

ऊपर वर्णित सिद्धांतों में से कोई भी मुझे बहुत संभावना नहीं लग रहा था, और अब हम सभी ने उन्हें बाहर कर दिया है। मैंने मदद के लिए देखना शुरू किया, और मुझे Microsoft के एक मित्र से विचार देने के लिए कहा। और उस क्षण मुझे पता चला कि विंडोज में अच्छी तरह से ज्ञात 0-31 प्रवाह प्राथमिकता वास्तव में एक पूर्ण प्राथमिकता प्रणाली के सिर्फ पांच कम प्राथमिकता वाले बिट्स हैं ।

आधिकारिक पद का उपयोग

यह पता चला कि मेरी अज्ञानता मेरी अपनी गलती थी। यदि मैं विंडोज इंटर्ल्स, 7 वें संस्करण, भाग 1 के थ्रेड्स अनुभाग के सभी 108 पृष्ठों को ध्यान से पढ़ता हूं, तो मैं समझूंगा कि क्या हो रहा था। यदि आप आगे कूदना चाहते हैं, तो यह विषय 287 से 295 पृष्ठों पर प्रकट होता है । यह सुपर-प्राथमिकता वाला क्षेत्र जिसके बारे में मुझे नहीं पता था कि रैंक कहा जाता है । यह WPA में एक डिफ़ॉल्ट छिपे हुए कॉलम के रूप में दिखाई देता है (इसे खोजने के लिए, आपको NewThreadRank नामक View Editor को खोलना होगा) । थ्रेड्स की योजना बनाते समय, थ्रेड रैंक प्राथमिकता से अधिक है। लगभग सभी धाराओं में रैंक 0 है, और रैंक 0 के साथ एक स्ट्रीम हमेशा रैंक 2 के साथ एक स्ट्रीम की तुलना में एक उच्च प्राथमिकता है। एक कॉलम को शामिल करके

NewThreadRank और तालिका के बाईं ओर देखते हुए, हम तुरंत समस्या देख सकते हैं:

वरीयता की तुलना में रैंक अधिक महत्वपूर्ण है

। LockApp.exe स्ट्रीम में रैंक 2 है, जिसका अर्थ है कि प्राथमिकता 14 के बावजूद, सिस्टम में उनकी सबसे कम प्राथमिकता है।

एक लगभग पूरा विवरण

चूंकि यह पता चला है कि LockApp.exe थ्रेड्स की रैंक 2 है, उन्हें केवल तब निष्पादित किया जा सकता है जब रैंकों 0 में से कोई भी थ्रेड "चलाना" न हो। चूंकि कई एप्लिकेशन (अज्ञात कारणों से) अपनी अदृश्य स्क्रीन को सक्रिय रूप से प्रस्तुत करते हैं, वे सीपीयू समय के हर टुकड़े के लिए लड़ते हैं, उच्च रैंक के लिए कुछ भी नहीं छोड़ते हैं। एक बार LockApp.exe CPU समय का एक छोटा सा अंश प्राप्त करता है, यह जल्दी से 0 रैंक (और CPU लोड ड्रॉप्स) में चला जाता है, जिसके बाद लॉगिन प्रक्रिया सामान्य तरीके से की जाती है।

इस जानकारी को जानने के बाद, मैंने अध्ययन करना शुरू किया कि लॉकअप की रैंक समय के साथ कैसे बदलती है। पिछले कुछ सेकंड में, लॉकएप अचानक सोने से पहले रैंक 0 से 2 तक चला गया। रैंक को सीपीयू को बहुत अधिक समय तक रोकने के लिए डिज़ाइन किया गया है, जैसे कि जब विंडोज फोटो अवांछित पृष्ठभूमि प्रसंस्करण के लिए उत्सुक है और संक्रमण करता है। रैंक 2 से 19:

Microsoft.Photos रैंक नीचे जाता है।

प्रलेखन से आप समझ सकते हैं कि स्ट्रीम रैंक का मुख्य उद्देश्य मशीन पर सत्रों के बीच सीपीयू समय का उचित साझाकरण है ताकि एक उपयोगकर्ता की प्रक्रिया दूसरों को नुकसान न पहुंचाए। रैंक का उपयोग करने के लिए ये दोनों विकल्प यह स्पष्ट करते हैं कि थ्रेड की रैंक केवल तभी बढ़नी चाहिए जब वह बहुत अधिक CPU समय का उपयोग करता है, और जब लैपटॉप सोने के लिए जाता है, तो LockApp.exe ने केवल 79.3 ms CPU समय का उपयोग किया, और बाकी सिस्टम - CPU समय के साथ 17 । फिर भी, किसी कारण से ओएस ने सोने के लिए जाने की प्रक्रिया में लॉकएप को 2 पर डाउनग्रेड करने का फैसला किया।

OS धारा के रैंक को केवल तभी बदलता है जब वह "नियोजन समूह" ( KSCHEDULING_GROUP ) से संबंधित हो), और एक सामान्य विंडोज इंस्टॉलेशन में अधिकांश धागे सदस्य नहीं हैं। नतीजतन, अधिकांश धागे रैंक में बदलाव के अधीन नहीं हैं, इसलिए वे सीपीयू समय को जिस तरह से चाहते हैं, खर्च कर सकते हैं।

शेष पहेलियाँ

दुर्भाग्य से, यह अभी भी स्पष्ट नहीं है कि लॉकएप ने नींद आने से पहले रैंक 2 को क्यों छोड़ दिया। मैं यह मानूंगा कि लॉकएप योजना समूह में है और शायद एक एल्गोरिदम गलत तरीके से व्यवहार करता है। लेकिन मुझे इसकी जांच करने के लिए एक एपीआई नहीं मिला, और समय समाप्त हो रहा था। यदि आप कोई विवरण जानते हैं, तो टिप्पणियों में मूल लेख में लिखें। नियोजन निर्णयों में सबसे महत्वपूर्ण घटक के रूप में रैंक का उपयोग करने का बहुत सिद्धांत, यह मुझे लगता है, अनिवार्य रूप से टूट जाता है अगर सिस्टम में अधिकांश प्रक्रियाएं इसमें शामिल नहीं होती हैं - नियोजन समूहों में थ्रेड्स हमेशा आवश्यक संसाधनों के बिना छोड़े जाने का जोखिम रखते हैं। डायनेमिक रिसोर्स एलोकेशन प्लानिंग ( DFSS ) को विफल कर दिया जाता है, अगर ज्यादातर धागे शामिल नहीं होते हैं।

इसके अलावा, मुझे नहीं पता कि सोने के बाद इतने सारे एप्लिकेशन सक्रिय क्यों रहते हैं। यह आमतौर पर इस तथ्य से समझाया जाता है कि "कई टाइमर समाप्त हो जाते हैं जब लैपटॉप कई घंटों के लिए स्लीप मोड में होता है," लेकिन यह स्पष्टीकरण उपयुक्त नहीं है यदि लैपटॉप केवल कुछ सेकंड के लिए एक सपने में था, और डब्ल्यूपीए रेंडरिंग व्यवहार इंगित करता है कि विंडो सिस्टम में कुछ होता है कुछ गलत। उस बुरे-व्यवहार एप्लिकेशन और प्रतीक्षा-चक्र ड्राइवरों में जोड़ें, और सीपीयू द्वारा समय के साथ सब कुछ स्टैक्ड हो जाता है।

तथ्य यह है कि सीपीयू तूफान नीचे मर जाते हैं और लॉकअप एक ही समय में शुरू होता है एक स्पष्ट विवरण की ओर जाता है: सीपीयू ड्रॉप होने पर लॉकएप केवल काम कर सकता है। लेकिन एक समान रूप से समझाने वाला स्पष्टीकरण है: जैसे ही लॉकएप को चलाने की क्षमता मिलती है (या, संभवतः, लोगोनयूआई को मिलती है), सीपीयू की मांग गिर जाती है। दोनों स्पष्टीकरण काम करते हैं, लेकिन मुझे लगता है कि उत्तरार्द्ध अधिक प्रशंसनीय है, क्योंकि अन्यथा हम यह नहीं समझा सकते हैं कि डब्ल्यूपीए का प्रतीत होता है अंतहीन प्रतिपादन अचानक बंद क्यों हो जाता है।

समस्या का समाधान

जैसे ही मुझे पता चला कि LockApp.exe एक अलग अनुप्रयोग है जिसे लॉन्च करने में समस्याएं हैं, और यह कि इसकी प्राथमिकता बढ़ाने से कोई फायदा नहीं होता, मैंने इसे बंद कर दिया। फ़ाइल DisableLockScreen.reg ने मुझे इससे मदद की:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Personalization]
“NoLockScreen”=dword:00000001

लॉक स्क्रीन को बंद करने से, लैपटॉप कवर खोलने के तुरंत बाद उठता है। मैंने सीपीयू के ब्रेकिंग या तूफानों पर ध्यान नहीं दिया, और अब इसे दर्ज करने में एक कदम कम लगता है। जब मैंने पहली बार समस्या का सामना किया था, तब मैंने

जो पहली ट्विटर पोस्ट की थी , उसमें एक जांच के लिए एक समयरेखा शामिल है जो किसी के लिए उपयोगी हो सकती है। इसके अलावा, ट्विटर के बहुत सारे स्मार्ट लोग पोस्ट पर आए, उनके लिए धन्यवाद।

जब मैं लेख पर लौटा, मुझे पता चला कि लॉक स्क्रीन को वापस चालू करने के बाद, समस्या गायब हो गई। एक साधारण रिबूट ने इसे ठीक नहीं किया - फरवरी में मैंने कई बार रिबूट किया, लेकिन हम शायद नहीं जानते कि यह क्यों खो गया था।

जांच: विंडोज में थ्रेड प्राथमिकताओं से अधिक क्या है?