Як дізнатися про першопричину високих викликів відкладених процедур?

У мене двоядерний процесор, і один з двох постійно знаходиться на 100%. Переглядаючи ProcessExplorer, показує мені, що це відкладені процедури дзвінків. Читання по мережі, здається, дає мені багато різних відповідей.

Чи можна вказати пару кроків, щоб спробувати звузити, яка проблема може бути в моєму випадку?

Оновлення 1: FWIW, проблема зберігається навіть у безпечному режимі.

Оновлення 2: Я відключив все, що міг, із задньої частини ПК, і це придбало мені на 40% більше безкоштовного процесора. Я також завантажив інструмент RATTV3 , але чомусь на моїй машині він не дає мені поломки водія за водієм. Там є опис добре обох DPCLatencyChecker і RATTV3 тут .

Оновлення 3: , LatencyMon (див моя відповідь нижче) говорить мені , що це nvstor32.sys- що драйвера від NVIDIA SATA - згодом близько 5300 мкс.

Оновлення 4: Сюжет згущується, обмірковуючи, чи спробувати завантажувати диск відновлення (щоб побачити, чи справді це драйвери, а не проблема з обладнанням), я помітив, що програвач DVD / CD не працює (тобто навіть не відкриває двері, коли натискаю кнопку). Зважаючи на те, що машина просто повернулася із заміною материнської плати, я подумав, можливо, вони забули її підключити. Я відкрив коробку, все здавалося нормально, але я відключився від мережі та знову підключив її. Після перезавантаження все було добре - більше не DPC (найвищий зараз 300 мкс)!

Оновлення 5: Наступного дня повернення проблеми, програвач компакт-дисків знову не працює, навіть курсор у текстовому вікні пароля блимає повільним режимом ... Спробував відключити все, про що я міг придумати, а під час другої перезавантаження знову працював (як у Update2 ). Наступного разу я спробую повністю відключити програвач CD ...

Оновлення 6: Щойно помічений системний журнал подій nvstor32.sysвидає повідомлення про помилку Parity error detected in \Device\RaidPort0, а потім попередження про надсилання повторної ініціалізації. Тепер просто потрібно розібратися, який з них RaidPort0... (зауважте, у мене немає налаштування RAID, це просто болотний стандарт Acer). О, і моє налаштування Avast, мабуть, загинуло, коли я робив системний відкат (або як там його називають), оскільки він не запуститься (помилка RPC), не видалиться (сталася помилка setiface).

Оновлення 7: Нарешті отримав час для перезавантаження з відключеним DVD. Більше проблем з DPC немає! (Хоча багато помилок на сторінці, але це на потім). Наступний крок: опрацюйте, чи це кабель, чи програвач DVD.

Оновлення 8: Позичено кабель SATA, завантажений ним, немає проблем. Програвач CD / DVD працює, жодних проблем із DPC nvstor32.sys, процесори не заблоковані. Щасливий кінець ... майже: У мене все ще виникають проблеми з Avast, очевидні проблеми з DPC storport.sysпри запуску (можливо, це нормально для USB?) Та безліч помилок на жорсткій сторінці. Але вони будуть предметом інших питань.

Постскрипт: Нещодавно у мене почалася така ж проблема, і за допомогою того ж методу вдалося відстежити її на USB-накопичувачі (той, який я використовував для ReadyBoost).

Ось історія про те, як я знайшов причину моєї високої затримки DPC.

Під час відтворення звуку у моїй системі спостерігалися клацання та спливи. Я знав, що це означає, що щось у режимі ядра зависає процесором. Перша моя думка полягала в тому, щоб розібратися навколо Process Explorer і побачити, чи щось виглядає не на місці. Єдине, що привернуло мою увагу - це надмірна кількість часу, витраченого на виконання дзвінків із відкладеними процедурами (DPC):

Я знав, що DPC - це код, який виконується всередині драйвера; викликом було розібратися, який водій. Я звернувся до перевірки затримки DPC , який показав мені, наскільки погані затримки:

DPC Latency Checker пропонує перейти через пристрої в диспетчері пристроїв та відключити одне за одним неістотне обладнання (наприклад, мережева карта, звукова карта), сподіваючись виділити драйвер помилок. (Якщо ви відключите пристрій, а затримка DPC раптом знижується: ви знайшли свого винуватця!)

На жаль, після відключення всього, що я, можливо, міг (поки все ще вміло користуватися комп’ютером - не відключайте жорсткий диск, відеокартку, мишу чи концентратор USB, до яких миша підключається!), Затримка все ще була великою. Далі я звернувся до інструментарію Windows Performance Toolkit (частина Windows SDK ) та відмінного допису блогу Петра Вайленда «Вимірювання часу DPC» . Після встановлення інструментарію Windows Performance Toolkit:

Я відкрив піднесений командний рядок і побіг:

>xperf -on Latency

Примітка . Latency Група - це попередньо визначений набір подій, які можна простежити у постачальника групи Kernel :

>xperf -providers kg
   Base           : PROC_THREAD+LOADER+DISK_IO+HARD_FAULTS+PROFILE+MEMINFO
   Diag           : PROC_THREAD+LOADER+DISK_IO+HARD_FAULTS+DPC+INTERRUPT+CSWITCH+PERF_COUNTER+COMPACT_CSWITCH
   DiagEasy       : PROC_THREAD+LOADER+DISK_IO+HARD_FAULTS+DPC+INTERRUPT+CSWITCH+PERF_COUNTER
   Latency        : PROC_THREAD+LOADER+DISK_IO+HARD_FAULTS+DPC+INTERRUPT+CSWITCH+PROFILE
   ...

У цьому випадку Latencyвідповідає прапорам ядра:

• PROC_THREAD Обробити і видалити нитку
• ЗАВАНТАЖЕННЯ Ядро та режим користувача Події завантаження / вивантаження зображення
• PROFILE CPU Приклад профілю
• Контекстний перемикач CSWITCH
• Події DPC DPC
• INTERRUPT Переривання подій
• DISK_IO Дисковий вхід / вивід
• HARD_FAULTS Помилки на жорсткій сторінці

Відпустивши цей хв на хвилину, я зупинив трасування і зберіг його у файл:

C:\Users\Ian\Desktop\xperf -d thingy1.etl

А потім я ознайомився з результатами трасування за допомогою команди:

C:\Users\Ian\Desktop\xperf thingy1.etl

Це завантажує графічний аналізатор продуктивності Windows . Клацнувши правою кнопкою миші на графіку використання процесора DPC , я вибрав Зведену таблицю . Це показує розподіл часу, проведеного у DPC водієм:

Відразу я бачу, як один драйвер ( tsvp.sys) приймає в середньому 2,8 мс за виконання DPC, що на порядок повільніше, ніж будь-який інший драйвер:

Гуглінг tsvp.sysдав мені відповідь: CommView , який я нещодавно встановив.

Тепер питання полягає в тому, як відключити цей драйвер. Використовуючи функцію AutoRuns , я бачу, що вона встановлена ​​як послуга драйвера:

Використовуючи Диспетчер пристроїв, я можу відключити службу, що розміщує цей драйвер. Спочатку потрібно показати приховані пристрої , а потім розгорнути Non-Plug and Play Driversвузол:

Нарешті, я міг зупинити службу драйверів, і я змінив режим запуску з System(тобто драйвер є важливою частиною Windows, і Windows не може завантажуватися без нього), на Demand(тобто я можу запустити драйвер, коли хочу):

Припинення служби водія негайно виправило мою затримку DPC:

Я можу або не можу повністю видалити CommView, але поки що я вирішив справу із затримкою високого рівня DPC.

Оновлення . Починаючи з Windows 8, ви більше не можете бачити драйвери, що не підключаються та відтворюють, у Диспетчері пристроїв :

Примітка Починаючи з Windows 8 та Windows Server 2012, диспетчер підключення та відтворення більше не створює перенастроювання пристроїв для пристроїв, що не належать до PnP (застарілі). Таким чином, у Диспетчері пристроїв немає таких пристроїв для перегляду. Щоб включити приховані пристрої в дисплей Диспетчера пристроїв, натисніть Переглянути та виберіть Показати приховані пристрої.

Microsoft забрала функцію і замінила її нічим. Хороша робота.

У типовій душевній люті кілька недобрих відповідей :

• Диспетчер пристроїв ніколи не показував драйвери, що не належать до ПК
• Навіщо вам це потрібно?

На щастя, NirSoft створив заміну. ServiWin дозволяє бачити, зупиняти та запускати всі сервіси (навіть ті, які Microsoft вирішив, що адміністраторам слід дозволити бачити):

ДОПОВІДЬ ПРО ХІД РОБОТИ

Найкращий інструмент, який я знайшов поки що, це LatencyMon , який в основному робить все, що роблять попередні два інструменти, не змушуючи замислюватися. Сторінка для завантаження просить вас зареєструватися електронною поштою, але в мене нічого не сталося, коли я це зробив - але ви можете прокрутити внизу сторінки, щоб завантажити все одно.

У моєму випадку я використав LatencyMon (з відповіді Бенжола) і виявив, що драйвер замерзає життя, Всесвіт і все, що було (також), storport.sysщо є драйвером Microsoft для " високоефективних автобусів ". Це підтвердило мою підозру, що проблема пов’язана з IO.

Я також пішов вперед і переглянув свій переглядач подій Windows 7 , папку Журнали Windows -> Додаток , і виявив кілька пакетів помилок з копією тону (VSS), що трапляються кожні 30 хв до 2 годин. Вони деталі були такими:

Volume Shadow Copy Service error: Error calling a routine on the Shadow Copy Provider {b5946137-7b9f-4925-af80-51abd60b20d5}. Routine returned E_INVALIDARG. Routine details GetSnapshot({00000000-0000-0000-0000-000000000000},000000000023C850). 

Operation:
   Get Shadow Copy Properties

Context:
   Execution Context: Coordinator

Тоді я почав досліджувати, що за чорта є VSS і для чого він використовується. Підходжу кілька - сторінок - про - ВСС усунення неполадок . Переглядаючи все те, у мене був один великий підозрюваний: моє резервне програмне забезпечення CrashPlan .

Слідуючи цим посиланням, я швидко знайшов сторінку, пов’язану з нею з помилками VSS . Дотримуючись вказівок щодо відключення резервного копіювання відкритих файлів, в яких використовується VSS, заморозки, високе використання процесора ядра тощо були повністю вимерлими. І не зрозумійте мене неправильно: CrashPlan - це чудово! Просто ця функція не працювала на моїй машині.

До речі, ця сторінка тут була ТИМОЮ, яка дала мені першочергове керівництво, яке допомогло мені знайти першопричину моїх проблем. Велике спасибі @Benjol та всі інші, що відповіли раніше! Сподіваюся, моя відповідь допоможе і іншим ...

Напевно, існує драйвер пристрою, який підтримує вашу систему. Один із способів проаналізувати це - запустити перевірку затримки DPC . Потім відключіть один драйвер за раз і побачите, чи знижується навантаження DPC. (Провідник процесів також працює.)

Ви можете відключити драйвери пристроїв у програмі Керування комп'ютером -> Диспетчер пристроїв.

Я вважаю, що тут слід додати свою відповідь, оскільки це питання важко вирішити і не завжди зводиться до поганих конфліктів драйверів або IRQ.

У мене була висока затримка RPC, яка спричиняла спливи / тріщини в моїй звуковій картці USB-накопичувача. Інструменти, описані у прийнятій відповіді, не допомогли визначити конкретного драйвера, який спричинив проблему. Затримка виникала в багатьох процесах: HAL, USBPORT.SYS та ядра Windows. Поглиблення в ці процеси не виявило очевидного винуватця.

У моєму випадку виявилося, що випуск був нижчим рівнем і був специфічним для материнських плат GigaByte з певними наборами чіпсетів та переглядами BIOS. Рішення полягало в тому, щоб відключити Intel SpeedStep та всі інші особливості материнської плати, які коригували швидкість та напругу процесора на ходу. Як тільки ці параметри було вимкнено, затримка RPC була негайно виправлена.

Я почав бачити цю помилку після усунення помилки IRQ за допомогою мого контролера nVidia 10/100/1000 Ethernet, який з’явився під час оновлення моєї відеокарти до GeForce GTX 550 Ti.

Здається, після оновлення до нових драйверів GeForce 295.73, а потім вирішення конфлікту переривання, я видалив, пошкодив або видалив існуючі драйвери контролера nForce SATA / RAID. Я не використовую RAID, помилка все ще зберігається і час від часу блокується 64-розрядний Vista Ultimate.

Після випробування всіх пропозицій щодо усунення несправностей, які я знайшов в Інтернеті, просте рішення представилося… Я перейшов на nForce SATA / RAID-контролер 15.58, але залишив інші драйвери nForce в спокої.

Це вирішило це для мене, і я тепер вирішив усі мої конфлікти з водієм. Сподіваюся, це теж допоможе вам.