¿Cómo llego a la causa raíz de las llamadas de procedimiento diferido altas?

Tengo un procesador de doble núcleo, y uno de los dos está constantemente al 100%. Mirar en ProcessExplorer me muestra que son llamadas de procedimiento diferido. Leer alrededor de la red parece darme toneladas de respuestas diferentes.

¿Es posible establecer un par de pasos para tratar de reducir cuál podría ser el problema en mi caso?

Actualización 1: FWIW, el problema persiste incluso en modo seguro.

Actualización 2: desconecté todo lo que pude de la parte posterior de la PC, y eso me compró un procesador 40% más gratis. También descargué la herramienta RATTV3 , pero por alguna razón en mi máquina no me da un desglose de controlador por controlador. Hay una descripción bien de ambos DPCLatencyChecker y RATTV3 aquí .

Actualización 3: , LatencyMon (véase mi respuesta a continuación) me dice que es nvstor32.sys- que es controlador SATA de NVidia - con tiempos de alrededor de 5300 mu s.

Actualización 4: La trama se complica, mientras reflexionaba si debía intentar arrancar un disco de recuperación (para ver si realmente eran controladores y no un problema de hardware), noté que el reproductor de DVD / CD no funcionaba (es decir, ni siquiera abría el puerta cuando presiono el botón). Dado que la máquina acababa de regresar de haber reemplazado la placa base, pensé que tal vez se habían olvidado de enchufarla. Abrí la caja, todo parecía estar bien, pero lo desconecté y volví a enchufarlo. Al reiniciar, todo estuvo bien, ¡no más DPC (el más alto ahora es de 300 µs)!

Actualización 5: Al día siguiente, problema de nuevo, el reproductor de CD no funciona nuevamente, incluso el cursor en el cuadro de texto de la contraseña parpadea en cámara lenta ... Intenté desconectar todo lo que se me ocurrió, y en el segundo reinicio, funcionó nuevamente (como en Update2 ) La próxima vez intentaré desconectar completamente el reproductor de CD ...

Actualización 6: Acabo de notar que el registro de eventos del sistema muestra nvstor32.sysun mensaje de error Parity error detected in \Device\RaidPort0y luego una advertencia sobre el envío de una reinicialización. Ahora solo tengo que averiguar cuál RaidPort0es ... (tenga en cuenta que no tengo una configuración RAID, solo es un Acer estándar). Ah, y mi configuración de Avast aparentemente murió cuando hice un Rollback del sistema (o como se llame), porque no se inicia (error RPC), no se desinstala (se ha producido un error de configuración).

Actualización 7: Finalmente tuve tiempo de reiniciar con DVD desconectado. ¡No más problemas de DPC! (muchas fallas de página, pero eso es para más adelante). Siguiente paso: averigua si es el cable o el reproductor de DVD.

Actualización 8: tomó prestado un cable SATA, arrancó con él, sin problemas. El reproductor de CD / DVD funciona, no hay problemas de DPC nvstor32.sys, no hay procesadores bloqueados. Final feliz ... casi: todavía tengo problemas con Avast, problemas aparentes de DPC con el storport.sysinicio (¿tal vez normal para USB?) Y muchas fallas de página difíciles. Pero esos serán el tema de otras preguntas.

Postdata: recientemente comencé a tener el mismo problema y, usando el mismo método, logré rastrearlo hasta una memoria USB (la que estaba usando para ReadyBoost) que estaba siendo disparada.

Aquí está la historia de cómo encontré la causa de mi alta latencia DPC.

Mi sistema estaba experimentando clics y estallidos durante la reproducción de sonido. Sabía que esto significaba que algo en modo kernel estaba acaparando la CPU. Mi primer pensamiento fue hurgar en Process Explorer y ver si algo parecía fuera de lugar. Lo único que me llamó la atención fue una cantidad excesiva de tiempo dedicado a realizar llamadas de procedimiento diferido (DPC):

Sabía que los DPC son código que se ejecuta dentro de un controlador; El desafío era averiguar qué conductor. Me dirigí al DPC Latency Checker , que me mostró cuán grave era la latencia:

DPC Latency Checker sugiere pasar por dispositivos en el Administrador de dispositivos y deshabilitar el hardware no esencial uno por uno (por ejemplo, tarjeta de red, tarjeta de sonido), con la esperanza de aislar el controlador con errores. (Si desactiva un dispositivo, y la latencia DPC cae repentinamente: ¡ha encontrado a su culpable!)

Desafortunadamente, después de deshabilitar todo lo que pude (mientras todavía puedo usar la computadora, ¡no deshabilite su disco duro, tarjeta de video, mouse o concentrador USB en el que está conectado el mouse!), La latencia aún era alta. A continuación, recurrí al Kit de herramientas de rendimiento de Windows (parte del SDK de Windows ) y a una excelente publicación de blog de Peter Weiland, "Medición del tiempo de DPC" . Después de instalar Windows Performance Toolkit:

Abrí un símbolo del sistema elevado y ejecuté:

>xperf -on Latency

Nota : El Latency grupo es un conjunto predefinido de eventos que se pueden rastrear desde el proveedor del Grupo 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
   ...

En este caso Latencycorresponde a las Banderas del Kernel:

• PROC_THREAD Proceso y subproceso crear / eliminar
• CARGADOR Kernel y modo de usuario Eventos de carga / descarga de imágenes
• PERFIL CPU Perfil de muestra
• Interruptor de contexto CSWITCH
• DPC DPC Events
• INTERRUPCIÓN Eventos de interrupción
• DISK_IO Disk I / O
• HARD_FAULTS Fallas de página dura

Después de dejar que se ejecute por un minuto, detuve el seguimiento y lo guardé en un archivo:

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

Y luego vi los resultados de la traza con el comando:

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

Esto carga el analizador gráfico de rendimiento de Windows . Al hacer clic derecho en el gráfico de uso de CPU de DPC , seleccioné la tabla de resumen . Esto muestra un desglose del tiempo pasado en DPC por conductor:

De inmediato puedo ver un controlador ( tsvp.sys) que toma un promedio de 2.8 ms por ejecución de DPC, que es un orden de magnitud más lento que cualquier otro controlador:

Google tsvp.sysme dio la respuesta: CommView , que había instalado recientemente.

La pregunta ahora es cómo deshabilitar este controlador. Usando AutoRuns , puedo ver que está instalado como un servicio de controlador:

Con el Administrador de dispositivos, puedo desactivar el servicio que aloja este controlador. Primero tiene que mostrar los dispositivos ocultos , luego expanda el Non-Plug and Play Driversnodo:

Finalmente pude detener el servicio del controlador, y cambié su modo de inicio de System(lo que significa que el controlador es una parte esencial de Windows, y Windows no puede arrancar sin él), a Demand(lo que significa que puedo iniciar el controlador cuando quiera):

Detener el servicio del controlador solucionó de inmediato mi latencia DPC:

Puedo o no desinstalar completamente CommView, pero por ahora he resuelto el caso de la alta latencia de DPC.

Actualización : a partir de Windows 8 ya no puede ver los controladores que no son Plug and Play en el Administrador de dispositivos :

Nota A partir de Windows 8 y Windows Server 2012, el Administrador Plug-and-Play ya no crea representaciones de dispositivos para dispositivos que no sean PnP (heredados). Por lo tanto, no hay tales dispositivos para ver en el Administrador de dispositivos. Para incluir dispositivos ocultos en la pantalla del Administrador de dispositivos, haga clic en Ver y seleccione Mostrar dispositivos ocultos.

Microsoft eliminó la función y la reemplazó por nada. Buen trabajo.

En la típica ira nerd, algunas respuestas inútiles :

• El administrador de dispositivos nunca mostró controladores que no sean PNP
• ¿Por qué necesitas esto?

Afortunadamente, NirSoft ha creado un reemplazo. ServiWin le permite ver, detener e iniciar todos los servicios (incluso los que Microsoft decidió que los administradores deberían poder ver):

INFORME DE PROGRESO

La mejor herramienta que he encontrado hasta ahora es LatencyMon , que básicamente hace todo lo que hacen las dos herramientas anteriores, sin hacerte pensar. La página de descarga le pide que se registre por correo electrónico, pero no me sucedió nada cuando hice eso, pero puede desplazarse hasta la parte inferior de la página para descargar de todos modos.

En mi caso, utilicé LatencyMon (de la respuesta de Benjol) y descubrí que el conductor congelaba la vida, el universo y todo era (también) storport.sysque es un controlador de Microsoft para " autobuses de alto rendimiento ". Eso confirmó mi sospecha de que el problema estaba relacionado con IO.

También seguí adelante y miré mi Visor de eventos de Windows 7 , carpeta Registros de Windows -> Aplicación , y encontré varios lotes de errores de Volume Shadow Copy (VSS) que ocurrían cada 30 minutos a 2 horas. Sus detalles fueron así:

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

Luego comencé a investigar qué diablos es VSS y para qué se utiliza. Fui varias - páginas - sobre - VSS solución de problemas . Al revisar todos esos, tuve un gran sospechoso: mi software de respaldo CrashPlan .

Siguiendo ese ejemplo, rápidamente encontré una página que lo relaciona con los errores de VSS . Siguiendo las instrucciones allí para deshabilitar la copia de seguridad de los archivos abiertos, que usa VSS, las congelaciones, el alto uso de CPU de Kernel, etc., se extinguieron por completo. Y no me malinterpreten: ¡CrashPlan es genial! Solo que esta función no funcionaba en mi máquina.

Por cierto, esta página aquí fue LA QUE me dio el liderazgo inicial que me ayudó a encontrar la causa raíz de mis problemas. ¡Muchas gracias @Benjol y todos los demás que respondieron anteriormente! Espero que mi respuesta también ayude a otros ...

Probablemente haya un controlador de dispositivo que mantenga ocupado su sistema. Una forma de analizar esto es ejecutar el comprobador de latencia DPC . Luego deshabilite un controlador a la vez y vea si la carga de DPC baja. (El explorador de procesos también funciona).

Puede deshabilitar los controladores de dispositivo en Administración de equipos -> Administrador de dispositivos.

Siento que debo agregar mi respuesta aquí porque este problema es difícil de resolver y no siempre se debe a malos controladores o conflictos de IRQ.

Tenía una alta latencia de RPC que causaba estallidos / crujidos en mi tarjeta de sonido USB profesional. Las herramientas descritas en la respuesta aceptada no fueron útiles para identificar un controlador en particular que estaba causando un problema. La latencia se producía en varios procesos: HAL, USBPORT.SYS y el kernel de Windows. Profundizar en estos procesos no reveló un culpable obvio.

En mi caso, resultó que el problema era de nivel inferior y específico para las placas base GigaByte con ciertos conjuntos de chips y revisiones de BIOS. La solución fue desactivar Intel SpeedStep y todas las demás características específicas de la placa base que ajustaban la velocidad y el voltaje de la CPU sobre la marcha. Una vez que estas opciones se desactivaron, mi latencia RPC se corrigió inmediatamente.

Comencé a ver este error después de resolver un error de IRQ con mi controlador Ethernet nVidia 10/100/1000 que apareció al actualizar mi tarjeta gráfica a la GeForce GTX 550 Ti.

Parece que después de la actualización a los nuevos controladores GeForce 295.73 y luego de resolver el conflicto de interrupción, eliminé, dañé o desinstalé los controladores de controladores SATA / RAID nForce existentes. No uso RAID, el error aún persiste y bloqueó Vista Ultimate 64-bit de vez en cuando.

Después de probar todas las sugerencias de solución de problemas que encontré en la web, se presentó una solución simple ... Actualicé al controlador nForce SATA / RAID 15.58, pero dejé otros controladores nForce solos.

Eso me lo arregló, y ahora he resuelto todos mis conflictos de controladores. Espero que también te ayude.