Загрузка ЦП драйвером, Windows

Здравствуйте коллеги! Есть проблема с загрузкой процессора в Windows.Дело обстоит так: у меня есть драйвер (написан на Си) и программа-подписчик драйвера (написана на С++). Когда я запускаю драйвер, а потом программу все работает верно: Диспетчер показывает загрузку ЦП на 80-95% (это нормальный результат, т.к. создается соответствующая нагрузка) и комп работает нормально. Но после 30 (примерно) минут работы показатель загруженности ЦП в Диспетчере падает до 40-50% и комп начинает жутко глючить и тормозить. Драйвер работает постоянно и сам по себе систему вообще не грузит, но когда запускаю подписчика, начинаются торможения, которые не прекращаются даже после завершения работы программы. Я так понимаю, что проблема в драйвере, а вернее в общении драйвера с программой-подписчиком со стороны драйвера (на сколько знаю, ресурсы, что используются драйверами не отображаются в Диспетчере, но ресурсы они используют, безусловно) но не могу найти баг. Подскажите пожалуйста (какие-то инструменты / программы / методы, хоть что-то)
1. Как я могу точно определить в чем действительно проблема, потому что она может быть не в драйвере или не только в драйвере (я не уверен)?.
2. Если проблема с драйвером, как я могу отловить проблемный участок кода?
Большое спасибо!

0

Я для таких вещей использую либо отладчик (в простых случаях), либо утилиту xperf
(когда проблема посерьезнее). xperf умеет собирать статистику системы по используемым
ресурсам - память, процессор, прерывания, системные вызовы, стеки потоков и т.д.,
при этом анализ представлен визуально, в виде графиков и/или диаграмм.

Статьи по использованию xperf:

Stack Walking in Xperf
https://blogs.msdn.microsoft.c... -in-xperf/

Windows Performance Toolkit – Xperf
https://blogs.msdn.microsoft.c... kit-xperf/

Xperf Basics: Recording a Trace
https://randomascii.wordpress.... g-a-trace/

Xperf является частью Windows Performance Toolkit (WPT).
WPT не распостраняется, как отдельный продукт, но его можно скачать
вместе с Windows ADK (я использовал ADK 8.1):

Windows Assessment and Deployment Kit (Windows ADK) for Windows 8.1 Update
https://www.microsoft.com/en-U... x?id=39982

1

Спасибо большое, уже изучаю. Не могли бы Вы еще подсказать, какие флаги для создания трейса лучше всего использовать конкретно в моем случае? Я использовал эту цепочку: "xperf -on PROC_THREAD+LOADER+PROFILE -stackwalk profile" -> rem Your scenario goes here… -> "xperf -d mytrace.etl", но, увы, конкретных данных о функциях я не получил, плюс что самое главное: по драйверу так ничего и не видно. Может, флаг какой-то нужен?

0

Я обычно делаю так:

Этого достаточно.

На 64-битных редакциях Windows еще требуется включить опцию DisablePagingExecutive = 1
в реестре (HKLM\System\CurrentControlSet\Control\S ession Manager\Memory Management).

Ну и для нормального анализа нужно еще символы подключить (pdb), как свои, так и Microsoft.

0

То ли я не научился пользоваться Xperf то ли что, но мне он совсем ничего не дал, функции, что текут, я не увидел. Но решил вплотную заняться драйвером. Залогировал по максимуму и через DebugView просмотрел все что можно. Мест утечки так и не нашел... Интересный факт, что во время затупа компа останавливал драйвер (он запускается как сервис), но затуп никуда не делся, по идее если бы утечку, на которую идет много проца, давал драйвер, то после его остановки, все бы должно было пройти, но нет... Сейчас вообще не представляю за что браться, что искать и в какую сторону копать...

0

Сообщение от CatDreamer То ли я не научился пользоваться Xperf то ли что, но мне он совсем ничего не дал, функции, что текут, я не увидел.

Сообщение от CatDreamer Мест утечки так и не нашел...

А при чем здесь утечки?
Ты же ищешь проблемы, связанные с высокой загрузкой проца, разве нет?
Вот и смотри в статистике xperf, сколько раз какие функции вызывались,
какой поток больше всего нагружает процессор и на каких вызовах.
Все это должно быть.

Кроме xperf, могу посоветовать еще пару вариантов решения проблемы.

1. Исключай один за другим различные компоненты твоей программы,
заменяя их "пустышками", и смотри, как ведет себя система.
Способ очень рутинный, но иногда реально помогает.

2. Можно понаставить в каждую функцию DbgPrint/WppTrace и
фиксировать как время вызова, так и счетчик обращений.
Ну а затем анализировать, какие функции чаще всего вызываются и
какие занимают больше всего времени.

0

Извините, я не точно написал сначала, потому что сам еще не знал. Дело в том, что загруженность компа происходит тогда, когда после 30 мин работы проги с драйвером и всеми модулями начинает резко расти количество используемой системой оператвы (где-то 3ГБ за 10 мин). Именно в этот момент начинаются проблемы с ЦП, я так понимаю, что она тратится на обработку этих 3 ГБ оператвы, а вернее того, что в нее выгружено. Потому я вижу решение в том, чтобы найти место, или хотя бы модуль в котором происходит или который провоцирует такую утечку. На счет DbgPrint() я его уже пробовал: залогировал весь драйвер и буквально прошелся по каждой строчке и практически только что пришел к выводу, что проблема не в драйвере. На счет "пустышок" и отрезания модулей тоже проходил: отрезал все части по очереди, которые можно отрезать, но проблема осталась .
Очень хотел найти какой-то инструмент, чтобы посмотреть под какие процессы/службы/драйвера система выделяет RAM и сколько, чтобы уже наконец определить хоть где проблема: в драйвере или проге. Может, я плохо искал, но много чего попробовав, все оказалось не тем, что мне надо. Может что-то посоветуете для такой цели?

0

Посмотри здесь, может что-нибудь найдешь полезное:

Finding Memory Leaks Using the CRT Library
https://msdn.microsoft.com/en-... tx3cf.aspx

Обнаружение и локализация утечек памяти
http://rsdn.org/article/vcpp/leaks.xml

Visual Leak Detector for Visual C++ 2008-2015
https://vld.codeplex.com/

Утечки в драйвере можно выявлять с помощью Driver Verifier.
Например, если ты выделил память, а затем выгрузил его, то Driver Verifier
выбросит bug check с соответствующим кодом.

0

CRT был одним с первых шагов ... Но все ровно спасибо

0

Я открою один секрет...
Если ты пишешь на C++, используя RAII, смарт-поинтеры и другие приемы
безопасного программирования, то у тебя утечек вообще не должно быть.
Все, что выделяется в конструкторе, освобождается в деструкторе (RAII).
Вместо C-строк используем std::(w)string, вместо C-массивов - std::vector, и т.д.
При таких подходах "наступить" на утечку памяти довольно сложно...

Еще можно (в некоторых случаях) обернуть весь код, работающий с памятью,
в функции регистрации/дерегистрации: выделяем память - регистрируем адрес,
очищаем память - снимаем его регистрацию. В определенных точках можно
вставить проверки на к-во зарегистрированных адресов. Хотя это практически
то же самое, что делает Debug CRT...

0

Спасибо, буду знать на будущее

0