🙌🏿 👨🏼‍💼 🙅 التحقيق: ما هو أعلى من أولويات مؤشر الترابط في Windows؟ 🙋🏿 🤙🏾 🈹

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

في المرات القليلة الأولى ، عندما أدى ذلك إلى تأخير عشرين ثانية ، تجاهلت المشكلة ، على أمل أن تحل نفسها. في المرات القليلة التالية التي فكرت فيها في التحقيق ، ولكن مشاكل الأداء التي تنشأ حتى قبل تسجيل الدخول أكثر صعوبة في حلها ، وكنت كسولًا.

عندما لاحظت أنني كنت أتجنب إغلاق الكمبيوتر المحمول لأنني كنت خائفة من هذه التأخيرات المتكررة جدًا ، أدركت أن الوقت قد حان للقيام بذلك بجدية.

لحسن الحظ ، قمت مؤخرًا بإصلاح تتبع المخزن المؤقت الحلقي UIforETWجعلها موثوقة ، لذلك بدأت في ذلك وبدأت في انتظار حدث التأخير التالي. لم يكن علي الانتظار طويلا.

استغرق الأمر مني عدة مرات للحصول على تتبع ETW على ما يرام تمامًا معي . وبما أن هذه المنطقة كانت غير مألوفة بالنسبة لي ، فقد استغرق الأمر بعض الوقت لمعرفة ما كان يحدث. ما زلت لم أفهم المشكلة تمامًا ، لكن 90 ٪ فهموا أسباب حدوثها. تمكنت من تعلم الكثير ، بما في ذلك بعض التفاصيل الجديدة حول جدولة Windows ، ووجدت أيضًا حلًا فعالًا تمامًا.

يبدو التتبع المثالي الذي سجلته في النهاية عند التحميل في Microsoft Windows Performance Analyzer (WPA) كما يلي:

الأحداث القياسية والنوافذ في التركيز واستخدام وحدة المعالجة المركزية.

يحتوي هذا الجدول ورسمان بيانيان على الكثير من المعلومات. يوضح الجدول العلوي ( الأحداث العامة ) ضغطات المفاتيح المسجلة لـ UIforETW. حاولت الضغط على مفتاح (رمز المفتاح الظاهري 162) مرة واحدة في الثانية حتى يظهر حقل إدخال كلمة المرور. نظرًا لأنه يتم تحديد ضغطات المفاتيح الـ 17 هذه ، يظهر في الرسم البياني أدناه خطوط زرقاء رأسية لتصور مبسط لوقت تنفيذ الأحداث المهمة. يمثل المحور س الوقت بالثواني.

توضح الأشرطة الأفقية في الرسم البياني العلوي ( Window in Focus ) العملية التي تم التركيز عليها خلال هذا الوقت. هناك ست عمليات مختلفة في المجموع. فترة التعقب هي الفترة القصيرة التي تم خلالها إغلاق الكمبيوتر المحمول.

يوضح الرسم البياني السفلي استخدام وحدة المعالجة المركزية . يتم الحصول على المعلومات من بيانات تبديل السياق ، لذلك يجب أن تكون دقيقة وكاملة تمامًا. في هذا التتبع ، تشير قيمة 100٪ إلى اللحظة التي تم فيها استخدام جميع المعالجات المنطقية الثمانية لجهاز الكمبيوتر الدفتري رباعي النواة ذي الثماني نواة.

بعد أن تلقيت بيانات التتبع ، كان عليّ معرفة ما يفعله الكمبيوتر المحمول سراً عند إغلاق الغطاء وحتى لحظة عودتي إلى النظام.

العاصفة قبل الهدوء

كما نرى ، فإن الكمبيوتر المحمول في بداية تتبع الكمبيوتر المحمول بسيط نسبيًا ، كما يجب أن يكون. ثم أغلقت غطاءها. يبدو أن هذا قد تسبب في ارتفاع كبير في نشاط وحدة المعالجة المركزية وتغيير في تركيز النوافذ. تغيرت النافذة في التركيز من UIforETW إلى Idle ، ثم إلى csrss ، ثم إلى Idle ، إلى LogonUI ، ثم عادت إلى Idle. من كان يظن؟

خلال هذه الفترة ، أجرى الكمبيوتر المحمول حوالي 17 ثانية من معالجة وحدة المعالجة المركزية بأنواع مختلفة. جزء منه هو العمل المطلوب للإغلاق. الجزء - هذه برامج (بما في ذلك أدوات Google الداخلية) مسجلة في "برنامج جدولة المهام" لتنفيذ "عندما يقوم مستخدم بتأمين محطة عمل" - من المنطقي. حتى أنني لاحظت أنه يتم العمل على إنشاء عناصر واجهة المستخدم لتسجيل الدخول عندما يستمر المستخدم في العمل - تحتاج إلى الاستعداد مسبقًا ، أليس كذلك؟

17 ثانية من وحدة المعالجة المركزية - وقت طويل جدًا للكمبيوتر المحمول للنوم. تستغرق العملية أكثر من أربع ثوانٍ ، حتى على الكمبيوتر المحمول المزود بأربع نوى وثمانية خيوط. على جهاز الكمبيوتر المحمول في المنزل ، يستغرق الأمر أكثر من 13 ثانية من وقت وحدة المعالجة المركزية للنوم ، وكلها تقريبًا تذهب إلى رمز Windows. هل تحتاج خدمة سياسة التشخيص حقًا إلى تشغيل اثنين من SruDbTable Searches قبل أن يتمكن الكمبيوتر المحمول من الراحة؟

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

وفقط بعد ذلك أدركت أنه خلال هذا الوقت تم إلقاء حبيبات تدمير بقائي ...

ينام

بعد حظر الكمبيوتر المحمول ، لا يوجد نشاط وحدة المعالجة المركزية. في هذا الاختبار بالذات ، تم قفل الكمبيوتر المحمول لمدة 16 ثانية تقريبًا.

الصحوة المتشنجة

نشاط وحدة المعالجة المركزية عند الانتقال إلى النوم لا يقارن عندما بدأ الاستيقاظ. خلال هذا الوقت ، استغرق جهاز الكمبيوتر المحمول الخاص بي المثقل حوالي 172 ثانية من وقت وحدة المعالجة المركزية (!!!) لمدة 22.6 ثانية. هذا عمل كثير

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

لغز آخر هو لماذا الكثيرالبرامج تنبض بالحياة بعد هذا التوقف القصير. من المضحك أن أخطر متسلل مسؤول عن 31.6 من 172 ثانية من وحدة المعالجة المركزية كان Windows Performance Analyzer (WPA) - البرنامج الذي أستخدمه لتحليل الآثار. تعمل النسخ الثلاث التي تركتها قيد التشغيل بجد على عرض واجهة المستخدم الخاصة بي ، على الرغم من أنها غير مرئية حتى الآن.

بالإضافة إلى ذلك ، تحدث أنماط داكنة عند محاولة تهيئة أجهزة الكمبيوتر المحمول. KeStallExecutionProcessor عبارة عن حلقة انتظار ، وكان من الغريب أن نرى أن هذه هي الوظيفة الأكثر قابلية للتنفيذ للنظام بأكمله. هل دورة الانتظار الثانية هي الطريقة الوحيدة لبدء المعدات؟ هل من الضروري حقًا قضاء 700 مللي ثانية من وقت وحدة المعالجة المركزية في تهيئة الماوس ولوحة المفاتيح ؟ هل يجب على Microsoft و Intel تجاهل توصية Microsoft بشأنبحد أقصى 50 ميكروثانية ؟

محركات دورة الانتظار. تمت كتابة i8042prt.sys بواسطة Microsoft. تم إنشاء التاليين بواسطة Intel.

في نهاية المطاف ، يتم تشغيل العديد من البرامج بنشاط خلال هذا الوقت . يبدو أن معظمهم يواجهون نفس مشكلة WPA - فهم يائسون لرسم رسومات على شاشة مخفية ، وهذا يشير إلى خطأ في Windows. ولكن حتى بدون هذا الخطأ explorer.exe والبرامج الأخرى تسعى بنشاط للقيام بشيء ما. ولكن في النهاية ، على الرغم من أن هذا الاستخدام المفرط لوحدة المعالجة المركزية هو جزء ضروري من المشكلة ، إلا أنها ليست المشكلة نفسها . لذا مرة أخرى توقفت عن الاهتمام بها.

التركيز

عند تحليل الآثار ، من المهم معرفة متى تحدث الإجراءات الهامة. كان الدليل الرئيسي هو أحداث الإدخال ، لأنني توقفت عن النقر على عنصر التحكم بعد ظهور نموذج إدخال كلمة المرور. فيما يلي ضغطات المفاتيح الثلاثة الأخيرة لمفتاح التحكم بشكل تقريبي على الرسم البياني لـ Window in Focus :

يبدو أن الأحداث الحاسمة تحصل على تركيز LockApp.exe ، وبعد ذلك يحصل التركيز على LogonUI.exe على الفور تقريبًا. من المفترض ، أنني أدخلت كلمة المرور في LogonUI.exe (من الملائم أن التتبع لم يعترض أحداث لوحة المفاتيح) ، وبعد ذلك تحول التركيز لفترة وجيزة إلى المستكشف ، ثم إلى UIforETW ، الذي بدأت منه.

يبدو أيضًا أن LogonUI.exe لا يمكنه التركيز قبل LockApp.exe - هذا النمط يعيد نفسه في جميع الآثار التي درستها.

لذا ، بعد أكثر من ألف كلمة مخصصة لحل هذا اللغز ، لدينا أخيرًا سؤال واضح يمكننا التحقق منه: لماذا يركز LockApp.exe بعد الخروج من وقت التوقف عن العمل ، يستغرق عشرين ثانية؟

لدينا سؤال؟ رائع ، دعنا نجيب عليه

باستخدام بيانات استخدام CPU (دقيقة) التي تم الحصول عليها من تبديل المحتوى ، اكتشفت بسرعة أنه في غضون عشرين ثانية بعد تنبيه LockApp.exe تلقى أقل من مللي ثانية واحدة من وقت وحدة المعالجة المركزية ، ولمدة تزيد عن 14 ثانية (من 35.158 ثانية إلى 49.827 ثانية) عموما:

لا يعمل LockApp على الإطلاق لفترة طويلة

الوثائق الخاصة بمعنى الأعمدة في جداول استخدام CPU (دقيقة) هنا .

إذا لم تكن العملية أو الخيط قيد التشغيل لبعض الوقت ، وترغب في معرفة السبب ، فعادة ما يمكن العثور على أدلة مهمة في تبديل السياق الأول بعد فترة هدوء طويلة ، أي التبديل إلى 49.827 ثانية من التتبع. لقد أعدت ترتيب الأعمدة لإظهار المزيد من البيانات من تبديل السياق هذا:

تم تحضير LockApp ولكن لم يتم تنفيذها. غريب ...

العد ، يساوي 1 يعني أننا ننظر إلى البيانات لتبديل سياق واحد.

الوقت منذ الماضي ، يساوي 38.2 مليون ميكروثانية ، يعني أن هذا الخيط لن يتم تنفيذه في غضون 38.2 ثانية. هذا في حد ذاته ليس جيدًا ولا سيئًا. تدفقات الخمول توفر الطاقة ، وفي النهاية كان الكمبيوتر المحمول في المنام لبعض الوقت.

يخبرنا وقت التبديل ببساطة عن وقت ملاءمة الخيط بالضبط في وحدة المعالجة المركزية - عندما يتحول السياق إلى هذا الخيط.

والآن ننتقل إلى العمود جاهز. يخبرنا إلى متى كان الخيط جاهزًا للتنفيذ ، ولكن لم يتم تنفيذه. وبعبارة أخرى ، كان هذا الموضوع ينتظر شيئًا (قفلًا ، مقبضًا) وهذا شيءتم تحريره أو بدء تشغيله ، ولكن مؤشر الترابط لا يزال لا يعمل لمدة 19.493 ثانية.

لفهم عمود جاهز (الولايات المتحدة) بشكل أفضل ، يمكنك إلقاء نظرة على عمود (أوقات) الجاهزية . يخبرنا عندما يتم إعداد الدفق. نرى أنه لمدة 30.333 ثانية من التتبع ، تم تحضير هذا الخيط للتنفيذ ، ولكن لم يتم تنفيذه حتى 49.827 ثانية. يبدو أن هذا مهم.

يُظهر لنا ترتيب الأعمدة هذا نفس تبديل السياق:

مكدس

خيط جديد ومكدس خيط جاهز لذا ، تم طلب هذا الخيط (الذي توقع مكدس الخيط الجديد NtWaitForWorkViaWorkerFactory) أن يستيقظ (عملية النظام التي تستدعي KeSetEvent) بعد فترة وجيزة من فتح غطاء دفتر الملاحظات لمدة 30.333 ثانية من التتبع. لكنها لم تبدأ بعد ذلك (والتي ستكون "جيدة") ، ولكن بعد 19.494 ثانية ، وهذا أمر سيئ.

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

حالات ...

معظم الناس لا يقضون الكثير من الوقت في دراسة آثار ETW ، لذلك هناك حاجة إلى شرح هنا. هذا غريب جدا إذا كان الخيط جاهزًا ، فعادة ما يبدأ على الفور ، أو بعد بضع ثوانٍ. إن استعداد الدفق ، كما يوحي الاسم ، يعني أن الدفق جاهز للتنفيذ ولا يمكن أن يتداخل معه أي شيء تقريبًا. ولكن دعونا نكتشف ما يمكن أن يمنع تنفيذ خيط الانتهاء.

الأولوية موضوع

في البداية اقترحت أن هذه حالة بسيطة من "الجوع" وحدة المعالجة المركزية. تتطلب العشرات من العمليات وقت وحدة المعالجة المركزية ، وبسبب هذا ، لا يحصل LockApp على الوقت المناسب حتى ينخفض الحمل. ومع ذلك ، لا تتوافق هذه النظرية تمامًا مع الأعراض ، لأن عملية LockApp يمكن أن تستغرق حوالي 18 ثانية حتى بدون الحصول على وقت وحدة المعالجة المركزية.

نظرية الجوع CPU جيدة لأنها يمكن التحقق منها. تمكنت من زيادة أولوية عملية LockApp باستخدام إدارة المهام (خلال إحدى الفترات القصيرة عندما لم يتم تعليقها بواسطة نظام UWP) ، وبالتالي ، في التتبع النهائي الذي استخدمته لهذا المنشور ، تم تنفيذ LockApp بأولوية عالية. يتم تشغيل مؤشر ترابط Windows عادي بأولوية حوالي 8-10. أعلى أولوية يمكن من خلالها تشغيل مؤشر ترابط Windows عادي (غير في الوقت الحقيقي) هو 15. أظهرت آثار ETW الخاصة بي أن LockApp يعمل دائمًا مع الأولوية 13 أو أعلى.

إليك جدول زمني لوحدة المعالجة المركزية لـ 19.494 ثانية ، مجمعة وملونة حسب أولوية الخيط ( New In Pri، الأولوية الحالية التي تم تعيينها لمؤشر الترابط). نرى أن سلاسل الرسائل ذات الأولويات 4 و 8 و 9 و 10 تستهلك الغالبية العظمى من وقت وحدة المعالجة المركزية ، خاصة في النهاية:

استخدام وحدة المعالجة المركزية حسب الأولوية هذه

صورة أخرى بها سلاسل رسائل مخفية ذات أولويات 0-12. في كل مرة ينخفض الرسم البياني إلى أقل من 12.5٪ (وهو ما يعني معالجًا منطقيًا لوقت وحدة المعالجة المركزية لجهاز الكمبيوتر الدفتري ذي الثمانية سلاسل) ، يجب تشغيل LockApp ، ويصبح من غير المعقول على الإطلاق أن الأولوية تمنع تنفيذه في كثير من الأحيان عندما تكون العديد من سلاسل الرسائل ذات أولوية أقل أو متساوية احصل على الكثير من الوقت.

استخدام وحدة المعالجة المركزية ذات الأولوية ، وسلاسل العمليات ذات الأولوية العالية فقط

إزالة انعكاس الأولوية

هناك تكهنات بأن خوارزميات الانعكاس ذات الأولوية لـ Windows مواتية للغاية لمؤشرات الترابط الأخرى التي تم حظر LockApp.exe. ولكن بما أن الرسوم البيانية الموضحة أعلاه توضح استخدام الأولويات الحقيقية في قرارات التخطيط ، فيجب التخلي عن هذا الافتراض (غير المقنع دائمًا).

كومة التفريغ الأساسية

عندما تحدثت عن هذا اللغز على Twitter ، اقترح أحد المعلقين أنه تم تفريغ حزمة خيط المناقشة . لم أكن على دراية بهذا الموقف ، ولكن بعد تفسيرات جون ويرث (يفهم في مجاله) ، أوقفت مبادلة مكدس النواة وأعدت تشغيل الكمبيوتر. لا شيء تغير. في الواقع ، لم أكن أعتقد أن هذا سيساعد ، نظرًا لأن لدي ذاكرة 32 جيجابايت ، وتحدث المشكلة بشكل متكرر وغالبًا ؛ ولكن كان من الأفضل التأكد من ذلك.

وقفة العملية

نظرًا لأن LockApp هو تطبيق UWP حديث ، فإنه يخضع لقيود مشابهة لتلك المفروضة على تطبيقات الهواتف الذكية. من بين أمور أخرى ، هذا يعني أنه يمكن تعليقه عندما لا يكون في المقدمة ، ثم "إلغاء التجميد" عند إعادته إلى المقدمة. اقترح جيمس فورشو تسجيل Microsoft-Windows-Kernel-Process ETW للحصول على بيانات حول ذلك.

تم تصميم الأحداث لإحداث أقصى قدر من الارتباك. يتم استخدام اسم المهمة " عملية تجميد" لكل من "تذويب" و "تجميد" ، وإصدار الفوز: حدث التوقف يعني أن العملية تبدأ (توقف التجميد) ، وإصدار الفوز: ابدأيعني أن العملية تتوقف (تبدأ في التجمد). كل هذا منطقي للغاية ، ولكنه مربك للغاية. إذا تم تقسيم أسماء الأحداث إلى Freeze و Thaw ، فسيكون هناك قدر أقل من الارتباك.

لا توجد وثائق لهذه الأحداث ، ولكن بفضل التحليل ، قررت أن هذه الأحداث يتم إنشاؤها دائمًا بواسطة خدمة البنية التحتية لمهام الخلفية / وسيط . يشار إلى اسم ومعرف العملية للعملية المقابلة في حقل FrozenProcessID.

ProcessFreeze Events (يستخدم أيضًا لإذابة الثلج)

كان من المثير للاهتمام التحقيق في هذا المزود - لديه العديد من الأحداث الواعدة - ولكن في النهاية اتضح أن LockApp لم يتوقف مؤقتًا أو يذوب الجليد أثناء التتبع. ومع ذلك ، بدا هذا الموفر مفيدًا جدًا ، لذلك قمت بتعديل UIforETW بحيث تقوم الإصدارات المستقبلية بتدوينه دائمًا.

لقد استبعدنا بالفعل كل شيء

لا يبدو لي أن أيًا من النظريات الموصوفة أعلاه محتملة للغاية ، والآن استبعدناها جميعًا. بدأت في البحث عن المساعدة ، وطلبت مني أن أقدم لي أفكارًا من صديق من Microsoft. وفي تلك اللحظة اكتشفت أن أولوية التدفق 0-31 المعروفة جيدًا في Windows هي في الواقع خمس بتات ذات أولوية منخفضة لنظام الأولوية الكاملة .

استخدام المنصب الرسمي

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

هذا المجال ذو الأولوية الفائقة الذي لم أكن أعرف عنه يسمى الرتبة . يظهر في WPA كعمود مخفي افتراضي (للعثور عليه ، يجب عليك فتح محرر العرض) يسمى NewThreadRank . عند تخطيط سلاسل الرسائل ، يكون ترتيب سلسلة الرسائل أولوية على الأولوية. جميع التدفقات تقريبًا لها رتبة 0 ، ودفق ذو رتبة 0 دائمًا له أولوية أعلى من تيار مع رتبة 2. بتضمين عمودNewThreadRank والنظر إلى الجانب الأيسر من الجدول ، يمكننا أن نرى المشكلة على الفور:

الرتبة أكثر أهمية من الأولوية

، حيث أن تدفقات LockApp.exe لها رتبة 2 ، مما يعني أنه على الرغم من الأولوية 14 ، إلا أنها تحظى بأولوية أقل في النظام.

شرح شبه كامل

نظرًا لأنه تبين أن سلاسل عمليات LockApp.exe لها رتبة 2 ، فلا يمكن تنفيذها إلا عندما لا يتم تشغيل أي من سلاسل العمليات التي تحمل التصنيف 0 "تريد". نظرًا لأن العديد من التطبيقات (لأسباب غير معروفة) تعرض الشاشات غير المرئية بشكل نشط ، فإنها تقاتل من أجل كل فتات من وقت وحدة المعالجة المركزية ، ولا تترك شيئًا في صفوف أعلى. بمجرد أن يتلقى LockApp.exe جزءًا صغيرًا من وقت وحدة المعالجة المركزية ، فإنه ينتقل بسرعة إلى الرتبة 0 (وينخفض حمل وحدة المعالجة المركزية) ، وبعد ذلك يتم تنفيذ عملية تسجيل الدخول بالطريقة المعتادة.

بعد أن علمت هذه المعلومات ، بدأت في دراسة كيفية تغير ترتيب LockApp بمرور الوقت. في الثواني القليلة الماضية ، انتقل LockApp فجأة من الرتبة 0 إلى 2 قبل النوم. تم تصميم الرتبة لمنع وحدة المعالجة المركزية من شغل الكثير من الوقت ، كما هو الحال عندما يكون Windows Photos شديد الحرص على معالجة الخلفية غير المرغوب فيها ويؤدي الانتقال من الرتبة 2 إلى 19:

تنخفض Microsoft.Photos من المرتبة

من الوثائق يمكنك أن تفهم أن الغرض الرئيسي من ترتيب الدفق هو المشاركة العادلة لوقت وحدة المعالجة المركزية بين الجلسات على الجهاز بحيث لا تضر عمليات مستخدم واحد بالآخرين. يوضح كلا هذين الخيارين لاستخدام الترتيب أن ترتيب الدفق يجب أن يزيد فقط إذا كان يستخدم الكثير من وقت وحدة المعالجة المركزية ، وعندما ذهب الكمبيوتر المحمول إلى وضع السكون ، استخدم LockApp.exe 79.3 مللي ثانية فقط من وقت وحدة المعالجة المركزية ، وبقية النظام - 17 من وقت وحدة المعالجة المركزية . ومع ذلك ، قرر نظام التشغيل لسبب ما تخفيض إصدار LockApp إلى 2 في عملية النوم.

يغير نظام التشغيل رتبة الدفق فقط إذا كان ينتمي إلى "مجموعة التخطيط" ( KSCHEDULING_GROUP) ، ومعظم مؤشرات الترابط في تثبيت Windows النموذجي ليست أعضاء. وبالتالي ، لا تخضع معظم سلاسل الرسائل لتغيير في الترتيب ، لذا يمكنهم قضاء وقت وحدة المعالجة المركزية بالطريقة التي يريدونها.

الألغاز المتبقية

لسوء الحظ ، لا يزال من غير الواضح سبب انخفاض LockApp.exe إلى الرتبة 2 قبل تشغيل وضع السكون ، وسأفترض أن LockApp في مجموعة التخطيط ، وربما تتصرف إحدى الخوارزميات بشكل غير صحيح. ولكن لم أجد واجهة برمجة تطبيقات للتحقيق في ذلك ، وكان الوقت ينفد. إذا كنت تعرف أي تفاصيل ، فاكتب التعليقات على المقالة الأصلية. يبدو لي أن مبدأ استخدام الرتبة كأهم عنصر في قرارات التخطيط ، يجب أن ينهار حتمًا إذا لم تشارك فيه معظم العمليات في النظام - فالخيوط في مجموعات التخطيط تعرض دائمًا لخطر تركها دون الموارد اللازمة. إن تخطيط تخصيص الموارد الديناميكي ( DFSS ) محكوم عليه بالفشل إذا لم يتم تضمين معظم سلاسل الرسائل.

أيضا ، لا أعرف لماذا تظل العديد من التطبيقات نشطة بعد النوم. عادة ما يتم تفسير ذلك من خلال حقيقة أن "العديد من المؤقتات تنتهي عندما يكون الكمبيوتر المحمول في وضع السكون لعدة ساعات" ، ولكن هذا التفسير غير مناسب إذا كان الكمبيوتر المحمول في المنام لبضع ثوان فقط ، ويشير سلوك عرض WPA إلى حدوث شيء ما في نظام النافذة هل هناك خطب ما. أضف إلى ذلك التطبيقات السيئة وبرامج تشغيل دورة الانتظار ، وكل شيء مكدس بمرور الوقت بواسطة وحدة المعالجة المركزية.

حقيقة أن عواصف وحدة المعالجة المركزية تتلاشى وبدء تشغيل LockApp في نفس الوقت يؤدي إلى تفسير واضح: يمكن أن يعمل LockApp فقط عندما ينخفض طلب وحدة المعالجة المركزية. ولكن هناك تفسير مقنع بنفس القدر: بمجرد أن يحصل LockApp على القدرة على التشغيل (أو ربما يحصل LogonUI عليه) ، ينخفض طلب وحدة المعالجة المركزية. يعمل كلا التفسرين ، ولكن أعتقد أن الثاني أكثر معقولية ، لأنه بخلاف ذلك لا يمكننا تفسير سبب توقف عرض WPA الذي يبدو بلا نهاية.

حل للمشكلة

بمجرد أن أدركت أن LockApp.exe هو تطبيق منفصل يعاني من مشاكل في التشغيل ، وأن رفع أولويته لا يساعد ، فقد قمت بتعطيله. ساعدني ملف DisableLockScreen.reg في ذلك:

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

بإيقاف تشغيل شاشة القفل ، يستيقظ الكمبيوتر المحمول مباشرة بعد فتح الغطاء. لم ألاحظ فرملة أو عواصف وحدة المعالجة المركزية ، والآن يستغرق الأمر خطوة أقل للدخول.

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

عندما عدت إلى المقالة ، اكتشفت أنه بعد إعادة تشغيل شاشة القفل ، اختفت المشكلة. لم تعمل عملية إعادة تشغيل بسيطة على إصلاحها - في فبراير ، أعيد تشغيلها عدة مرات ، ولكن ربما لن نعرف سبب فقدانها.

التحقيق: ما هو أعلى من أولويات مؤشر الترابط في Windows؟