Лучший отвечающий
100% загрузка одного из четырех ядер процессора

Вопрос
-
Здравствуйте.
Windows 10 1903 планшетный компьютер ThinkPad10 CPU IntelAtom Z3795\4gb\128gb прошивка 1.49 (последняя) через час после включения машинки внезапно первое ядро загружается на 100% системным процессом interrupts, после перезагрузки ситуация не повторяется. В отчете системного монитора все нормально. Все драйверы подписаны. В планировщике отключил приложения, срабатывающие через час. Сделал неск.ВСОДов для техподдержки антивируса, антивирус не причем. Интеловскими утилитами с офсайта гонял проц на предмет дефектов. Их нет. Как увидеть нитки процесса interrupts, которые грузят процессор? LatencyMon показывает начиная со сборки 16ХХХ до нынешней - 1903, что грузила два: файл ядра (кернел) и среды в которой оно разворачивается (забыл название файла), именно эти два файла определяют задержку по данным этой утилиты. Прогресс в сборках 10й винды упорно проходит мимо того как работают такие процессоры. Уважаемые небожители Майкрософт. Обратите на проблему внимание. Спасибо всем.- Изменено vi_ssh 27 декабря 2019 г. 23:30
27 декабря 2019 г. 23:27
Ответы
-
Где не видел ответы прорицателей от Виндовс. Ответ один либо драйвер либо железо. Значит если не драйвер, то у точно железо ) без вариантов.
Вот по этому пути и шел в течение года. Очень симптоматично. Тонны дров с различными подсистемами. Год назад в январе проблема обозначилась и в этом январе, т.е. сегодня проблема похоже решилась. Нашел таки таких же горемык как и я в сети. В панели управления иконка электропитание. Слева вкладка - действие кнопок электропитания. Внизу чекбокс - включить быстрый запуск. Так вот надо этот быстрый запуск выключить, т.е. не зачеркивать чекбокс. На скорость загрузки это никак визуально не влияет, зато позволяет установить все положенные дрова при загрузке, а не откладывать их запуск, на когда машина работает на пользователя с максимальным загрузом приложений, а винда пытается доустановить отложенные пуски, ИМХО, что собственно и заметно в виде бесконечного перегруза одного ядра.
Обратите также внимание на диспетчер задач в момент перегруза одного из ядер процессом interrupts. В потоках прочерк. Это означает что этот процесс не отражает потоки вообще. Поэтому с осторожностью советую относиться к рекомендациям якобы решивших эту проблему пользователей с помощью Process Explorer, где в процессе interrupts на вкладке потоки эти пользователи находили якобы эти грузящие ядро потоки. Их там по определению быть не должно. )))
Итог. После как убрал быстрый запуски 6часов пытал машину в разных режимах загрузки тяжелыми приложениями и в разных режимах c 100% загрузкой всех ядер и длительной стрессовой перегрузкой по температуре. Ничего у меня не получилось. Никак не хотело ядро потом перегружаться. Так что в моем случае это не дрова и не железо. Это недопиленная схема питания, т.е. кривая винда.
Всем спасибо за участие.
- Изменено vi_ssh 2 января 2020 г. 21:07
- Предложено в качестве ответа Vector BCOModerator 2 января 2020 г. 21:56
- Помечено в качестве ответа Dmitriy VereshchakMicrosoft contingent staff, Moderator 8 января 2020 г. 7:49
2 января 2020 г. 21:02
Все ответы
-
Здравствуйте,
Уточните пожалуйста, а если на момент проблемы запустить Process Explorer удается выяснить, какой процесс загружает на 100%?Avis de non-responsabilité:
Mon opinion ne peut pas coïncider avec la position officielle de Microsoft.
Bien cordialement, Andrei ...
MCP28 декабря 2019 г. 2:43Модератор -
Спасибо, сотни раз запускал explorer в момент загрузки одного ядра, всегда одно и тоже. И от админа и так.
System idle procecess - 54%
Procexp64.exe - 23%
Interrupts - 14% По ядрам первое 80-100% остальные - по мелочи. В свойствах открываю вкладку Threads - пусто.
28 декабря 2019 г. 8:36 -
Привет!
Версия 1903
Сборка ОС 18362.535. Попытка перейти на 1909 проблему не устранила. В биосе поотключал последовательно, а потом все вместе I/O блютусов, хайфаев, ..... Результат тот же. Поотключал в сетевой карте все вейкапы. Все таки впечатление, что это не уровень прерываний. Скорее это плохопрописанный драйвер.
Спасибо за заботу.
- Изменено vi_ssh 30 декабря 2019 г. 20:16
30 декабря 2019 г. 20:15 -
Уровень не аппаратных прерываний имелось ввиду ).30 декабря 2019 г. 20:17
-
LatencyMon показывает начиная со сборки 16ХХХ до нынешней - 1903, что грузила два: файл ядра (кернел) и среды в которой оно разворачивается
Начните с обновления биоса и прошивок других устройств, какие найдете.
Поддержка Леново что отвечает?
1 января 2020 г. 19:41Модератор -
Спасибо за советы. Биос был обновлен до последней версии заводским менеджером (есть такая опция у них на сайте) Также в поддержке есть опция проверки и установки последних дров, что и было сделано. На настоящий момент все обновлено. Однако проблема сохраняется. Попытался найти в единой драйверной базе Майкрософт что-нибудь подходящее. Два, три драйвера звуковых попробовал - не та платформа, вообщем там бардак. Начал откатываться назад до уровня изначально рекомендованных с офсайта дров. В безопасном режиме (в обычном все нормально) нашел неск.воскл.знаков )). Таблица звуков Майкрософт и т.д. Все это отключил. Отодвинул спящий режим на 3 часа, чтоб на него не грешить. В менеджере событий никакого криминала. Так, ошибки по мелочи с местом расположения логов. Крик души: вот что изменилось с 95й винды до сих пор, тот же кривой реестр и ни единой нет нормальной утилиты по событиям. Все про прежнему "в ручном режиме поиска". Если бы не обновы по дырам, откатился бы на 7ку и провались эта 10ка.2 января 2020 г. 10:25
-
Не могу понять почему винда не видит проблему. Но ведь если interrupts вдруг начинает отьедать 14% ресурса проца, все это видят, а винда нет???2 января 2020 г. 10:47
-
Где не видел ответы прорицателей от Виндовс. Ответ один либо драйвер либо железо. Значит если не драйвер, то у точно железо ) без вариантов.
Вот по этому пути и шел в течение года. Очень симптоматично. Тонны дров с различными подсистемами. Год назад в январе проблема обозначилась и в этом январе, т.е. сегодня проблема похоже решилась. Нашел таки таких же горемык как и я в сети. В панели управления иконка электропитание. Слева вкладка - действие кнопок электропитания. Внизу чекбокс - включить быстрый запуск. Так вот надо этот быстрый запуск выключить, т.е. не зачеркивать чекбокс. На скорость загрузки это никак визуально не влияет, зато позволяет установить все положенные дрова при загрузке, а не откладывать их запуск, на когда машина работает на пользователя с максимальным загрузом приложений, а винда пытается доустановить отложенные пуски, ИМХО, что собственно и заметно в виде бесконечного перегруза одного ядра.
Обратите также внимание на диспетчер задач в момент перегруза одного из ядер процессом interrupts. В потоках прочерк. Это означает что этот процесс не отражает потоки вообще. Поэтому с осторожностью советую относиться к рекомендациям якобы решивших эту проблему пользователей с помощью Process Explorer, где в процессе interrupts на вкладке потоки эти пользователи находили якобы эти грузящие ядро потоки. Их там по определению быть не должно. )))
Итог. После как убрал быстрый запуски 6часов пытал машину в разных режимах загрузки тяжелыми приложениями и в разных режимах c 100% загрузкой всех ядер и длительной стрессовой перегрузкой по температуре. Ничего у меня не получилось. Никак не хотело ядро потом перегружаться. Так что в моем случае это не дрова и не железо. Это недопиленная схема питания, т.е. кривая винда.
Всем спасибо за участие.
- Изменено vi_ssh 2 января 2020 г. 21:07
- Предложено в качестве ответа Vector BCOModerator 2 января 2020 г. 21:56
- Помечено в качестве ответа Dmitriy VereshchakMicrosoft contingent staff, Moderator 8 января 2020 г. 7:49
2 января 2020 г. 21:02 -
Спасибо что детально описали решение проблемы. Возможно оно кому-то сохранит год поисков.
The opinion expressed by me is not an official position of Microsoft
2 января 2020 г. 21:58Модератор