Как мне найти причину высоких отложенных вызовов процедур?

19204
Benjol

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

Можно ли изложить пару шагов, чтобы попытаться сузить суть проблемы в моем случае?

Обновление 1: FWIW, проблема сохраняется даже в безопасном режиме.

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

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

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

Обновление 5: на следующий день проблема возвращается, проигрыватель компакт-дисков снова не работает, даже курсор в текстовом поле пароля медленно мигает ... Попытка отсоединить все, что я мог придумать, и при второй перезагрузке снова заработала (как в Update2 ). В следующий раз я попытаюсь полностью отключить проигрыватель компакт-дисков ...

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

Обновление 7: Наконец-то пришло время перезагрузки с отключенным DVD. Больше никаких проблем с ЦОД! (много ошибок страницы, хотя, но это на потом). Следующий шаг: выясните, если это кабель, или DVD-плеер.

Обновление 8: заимствовал кабель SATA, загрузился с ним, без проблем. CD / DVD-плеер работает, нет проблем с DPC nvstor32.sys, нет заблокированных процессоров. Хэппи-энд ... почти: у меня все еще есть проблемы с Avast, очевидные проблемы с DPC storport.sysпри запуске (может быть, нормально для USB?), И много грубых сбоев страниц. Но это будет предметом других вопросов.

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

40
Очень хорошие инструменты и помощь здесь ... http: //www.msfn.org/board/topic/140263-how-to-get-the-cause-of-high-cpu-usage-by-dpc-interrupt/ Moab 13 лет назад 3

6 ответов на вопрос

43
Ian Boyd

Here is the story of how I found the cause of my high DPC latency.


My system was experiencing clicks and pops during sound playback. I knew this meant that something in kernel mode was hogging the CPU. My first thought was to poke around Process Explorer, and see if anything looked out of place. The only thing that caught my attention was an excessive amount of time spent performing Deferred Procedure Calls (DPCs):

Screenshot of Process Explorer showing high DPC time

I knew that DPCs are code being run inside a driver; the challenge was to figure out which driver. I turned to DPC Latency Checker, which showed me just how bad the latency was:

screenshot of DPC Latency Checker

DPC Latency Checker suggests going through devices in Device Manager, and disabling non-essential hardware one-by-one (e.g. network card, sound card), hoping to isolate the buggy driver. (If you disable a device, and the DPC latency suddenly drops: you've found your culprit!)

screenshot of disabling devices

Unfortunately, after disabling everything I possibly could (while still being able to use the computer — don't disable your hard drive, video card, mouse, or USB hub the mouse is plugged into!), the latency was still high. Next I turned to the the Windows Performance Toolkit (part of the Windows SDK), and an excellent blog post by Peter Weiland, "Measuring DPC Time". After installing the Windows Performance Toolkit:

Screenshot of Windows SDK installer, with Windows Performance Toolkit being selected

I opened an elevated command prompt and ran:

>xperf -on Latency 

Note: The Latency group is a predefined set of events that can be traced from the Kernel Group provider:

>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 ... 

In this case Latency corresponds to the Kernel Flags:

  • PROC_THREAD Process and Thread create/delete
  • LOADER Kernel and user mode Image Load/Unload events
  • PROFILE CPU Sample profile
  • CSWITCH Context Switch
  • DPC DPC Events
  • INTERRUPT Interrupt events
  • DISK_IO Disk I/O
  • HARD_FAULTS Hard Page Faults

After letting that run for a minute, I stopped the trace, and had it save to a file:

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

And then I viewed the results of the trace with the command:

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

This loads the graphical Windows Performance Analyzer. Right clicking on the DPC CPU Usage graph, I selected Summary Table. This shows a breakdown of time spent in DPCs by driver:

screenshot of XPerf output

Right away I can see one driver (tsvp.sys) taking an average of 2.8ms per DPC execution, which is an order of magnitude slower than any other driver:

screenshot

Googling tsvp.sys gave me the answer: CommView, which I had recently installed.

The question now is how to disable this driver. Using AutoRuns, I can see that it's installed as a driver service:

screenshot of autoruns

Using Device Manager, I can disable the service that hosts this driver. First you have to Show hidden devices, then expand the Non-Plug and Play Drivers node:

screenshot of device manager

Finally I could stop the driver service, and I changed it's startup mode from System (meaning the driver is an essential part of Windows, and Windows cannot boot without it), to Demand (meaning I can start the driver when I want to):

screenshot of device manager

Stopping the driver service immediately fixed my DPC latency:

screenshot

I may or may not completely uninstall CommView, but for now I've solved the Case of the High DPC Latency.


Update: Starting with Windows 8 you can no longer see Non-Plug and Play Drivers in Device Manager:

Note Starting with Windows 8 and Windows Server 2012, the Plug-and-Play Manager no longer creates device represetnations for non-PnP (legacy) devices. Thus there are no such devices to view in the Device Manager. To include hidden devices in Device Manager display, click View and select Show Hidden Devices.

Microsoft took away the feature and replace it with nothing. Good job.

In typical nerd rage, some unhelpful answers:

  • Device manager never showed non pnp drivers
  • Why do you need this?

Fortunately, NirSoft has created a replacement. ServiWin lets you see, stop, and start all services (even the ones Microsoft decided administrators should be allowed to see):

screenshot of ServiWin

13
Benjol

ОТЧЕТ О ПРОГРЕССЕ

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

альтернативный текст

6
Chuim

В моем случае я использовал LatencyMon (из ответа Бенджола) и обнаружил, что драйвер зависает, вселенная и все остальное (также) storport.sysявляется драйвером Microsoft для « высокопроизводительных шин ». Это подтвердило мое подозрение, что проблема связана с IO.

Я также пошел дальше и посмотрел на мою Windows 7 Event Viewer, папку « Журналы Windows -> Приложение», и обнаружил несколько пакетов ошибок из Volume Shadow Copy (VSS), происходящих каждые 30 минут до 2 часов. Они детали были такими:

Volume Shadow Copy Service error: Error calling a routine on the Shadow Copy Provider . Routine returned E_INVALIDARG. Routine details GetSnapshot(,000000000023C850).   Operation: Get Shadow Copy Properties  Context: Execution Context: Coordinator 

Затем я начал исследовать, что такое VSS и для чего он используется. Подхожу несколько - страниц - о - VSS устранения неполадок . Проходя через все это, у меня был один большой подозреваемый: мое программное обеспечение для резервного копирования CrashPlan .

Следуя этому примеру, я быстро нашел страницу, связывающую его с ошибками VSS . Следуя инструкциям там, чтобы отключить резервное копирование открытых файлов, которые используют VSS, зависания, высокая загрузка ЦП ядра и т. Д. Полностью исчезли. И не поймите меня неправильно: CrashPlan великолепен! Просто эта функция не работает на моей машине.

Кстати, эта страница прямо здесь была ОДНОЙ, которая дала мне первоначальное руководство, которое помогло мне найти основную причину моих проблем. Большое спасибо @Benjol и всем, кто ответил ранее! Я надеюсь, что мой ответ также поможет другим ...

Спасибо Chuim, что, возможно, моя точная проблема тоже, я работал над решением этой проблемы в течение нескольких недель, и, наконец, я сузил ее до VSS и storport.sys, но не смог найти основную причину (CrashPlan резервное копирование открытых файлов), пока Ваше сообщение. Я еще не уверен, исправит ли это, но это лучшее преимущество, которое я когда-либо имел для высоких задержек DPC! Matt Palmerlee 11 лет назад 0
Я только что проверил, что настройка параметров аварийного плана, чтобы не создавать резервные копии открытых файлов, работала! Спасибо! Теперь я могу играть в Skyrim без ужасных звуковых пауз и глюков! Matt Palmerlee 11 лет назад 0
Просто хочу добавить, что я испытывал заикание звука после новой сборки ПК и обнаружил, что Crashplan также был виновником. Нашел этот ответ через http://www.computercabal.com/2012/07/debugging-audio-skipping-lagging.html. Спасибо всем за проделанную огромную работу, чтобы выследить это! chucknelson 10 лет назад 0
4
Andomar

Вероятно, есть драйвер устройства, который поддерживает вашу систему. Один из способов проанализировать это - запустить программу проверки задержки DPC . Затем отключите один драйвер за раз и посмотрите, снизится ли загрузка DPC. (Process Explorer также работает.)

Вы можете отключить драйверы устройств в «Управление компьютером» -> «Диспетчер устройств».

спасибо, я собираюсь читать по этой ссылке. Извините за мое невежество, но какие устройства я могу безопасно отключить без «отключения ветки» (например, клавиатура, экран, мышь и т. Д.)? Benjol 13 лет назад 0
Не уверен, что мои основные подозреваемые будут службы сторонних разработчиков. Я просто попробую, если что-то пойдет не так, вы можете загрузиться в безопасном режиме и снова включить драйверы. Andomar 13 лет назад 1
Хорошо, я вижу, что эта страница содержит список драйверов, которых следует избегать. Надеюсь, это не один из них. Benjol 13 лет назад 0
До этого, я думаю, что я собираюсь попробовать загрузиться с диска восстановления - если я * все еще * получаю проблему, это, скорее всего, аппаратная вещь? Benjol 13 лет назад 0
+1 для проверки латентности. По моему опыту, наиболее распространенным виновником здесь является драйвер для беспроводной сетевой карты. Shinrai 13 лет назад 1
3
Alex

I feel I should add my answer here because this issue is difficult to solve and not always down to bad drivers or IRQ conflicts.

I had high RPC latency that were causing pops/crackles in my pro-sumer USB soundcard. The tools described in the accepted answer were not helpful in identifying a particular driver that was causing an issue. The latency was occurring across a number of processes: HAL, USBPORT.SYS and the Windows kernel. Digging deeper into these processes did not reveal an obvious culprit.

It turned out in my case that the issue was lower-level and specific to GigaByte motherboards with certain chipsets and BIOS revisions. The solution was to disable Intel SpeedStep and all other motherboard specific features that adjusted CPU speed and voltage on the fly. Once these options were turned off my RPC latency was immediately fixed.

1
NorthAlabama

Я начал видеть эту ошибку после устранения ошибки IRQ на моем контроллере Ethernet nVidia 10/100/1000, который появился при обновлении моей видеокарты до GeForce GTX 550 Ti.

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

Попробовав все предложения по устранению неполадок, которые я нашел в Интернете, представилось простое решение ... Я перешел на nForce SATA / RAID контроллер 15.58, но оставил другие драйверы nForce в покое.

Это исправило это для меня, и теперь я решил все мои конфликты с драйверами. Надеюсь, вам это тоже поможет.

Похожие вопросы