Drivers & Software
I was checking my Windows Logs and see the following under System:
Error application name: cpumetricsserver.exe, version: 10.1.2.1884, timestamp: 0x615c7dd8
Faulting module name: cpumetricsserver.exe, version: 10.1.2.1884, timestamp: 0x615c7dd8
Exception Code: 0xc0000409
Margin of Error: 0x00000000000076bc
Error process ID: 0x1f78
Application start time with error: 0x01d7c71b772ebee7
Faulting application path: C:\Program Files\AMD\CNext\CNext\cpumetricsserver.exe
Faulting module path: C:\Program Files\AMD\CNext\CNext\cpumetricsserver.exe
Report ID: c9b50e4e-150d-4a8b-a231-38fe19896d64
Full package name with error:
After a short research i found out that «cpumetricsserver.exe» is from AMD Radeon.
cpumetricsserver.exe crashes at every computer startup.
This started occurring after the 21.10.2 Radeon software update.
I believe that has to do with AMD new feature Performance Monitoring which is part of AMD Overlay Menus: https://www.amd.com/en/support/kb/faq/dh-026
I installed both Windows 10 & Windows 11, but this issue (cpumetricserver.exe), happens only in Windows 11.
on Windows 10, it’s all good
In Adrenalin s/w Turn of all overlays, You really don’t need it and it is known to cause more trouble than benefits.
And while You’re are at it, turn off hotkeys as well, since it interferes with customized games and other s/w action keys.
Usually I’m using Radeon Chill to set min and max fps and to get a nice cool & quiet gaming experience while playing all my games at ultra settings.
How it is while playing Assassins Creed Odyssey and every setting maxed out +120% on the Resolution Modifier and it looks similar with AC Valhalla except that more ampere (A) is drawn and SAM can be fully utilized with AC Valhalla:
My Gpu has two temp sensors and this is on my second monitor.
If you would like to record or broadcast your game play: do Not use Adrenalin s/w for that, instead use OBS which is free and remember to change one important setting while playing games:
GPU h/w to s/w encoder since the GPU hardware is occupied with the game engines graphics.
My rig:
GPU: ASUS TUF Gaming AMD Radeon RX 6900 XT OC 16GB
Adrenalin s/w: 21.10.2
Extended monitor setup: Gigabyte AORUS-FI27Q27″ 2560×1440 @165Hz (primary), Philips IPS 24″ 1920×1080 @60Hz.
Mobo: Asus ROG Crosshair VIII Hero (wi-fi) with AMD X570 chipset
BIOS ver. 3801 (with AGESA V2 PI 1.2.0.3 Patch C).
Chipset: amd_chipset_software_3.10.08.506
SAM: Enabled and fully functional.
CPU: AMD Ryzen 9 3950X
Ram: Corsair Vengeance low profile 16GB @3200 MHz cl16
CPU Cooler: Noctua NH-D15-Se AM4
Storage: M2 Samsung 980 Pro 2TB NWME, SSD Samsumg 950 Pro 1 TB SATA
Windows 10 Pro 21H1 with latest Windows optional update.
Best regards from Sweden
You really need to first try my suggestion above regarding disable all overlays.
cpumetricsserver.exe has an direct impact on the overlays and vice versa.
Above are the essential information that needs to be present to be able for the community to try to help.
First of all if you are using Windows 11 (but it also applies to Windows 10):
1. Make sure that you have an updated BIOS version from the manufacturer.
2. Make sure that you have an updated Windows version in particular: installed Optional updates (manually run Windows update from the settings menu).
3. Make sure that You have the latest chipset drivers:
For AMD chipset: https://www.amd.com/en/support
For Intel chipset: https://www.intel.com/content/www/us/en/support/products/46644/software/chipset-software.html
Personally I will wait at least 6 or 10 months before installing Windows 11, wise of history.
Best regards from Sweden
Svhost.exe 100%, решение которое мне помогло
Прошу не пинать сразу, но возможно это описывали. В поиске я не нашел, как в гугле, так и на пикабу.
Знаю не мало случаев, когда из-за проблем с злополучным процессом, люди не найдя точного пошагового решения сносили свою систему, и любимые программы в целях заполучить чистый, без косяков windows 7.
Я и сам работая настройщиком, не раз сталкивался с данной ситуацией, когда в диспетчере svhost.exe бушует под сотку жируя драгоценной озухой.
В интернете поиски мне предлагали проверить hosts файл, проверить систему различными антивирусами, перепроверить последние установленные программы. Но в большинстве случаев, это оказывалось бессмысленной тратой времени.
Так вот.
Долгими поисками злополучной службы грузящей систему оказалось
Служба обновления windows.
То есть, люди отрубившие обновление винды через панель управления, заблокировали доступ системе к самообновлению, что в логичность итоге должно было отрубить данную службу в параметрах системы, но увы нет. Она остаётся включенной, и усердно пытается найти обновления несмотря на указания оболочки.
Говоря проще:
Если у вас грузит свхост
Вы попробовали все (что пробовал я) в интернете и вам не помогло
Если вам не необходимы обновления, и вас все устраивает
Если вы отрубили обновления системы в центре обновления
То:
Идём в win+r msconfig службы, и отрубаем службу обновления windows.
После перезагрузки все будет ОК
Защитник Windows напугал сисадминов ложным обнаружением Emotet
Microsoft Defender for Endpoint блокирует открытие файлов и выдает ошибку, указывающую на активность, связанную с Win32/PowEmotet.
Защитное решение Microsoft Defender for Endpoint блокировало открытие документов Microsoft Office и запуск некоторых исполняемых файлов из-за ложного срабатывания тега, который помечает файлы как потенциально содержащие вредоносное ПО Emotet.
При срабатывании Microsoft Defender for Endpoint блокирует открытие файла и выдает ошибку, указывающую на подозрительную активность, связанную с Win32/PowEmotet.SB или Win32/PowEmotet.SC. Проблема затрагивает файлы Excel и любого приложения Microsoft Office, использующего MSIP.ExecutionHost.exe и splwow64.exe.
Microsoft не предоставила какую-либо информацию о причинах данной ситуации. Наиболее вероятная причина заключается в том, что компания в последних обновлениях усилила чувствительность защитного решения к обнаружению поведения, подобного Emotet.
Изменение, вероятно, было вызвано недавним « возрождением » ботнета Emotet две недели назад. Напомним, исследователи в области кибербезопасности из Cryptolaemus, GData и Advanced Intel выявили случаи, когда вредоносная программа TrickBot устанавливала на зараженные устройства загрузчик для Emotet.
Как сообщили специалисты Microsoft, они устранили проблему для пользователей, подключенных к облачным сервисам, и работают над исправлением для всех остальных.
RX 580 Мнение Мурлока и не только
Всем привет! кто-то побдеил дрова AMD? Имею RX-580 8Гб, 32 Гектара оперативы, Вин 10Прошку лицуху, последнее обновление дров на ГП и постоянные вылеты в играх, во всех, даже флешках, типа Асфальт 8
Ну давай поймем куда думать:
бублик крутит без глюков
при удаленном AMD soft вроде робит
Есть RX 5880 4 Гб с ней тот же трабл
не может на разном железе быть один глюк
БП 700Вт, в ОССТ 5.4.2. тест Повер 30 минут стабильно
Спасало запуск от админа
Имя сбойного приложения: Radeonsoftware.exe, версия: 10.1.2.1788, метка времени: 0x5e9f5ad0
Имя сбойного модуля: Radeonsoftware.exe, версия: 10.1.2.1788, метка времени: 0x5e9f5ad0
Код исключения: 0xc0000005
Смещение ошибки: 0x0000000000412967
Идентификатор сбойного процесса: 0x2f60
Время запуска сбойного приложения: 0x01d62068f59a39ee
Путь сбойного приложения: C:\Program Files\AMD\CNext\CNext\Radeonsoftware.exe
Путь сбойного модуля: C:\Program Files\AMD\CNext\CNext\Radeonsoftware.exe
Идентификатор отчета: 0082b4af-d9c5-464d-b4bb-0c3021a56476
Полное имя сбойного пакета:
Код приложения, связанного со сбойным пакетом:
Зомби, которые съедают вашу память
Что бы вы там себе не думали, а зомби существуют. И они действительно едят мозги. Не человеческие, правда, а компьютерные. Я говорю сейчас о зомби-процессах и потребляемых ими ресурсах. Это будет душераздирающая история о потерянных и снова найденных 32 ГБ оперативной памяти. Возможно, лишь некоторые из вас столкнутся с точно такой же проблемой, но если вдруг это произойдёт — у вас хотя бы будет шанс понять, что происходит.
Начнём с того, что компьютеры под управлением ОС Windows склонны со временем терять память. Ну, по крайней мере, у меня, при моём способе ими пользоваться. После пары недель без перезагрузок (или, например, всего одного уикэнда за который я 300 раз пересобрал Хром) я стал замечать, что диспетчер задач начинает показывать мне очень маленькое количество свободной оперативной памяти, но в то же время в системе нет никаких процессов, которые эту самую память активно используют. В том примере выше (с 300 сборками Хрома) диспетчер задач сказал мне, что в системе занято 49.8 ГБ плюс ещё 4.4 ГБ памяти сжато — но при этом запущено всего несколько процессов, и все они в сумме даже и близко не используют столько памяти:
В моём компьютере 96 ГБ оперативной памяти (да, я счастливчик) и когда у меня нет вообще никаких запущенных процессов — я, знаете ли, хотел бы видеть ну хотя бы половину этой памяти свободной. Я правда рассчитываю на это. Но иногда этого достичь не удаётся и мне приходится перезагружать ОС. Ядро Windows написано качественно и надёжно (без шуток), так что память не должна бы пропадать бесследно. Но всё же она пропадает.
Первой же моей догадкой стало воспоминание о том, что один из моих коллег как-то жаловался на зомби-процессы, которые иногда остаются в ОС уже не активными, но всё же ещё не до конца удалёнными ядром. Он даже написал специальную утилиту, которая выводит список таких процессов — их имена и количество. Когда он запускал эту утилиту в своих тестах, то получал до нескольких сотен зомби-процессов на обычной Windows-машине. Я нашел его инструмент, запустил на своём компьютере и получил… 506 000 зомби-процессов. Да, 506 тысяч!
Я вспомнил, что одной из возможных причин перехода процесса в состояние «зомби» может быть то, что какой-то другой процесс держит открытым его дескриптор (handle). В моём случае большое количество зомби-процессов играло мне на руку — им было сложнее скрыться. Я просто открыл диспетчер задач и добавил на вкладку Details столбец с количеством открытых дескрипторов для каждого процесса. Затем отсортировал список по убыванию значений в этом столбце. Я сразу нашел героя данной истории — процесс CcmExec.exe (часть Microsoft System Management Server) имел 508 000 открытых дескрипторов. Это было во-первых, очень много, а во-вторых, подозрительно близко к найдненному мною выше числу в 506 000 зомби-процессов.
Всё получилось ровно так, как я того и ожидал. Как я без иронии писал выше — ядро Windows написано очень хорошо и когда процесс уничтожается, то и все занятые им ресурсы освобождаются. Закрытие CcmExec.exe освободило 508 000 дескрипторов, что дало возможность окончательно закрыть 506 000 зомби-процессов. Количество свободной оперативной памяти мгновенно выросло на 32 ГБ. Тайна раскрыта!
Что такое зомби-процесс?
До этого момента мы ещё не выяснили, что же заставило все эти процессы зависнуть в неопределённости, а не быть удалёнными. Похоже на то, что мы имеем дело с тривиальным багом в приложении (а не в ядре ОС). Общее правило гласит, что когда вы создаёте процесс, то получаете его дескриптор и дескриптор его главного потока. Вы ОБЯЗАНЫ закрыть эти дескрипторы. Если вашей задачей было просто запустить процесс — их можно закрыть сразу же (это не убъёт запущенный процесс, а просто разорвёт связь вашего процесса с ним). Если новый процесс вам для чего-то нужен (например, вы ждёте окончания его работы или вам нужен код, который он вернёт) — то нужно воспользоваться соответствующими функциями (например, WaitForSingleObject(hProcess, INFINITE) для ожидания выхода или GetExitCodeProcess(hProcess, &exitCode) для получения кода возврата) и всё-равно закрыть дескрипторы после того, как вы получили от дочернего процесса всё, чего хотели. Аналогично следует и поступать и с дескрипторами процессов, которые вы для чего-нибудь открываете с помощью функции OpenProcess().
Если процесс, который забывает так поступать, относится к системным, то вам даже может не помочь выйти из своего аккаунта и снова залогиниться, только полная перезагрузка.
Куда же девается память?
500 000 раз по 32 КБ будет равно примерно 16 ГБ — куда же делась остальная память? Сравнение состояния памяти до и после закрытия зомби-процессов даёт ответ на этот вопрос:
Мы можем чётко увидеть, что
16 ГБ уходит на Process Private Memory. Также мы видит, что ещё 16 ГБ приходится на Page Table Memory. Очевидно, что каждый зомби-процесс занимает 32 КБ в таблице страниц памяти и еще 32 КБ использует для своей личной памяти. Я не знаю для чего зомби-процессу так много памяти, но, наверное, никто никогда не думал, что число таких процессов может измеряться сотнями тысяч.
Некоторые типы занятой памяти увеличились после закрытия процесса CcmExec.exe, в основном это касается Mapped File и Metafile. Я не знаю точно, почему так получилось. Одной из моих догадок является то, что ОС решила, что свободной памяти теперь достаточно и что-то себе закешировала. Это, в общем, не плохо. Мне не жаль памяти для нужд ОС, я просто не хочу, чтобы она пропадала совсем уж бесцельно.
Важное замечание: RamMap тоже открывает дескрипторы всех процессов, так что эту утилиту следует закрыть, если вы хотите добиться закрытия зомби-процессов.
Я написал твит о моей находке и исследование продолжил другой программист, который сумел воспроизвести данный баг и передать информацию о нём разработчику из Microsoft, который сказал, что это «известная проблема, которая иногда случается, когда очень много процессов запускаются и закрываются очень быстро».
Я надеюсь, что данная проблема будет скоро исправлена.
Почему у меня на компьютере возникают такие странные проблемы?
Я работаю над кодом Windows-версии Хрома и одной из моих задач является оптимизация его сборки на этой ОС, а это требует многократных запусков этой самой сборки. Каждая сборка Хрома запускает огромное множество процессов — от 28 000 до 37 000 в зависимости от выбранных настроек. При использовании нашей распределённой системы сборки (goma) эти процессы создаются и закрываются очень быстро. Мой лучший результат сборки Хрома — 200 секунд. Но столь агрессивная политика запуска процессов выявляет и проблемы в ядре Windows и её компонентах:
Что дальше?
Если вы работаете не на компьютере, управляемом политиками компании, то процесс CmmExec.exe у вас не запущен и с конкретно данным багом вы не столкнётесь. Также он коснётся вас только если вы собираете Хром или делаете ещё что-то похожее, создавая и закрывая при этом десятки тысяч процессов в короткие промежутки времени.
CcmExec — не единственная в мире программа с багами. Я нашел много других, содержащих в себе конкретно этот же тип ошибок, приводящих к созданию зомби-процессов. И есть ещё огромное множество тех, которые я не нашел.
Как знают все опытные программисты, любая ошибка, которая не была явно исправлена или предупреждена — точно когда-то произойдёт. Просто написать в документации «Пожалуйста, закройте этот дескриптор» — не достаточно. Так что вот мой вклад в то, чтобы сделать нахождение подобного типа ошибок проще, а их исправление — реальнее. FindZombieHandles — это инструмент, основанный на NtApiDotNet и коде от @tiraniddo, который выводит список зомби-процессов и информацию о том, кто сделал их зомби. Вот пример вывода данной утилиты, запущенной на моём компьютере:
274 зомби — это ещё не так плохо. Но уже и это указывает на определённые проблемы, которые могут быть найденны и исправлены. Процесс IntelCpHeciSvc.exe в этом списке имеет самые большие проблемы — похоже на то, что он открывает (и забывает закрыть) дескриптор процесса каждый раз, когда я открываю видео в Windows Explorer.
Visual Studio забывает закрыть дескрипторы как минимум двух процессов, в одном случае это воспроизводится всегда. Просто запустите сборку проекта и подождите
15 минут пока процесс MSBuild.exe закроется. Можно также выставить опцию “set MSBUILDDISABLENODEREUSE=1” и тогда MSBuild.exe закроется сразу по окончанию сборки и потерянный дескриптор будет виден сразу. К сожалению, какой-то негодяй в Microsoft исправил эту проблему и фикс должен выйти в обновлении VS 15.6, так что поторопитесь воспроизвести её, пока это ещё работает (надеюсь, не нужно объяснять, что это была шутка и никакой он на самом деле не негодяй).
Также вы можете использовать для просмотра забытых процессов программу Process Explorer, сконфигурировав её нижнюю панель так, как это показано ниже (заметьте, что в этом случае будут показаны забытые дескрипторы как для процессов, так и для потоков):
Вот пару примеров найденных багов (о некоторых сообщено разработчикам, но не о всех):
Используя Process Explorer, я заметил, что NVDisplay.Container.exe открывает
5000 дескрипторов на событие \BaseNamedObjects\NvXDSyncStop-61F8EBFF-D414-46A7-90AE-98DD58E4BC99, создавая новый дескриптор каждые две минуты. Я так понимаю, они хотят быть супер-уверены в том, что могут остановить NvXDSync? Багрепорт Nvidia отправлен.
Corsair Link Service создаёт
15 дескрипторов в секунду, не освобождает их совсем. Багрепорт отправлен.
Adobe’s Creative Cloud теряет тысячи дескрипторов (около 6500 в день, по моим подсчётам). Багрепорт отправлен.
Удивительно, что никто до этого особо не обращал внимание на подобные баги. Эй, Microsoft, возможно, стоит собирать статистику по таким случаям и что-то предпринимать по этому поводу? Эй, Intel и Nvidia, почистите немного ваш код. Помните, я наблюдаю за вами.
А теперь вы можете взять утилиту FindZombieHandles, запустить её на вашей машине и рассказать о своих находках. Также вы можете использовать в экспериментах диспетчер задач и Process Explorer.
