CPU tinggi dari ntoskrnl.exe saat idle di GetStackLimits


3

Saya mengalami bug aneh di Windows 10.

Setelah 5 menit idle, cpu saya menjadi tinggi. Saya menggunakan Win Performance Analyzer dan menemukan bahwa itu terjadi di dalam ntoskrnl.exe pada utas GetStackLimits.

Saya telah memperbarui semua driver dan semuanya fungsional. Semua tugas menganggur dinonaktifkan dan dihapus. Saya juga menjalankan sfc / scannow dan chkdsk tanpa kesalahan.

Bagaimana saya bisa menemukan kesalahan ketika ada di dalam kernel ?!

Jawaban:


2

Saya menemukan jawaban untuk masalah saya sejak lama, tetapi lupa menambahkannya di sini.

Itu adalah fungsi perawatan di Windows 10 yang disebut:

RunFullMemoryDiagnostic

Ditemukan di bawah:

\ Microsoft \ Windows \ MemoryDiagnostic

Setelah menonaktifkan ini, tugas perawatan saya dapat selesai alih-alih hanya menggunakan CPU pada tugas ini.

Saya tidak memiliki masalah memori atau BSOD akhir-akhir ini, tetapi saya memiliki memori 32GB, yang mungkin memainkan peran untuk menyelesaikan tugas ini.

Saya memang menjalankannya selama beberapa jam, tetapi tidak pernah selesai, jadi saya jauh lebih baik tanpanya.

Terima kasih atas bantuannya!


0

Sayangnya, saya tidak tahu apakah perilaku ini berhenti ketika kondisi siaga hilang, tapi itu hal yang normal bagi mpengine (Microsoft AV stuff) untuk menjalankan alat MRT dan memindai seperti orang gila, yang menghasilkan penggunaan CPU yang tinggi untuk beberapa waktu (yang alat ini perlu menjalankan pemindaiannya), setelah beberapa saat idle saat pengguna masuk.

Jika penggunaan CPU kembali normal setelah Anda melakukan sesuatu seperti menggerakkan mouse atau menyentuh tombol, ini mungkin yang terjadi.

Saya menemukan ini paling mudah untuk dilihat dengan Process Explorer.

Jika aktivitas tetap tinggi saat kondisi diam berhenti, itu adalah hal lain.


0

Martin, dalam kasus saya itu disebabkan oleh Hyper-V yang diaktifkan (sebelum memutakhirkan dari Windows 8.1 ke 10) dan mungkin menggunakan koneksi jaringan yang tidak kompatibel dengan pengontrol Realtek PCIe GBE Family (Ethernet) yang datang dengan sistem desktop saya yang awalnya memiliki Windows 8.0 yang diinstal di sana. Satu-satunya alasan saya menggunakan Hyper-V adalah untuk pengembangan Windows Phone 8. Saya belum pernah menggunakan ini selama bertahun-tahun, tetapi jaringan itu berjalan pada koneksi yang dijembatani dan saya tidak pernah bisa membuatnya bekerja tanpa jembatan. Saya tidak tahu apa-apa tentang pengaturan ini. Pemasang Visual Studio melakukan semua pengaturan Hyper-V dan jaringan virtual.

Untuk memperbaiki masalah, saya cukup menghapus Hyper-V di dialog panel kontrol "Aktifkan atau nonaktifkan Windows" dan ini secara otomatis menghapus koneksi jembatan. Lalu saya menghabiskan beberapa jam untuk mendapatkan koneksi ethernet langsung saya untuk bekerja lagi. Diagnostik tidak membantu dengan ini. Saya akhirnya menggunakan trik lama menukar port koneksi yang digunakan pada router dengan yang lain (dari empat) dan Windows akhirnya bisa melihat komputer lain di jaringan rumah saya lagi.

Untuk membantu mendiagnosis masalah, saya menggunakan setup xperf cmd MagicAndre1981 untuk menghasilkan etl. (Lihat Menginstal WPT .) Saya kemudian membuka file ini di "Windows Performance Analyzer" dan menambahkan kolom "Stack" seperti pada contoh MagicAndre1981. Nama-nama modul di bawah root System memberi saya petunjuk bahwa itu mungkin Hyper-V seperti yang saya duga selama ini.


Saya pikir Anda benar tentang perangkat ethernet RealTek GBE yang menjadi biang keladinya dan saya tidak pernah berpikir bahwa Hyper-V memiliki pengaruh. Saya juga menggunakannya, tetapi untuk Virtualbox, tetapi jika itu membuat mesin saya sangat tidak stabil saya lebih suka mematikannya. Namun saya kembali ke Win7 selama satu minggu sekarang dan saya tidak mengalami masalah sama sekali. Memiliki BSOD di Win10 juga, yang membuat saya menjatuhkannya. Saya mencoba menggunakan Xperf dengan Simbol dan segalanya, tetapi itu terus menggali ke dalam kernel. Saya akan menerima ini sebagai jawabannya, karena ini adalah solusi yang paling rumit.
Martin Jensen
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.