وقتی مصرف CPU کامپیوترم ناگهان به ۹۰ درصد رسید، مدتی به تب Processes در Task Manager خیره شدم و چند پردازش را بستم. امیدوار بودم مشکل برطرف شود، اما هیچ تغییری نکرد.
Task Manager همیشه عامل واقعی بعضی از مشکلات ویندوز را نشان نمیدهد؛ بنابراین سراغ Event Viewer رفتم. تنها چند دقیقه طول کشید تا پردازش و خطایی را پیدا کنم که فشار زیادی به پردازنده وارد میکرد. پس از برطرف کردن مشکل، مصرف CPU کاهش پیدا کرد و در محدوده عادی باقی ماند. از آن زمان، برای عیبیابی مشکلات مشابه کمتر به Task Manager متکی هستم.
کار با Event Viewer
وقتی ابزار عمیقتر، سریعتر عمل میکند
ویندوز سابقهای از اتفاقات مختلفی که در کامپیوتر رخ میدهند نگه میدارد؛ از کرش برنامهها و هشدارها گرفته تا بهروزرسانیهای ناموفق و مشکلات درایورها و نصب برنامهها. بسیاری از این رویدادها در Event Viewer قابل مشاهده هستند.
البته Event Viewer لاگهای متعددی دارد و اگر برای نخستین بار وارد آن شوید، ممکن است مشخص نباشد از کجا باید شروع کنید. برای مشکلات مربوط به مصرف غیرعادی CPU، لاگهای System و Application میتوانند مفید باشند، اما در مشکلات مرتبط با WMI، لاگ WMI-Activity اهمیت بیشتری دارد.
مایکروسافت نیز برای عیبیابی مصرف بالای CPU توسط WMI توصیه میکند علاوه بر بررسی پردازش WmiPrvSE.exe، الگوی مصرف CPU و شناسه پردازش یا PID را بررسی کنید. لاگ Microsoft-Windows-WMI-Activity/Operational نیز میتواند اطلاعاتی درباره درخواستهای WMI و پردازشهایی که آنها را ایجاد میکنند در اختیار شما قرار دهد.
در مورد من، خطاهای تکرارشونده در لاگ WMI-Activity قرار داشتند. برای دسترسی به آن، مسیر زیر را باز کردم:
Applications and Services Logs → Microsoft → Windows → WMI-Activity → Operational
سپس از قابلیت Filter Current Log برای محدود کردن نتایج استفاده کردم. در بخش Event level گزینههای Error و Warning را انتخاب کردم و محدوده زمانی Logged را به همان بازهای محدود کردم که افزایش مصرف CPU اتفاق افتاده بود.
این کار حجم زیادی از اطلاعات اضافی را حذف کرد. در ادامه فقط به دنبال Event IDهای تکراری یا منبعی بودم که در فاصله زمانی کوتاه چندین بار ظاهر شده باشد.
خیلی زود متوجه شدم همان خطاهای WMI-Activity هر چند ثانیه یکبار تکرار میشوند.
وقتی اطلاعات را با تب Details در Task Manager مقایسه کردم، یک تفاوت مهم مشخص شد: Event Viewer معمولاً اطلاعات بیشتری درباره مؤلفه یا رویدادی که باعث مشکل شده ارائه میکند، در حالی که Task Manager ممکن است تنها یک پردازش عمومی یا میزبان را نشان دهد.
برای نمونه، در چنین مشکلاتی ممکن است WmiPrvSE.exe همان پردازشی باشد که مصرف CPU را ایجاد کرده است، در حالی که تشخیص اینکه کدام درخواست یا برنامه باعث فعالیت مداوم WMI شده، نیازمند بررسی دقیقتر Event Viewer و اطلاعات WMI است. مایکروسافت نیز تأکید میکند که صرفاً دیدن مصرف بالای WmiPrvSE.exe به این معنی نیست که خود سرویس WMI الزاماً عامل اصلی مشکل است؛ منشأ درخواست میتواند بخش دیگری از سیستم یا یک برنامه باشد.
Event Viewer بهصورت پیشفرض مستقیماً شما را به لاگهای موردنیاز برای چنین مشکلی نمیبرد و همین موضوع باعث میشود Task Manager سادهتر و در دسترستر به نظر برسد. اما پس از انتخاب لاگ مناسب و اعمال فیلتر، اطلاعات Event Viewer بسیار مفیدتر از چیزی بود که از Task Manager دریافت کرده بودم.
خطایی که مدام در پسزمینه دوباره اجرا میشد
Task Manager الگوی واقعی مشکل را نشان نمیداد
Event Viewer نشان داد که یک خطای مشخص وارد یک چرخه شکست مداوم شده است. WmiPrvSE.exe دائماً با مشکل مواجه میشد، خطا را در لاگ ثبت میکرد و دوباره اجرا میشد.
حتی پس از راهاندازی مجدد کامپیوتر نیز مشکل دوباره ظاهر میشد.
این رفتار ممکن است در Task Manager کاملاً عادی به نظر برسد. پردازش مشکلساز برای مدت کوتاهی ظاهر میشود، مصرف CPU را افزایش میدهد و سپس ناپدید میشود.
سعی کردم پردازشها را بر اساس میزان مصرف CPU مرتب کنم، اما افزایش مصرف آنقدر کوتاه بود و بین PIDهای مختلف و نامهای عمومی مانند svchost.exe و RuntimeBroker و WmiPrvSE جابهجا میشد که تشخیص الگو آسان نبود.
در مقابل، مشاهده منبع خطا که در یک بازه زمانی کوتاه بارها در Event Viewer تکرار میشد، تصویر بسیار واضحتری ارائه کرد.
همین چرخه مداوم شروع شدن و کرش کردن و دوباره اجرا شدن باعث شده بود مصرف کلی CPU برای مدتهای طولانی روی ۸۰ تا ۹۰ درصد باقی بماند.
نکته مهم این است که WMI خودش بخشی از زیرساخت اصلی ویندوز است و برنامهها و اسکریپتها از آن برای دریافت اطلاعات و انجام برخی عملیات مدیریتی استفاده میکنند. بنابراین وجود خطا در WMI-Activity لزوماً به معنای خراب بودن خود ویندوز یا WMI نیست؛ گاهی یک برنامه یا سرویس دیگر درخواستهای نامناسب یا بیشازحد ایجاد میکند.
متوقف کردن چرخه مصرف بالای CPU
چند مرحله ساده که مشکل را برطرف کرد
بعد از اینکه مطمئن شدم WmiPrvSE.exe در یک چرخه تکراری گرفتار شده است، Windows Services را باز کردم و سرویس Windows Management Instrumentation را پیدا کردم و آن را Restart کردم.
این کار مصرف شدید و مداوم منابع را متوقف کرد.
در مرحله بعد، Command Prompt را با دسترسی مدیریتی باز کردم و دستور زیر را اجرا کردم:
winmgmt /salvagerepository
این دستور یکی از ابزارهای رسمی مدیریت WMI است. طبق مستندات مایکروسافت، گزینه /salvagerepository سازگاری مخزن WMI را بررسی میکند و اگر ناسازگاری پیدا شود، مخزن را بازسازی میکند و در صورت امکان محتوای مخزن قبلی را نیز به مخزن بازسازیشده منتقل میکند.
بنابراین نباید تصور کرد که این دستور در هر شرایطی و بدون توجه به علت اصلی، مشکل مصرف CPU را برطرف میکند. همچنین مایکروسافت توصیه میکند WMI Repository را به عنوان نخستین اقدام حذف نکنید، زیرا حذف آن میتواند به سیستم یا برنامههای نصبشده آسیب برساند.
در مواردی که با مشکل WMI مواجه هستید، بهتر است ابتدا وضعیت مخزن را بررسی کنید. دستور زیر برای بررسی سازگاری مخزن کاربرد دارد:
winmgmt /verifyrepository
اگر مشکل واقعاً از ناسازگاری مخزن WMI باشد، استفاده از /salvagerepository میتواند مرحله بعدی عیبیابی باشد. مایکروسافت نیز در راهنمای عیبیابی WMI، بررسی مخزن و استفاده از این دستور را در سناریوهای مناسب توصیه کرده است.
پس از اجرای دستور، سیستم را Restart کردم و دوباره به لاگ خطاهای Event Viewer برگشتم. خطاهای تکراری WMI-Activity دیگر ظاهر نمیشدند.
وقتی Task Manager را بررسی کردم، مصرف CPU نیز از حدود ۹۰ درصد به محدوده عادی برگشته بود. فنهایی که در زمان فشار زیاد پردازنده با صدای بلند کار میکردند نیز آرام شدند.
بعد از رفع مشکل چه چیزی را باید بررسی کرد؟
مشکل اصلی برطرف شده بود، اما دو بررسی دیگر انجام دادم. ابتدا بررسی کردم آیا یک Task مرتبط باعث ایجاد درخواستهای مکرر WMI میشود یا خیر. سپس روز بعد دوباره به لاگ WMI-Activity برگشتم تا مطمئن شوم خطاها بازنگشتهاند.
این مرحله مهم است، زیرا اگر یک برنامه یا سرویس خارجی مرتباً درخواستهای WMI ایجاد کند، تعمیر مخزن WMI بهتنهایی ممکن است راهحل دائمی نباشد.
مایکروسافت نیز در راهنمای عیبیابی مصرف بالای CPU توسط WMI پیشنهاد میکند به زمان و الگوی افزایش مصرف توجه شود؛ یعنی بررسی کنید مصرف بالا تصادفی است یا در فواصل مشخص تکرار میشود و آیا همزمان فعالیت خاصی مانند اجرای یک برنامه یا سرویس مشاهده میشود.
به همین دلیل، PID و زمان وقوع مشکل دو سرنخ بسیار مهم هستند. اگر WmiPrvSE.exe مرتباً با PIDهای مختلف ظاهر شود، بررسی WMI-Activity میتواند به پیدا کردن درخواست یا مؤلفهای که پشت این فعالیت قرار دارد کمک کند.
روش سریعتر برای عیبیابی ویندوز
اگر بخواهم منصف باشم، Event Viewer در مقایسه با Task Manager کمی قدیمی به نظر میرسد؛ مخصوصاً با توجه به اینکه مایکروسافت در نسخههای مختلف ویندوز Task Manager را بهبود داده است.
با این حال، Event Viewer در بررسی توالی واقعی خطاها و اتفاقاتی که قبل و بعد از یک مشکل رخ دادهاند، بسیار عمیقتر عمل میکند. اگر بدانید کدام لاگ را باید باز کنید و چگونه آن را فیلتر کنید، این ابزار میتواند برای پیدا کردن علت اصلی یک مشکل بسیار سریعتر از حد انتظار باشد.
| وضعیت | Task Manager | Event Viewer |
|---|---|---|
| مصرف بالای CPU در لحظه | نام پردازش و درصد مصرف را نشان میدهد | خطاها و رویدادهای مرتبط را نیز نشان میدهد |
| افزایش مصرف مقطعی | ممکن است بهراحتی از دست برود | الگوی تکرارشونده را در لاگ حفظ میکند |
|
پردازشهای عمومی مانند svchost و WmiPrvSE |
جزئیات محدودی ارائه میکند | میتواند اطلاعات بیشتری درباره رویداد و مؤلفه مرتبط ارائه کند |
| پس از Restart | اطلاعات مربوط به قبل از راهاندازی مجدد را در اختیار ندارید | سابقه رویدادها همچنان در لاگ باقی میماند |
| پیدا کردن علت اصلی | گاهی نیازمند حدس و بررسی چند پردازش است | میتواند شما را به خطا یا رویداد مشخصی هدایت کند |
Task Manager برای چه چیزی بهتر است؟
Task Manager همچنان برای مشاهده سریع مصرف CPU و RAM و GPU و Disk بسیار مناسب است. اگر یک برنامه مشخص در همان لحظه منابع زیادی مصرف میکند، معمولاً سریعترین راه برای شناسایی آن همین ابزار است.
اما وقتی مصرف CPU مقطعی و تکرارشونده است و پردازش مشکلساز پیش از اینکه بتوانید آن را شناسایی کنید ناپدید میشود، Event Viewer میتواند تصویر کاملتری ارائه کند.
Event Viewer برای چه زمانی مناسبتر است؟
Event Viewer زمانی ارزش بیشتری پیدا میکند که بخواهید بدانید چرا یک پردازش مرتباً اجرا میشود یا چرا یک سرویس و برنامه بارها با خطا مواجه میشود.
در مورد WMI، لاگ Microsoft-Windows-WMI-Activity/Operational بهخصوص ارزش بررسی دارد. مایکروسافت در راهنمای رسمی خود نیز از همین لاگ برای بررسی فعالیتهای WMI و شناسایی درخواستهای مرتبط با مصرف بالای CPU استفاده میکند.
دفعه بعد، قبل از بستن پردازشها Event Viewer را بررسی میکنم
این تجربه به من یاد داد که اگر دفعه بعد مصرف CPU ناگهان افزایش پیدا کند و Task Manager نتواند عامل آن را بهوضوح نشان دهد، پاسخ احتمالاً جایی در Event Viewer پنهان شده است.
فیلتر کردن Error و Warningهای اخیر و بررسی Event IDهای تکرارشونده، در بسیاری از موارد سریعتر از این است که پشت سر هم پردازشها را در Task Manager ببندید.
مهمتر از آن، Event Viewer اطلاعاتی درباره الگوی خطا در اختیار شما میگذارد. همین اطلاعات میتواند مشخص کند مشکل فقط یک افزایش مصرف موقتی بوده یا یک پردازش و سرویس در پسزمینه دائماً در حال شکست خوردن و دوباره اجرا شدن است.
اگر CPU بدون دلیل مشخص برای مدت طولانی روی ۸۰ یا ۹۰ درصد باقی مانده است، Task Manager نقطه شروع خوبی است؛ اما اگر پاسخ روشنی پیدا نکردید، Event Viewer میتواند همان ابزاری باشد که علت واقعی مشکل را آشکار میکند.
سیارهی آیتی