Guía práctica de Process Monitor (ProcMon): identifica en 10 minutos por qué «no se lee la configuración» o aparece «ACCESS DENIED»

«Modifiqué el archivo de configuración, pero el comportamiento de la aplicación no cambia», «funciona en la máquina de desarrollo, pero en el equipo del cliente se cae justo después de arrancar», «hasta ayer funcionaba y no he tocado nada en el programa»: las solicitudes de investigación de fallos suelen llegar con esta forma. Y en muchos síntomas de este tipo, por mucho que se lea el código fuente, no se llega a la causa. Esto se debe a que qué archivo lee realmente la aplicación, qué clave del registro consulta y en qué falla lo determina el entorno de ejecución, no el código.

La herramienta que registra ese «qué ocurrió realmente» es Process Monitor (ProcMon), una herramienta de Sysinternals que Microsoft ofrece de forma gratuita. Registra en tiempo real toda la actividad del sistema de archivos, del registro y de procesos/hilos; es, por así decirlo, un grabador del registro de comportamiento de Windows, y en nuestras investigaciones de fallos es una herramienta que utilizamos con tanta frecuencia como WinDbg.¹

Sin embargo, aunque es muy potente, si se inicia sin más, aparecen miles o incluso decenas de miles de eventos por segundo, y la primera impresión suele ser «son demasiados, no se puede leer». En este artículo organizamos, desde la perspectiva del terreno de la investigación de fallos, la vía más corta para usar ProcMon en la práctica: cómo aplicar filtros, cómo interpretar la columna Result, los patrones habituales de investigación según el síntoma, las precauciones en entornos de producción y cómo diferenciarlo de otras herramientas de diagnóstico.

1. La conclusión, primero

• La pregunta que responde ProcMon es: «este proceso, cuándo, sobre qué ruta, qué hizo y qué resultado obtuvo». En pocos minutos se puede saber desde dónde se lee el archivo de configuración, en qué orden se buscaron las DLL o qué operación terminó en ACCESS DENIED.
• La forma estándar de usarlo es: «primero aplicar un Include por Process Name al proceso objetivo, y después acotar por Result a los casos anómalos». No es una herramienta pensada para leer los eventos en bruto de arriba abajo.
• En la columna Result hay muchos valores que parecen anómalos pero son normales. BUFFER OVERFLOW es un intercambio normal de la API, y NAME NOT FOUND en la mayoría de los casos es solo un paso intermedio del orden de búsqueda (capítulo 4).
• El filtro es una restricción solo de la vista; por detrás se siguen registrando todos los eventos. Al guardar el registro para entregarlo a otra persona, guárdalo con todos los eventos. Por el contrario, en capturas de larga duración, protege la memoria con Drop Filtered Events (capítulo 5).
• ProcMon no es una herramienta omnipotente. Averiguar «qué proceso tiene agarrado este archivo ahora mismo» es tarea de Process Explorer, el estado en el instante del bloqueo es tarea del volcado de memoria (crash dump), y dónde se consume la CPU es tarea de PerfView (capítulo 7).

A continuación, una tabla de referencia rápida para elegir la herramienta según el síntoma.

2. Qué es ProcMon: la instalación se completa en un minuto

Process Monitor es una de las herramientas de Sysinternals: una herramienta de monitorización que muestra en tiempo real la actividad del sistema de archivos, del registro y de procesos/hilos. Es la sucesora que integra y mejora las antiguas herramientas Filemon y Regmon, e incorpora información detallada por evento, filtros no destructivos, registro de la pila de hilos (thread stack) y registro desde el arranque (boot-time logging), entre otras funciones.¹

La instalación es sencilla. No hay instalador: basta con descargar el ZIP desde la página de descargas, descomprimirlo y ejecutar Procmon.exe. Para investigaciones urgentes, también se puede ejecutar directamente desde https://live.sysinternals.com/procmon.exe usando el servicio llamado Sysinternals Live.² En el primer inicio se pide aceptar el acuerdo de licencia, y como carga un controlador de kernel, se requieren privilegios de administrador (elevación de UAC). La explicación general de por qué se necesitan privilegios de administrador está en «Cuándo se necesitan privilegios de administrador en Windows»: las herramientas que observan eventos de todo el sistema operativo son un caso típico que «requiere elevación».

En el momento en que se inicia, comienza la captura y los eventos empiezan a fluir en pantalla. Basta con recordar tres operaciones principales.

Cada línea de evento se compone de Time (hora), Process Name (proceso), PID, Operation (operación), Path (ruta objetivo), Result (resultado) y Detail (detalle). Operation tiene una granularidad que corresponde en general a las API de Win32, como CreateFile (abrir/crear un archivo), ReadFile/WriteFile, RegOpenKey/RegQueryValue, etc. Es decir, el registro de ProcMon es la grabación de la conversación entre la aplicación y el sistema operativo, y muestra directamente la diferencia entre la «intención» y la «realidad»: la aplicación cree que está leyendo el archivo de configuración, pero en realidad lee otra ruta distinta.

3. Filtros: ProcMon es una herramienta que se lee después de acotar

Si se captura sin más, incluso con Windows en reposo fluyen miles de eventos por segundo. Se puede decir que la utilidad práctica de ProcMon depende de cómo se usen los filtros, y el método estándar consta de dos pasos.

Primer paso: acotar por proceso. Abre el diálogo de filtro con Ctrl+L y añade Process Name / is / myapp.exe / Include. También existe la opción de arrastrar el icono de mira de la barra de herramientas hasta la ventana de la aplicación objetivo, para filtrar solo ese proceso.

Segundo paso: acotar por resultado u operación. Si quieres buscar operaciones que fallan, usa Result / is not / SUCCESS / Include (muestra solo los casos anómalos). Si solo quieres ver escrituras, usa Category / is / Write / Include. Si quieres saber quién está tocando este archivo de configuración, sin acotar por proceso usa Path / contains / app.config / Include, y así sucesivamente.

En la práctica también se usa mucho el filtrado interactivo mediante clic derecho sobre la línea de evento. En cuanto encuentras una línea cercana a lo que buscas, haces clic derecho y eliges «Include ‘esta ruta’» o «Exclude ‘este proceso’», y los filtros se van acumulando sin necesidad de abrir el diálogo. La operación básica consiste en ir eliminando con Exclude las fuentes de ruido (antivirus, indexadores, etc.) y dejar solo lo que rodea a la operación buscada. También se puede usar el resaltado (Ctrl+H) como ayuda visual: permite colorear líneas con la misma expresión condicional que un filtro, así que cuando quieras «ver el flujo completo pero destacar solo los casos anómalos», usa el resaltado en lugar del filtro.

Hay tres particularidades en las que es fácil caer si no se conocen.

• El filtro acota la visualización, no el registro. Por detrás (de forma predeterminada) se siguen registrando todos los eventos, y si se quita el filtro se puede volver en cualquier momento al conjunto completo. Por esto se le llama filtro no destructivo, un diseño en el que resulta difícil que ocurra el problema de «acotar tanto que se pierda evidencia».¹
• La configuración del filtro se conserva en el siguiente inicio. Todo el mundo pasa alguna vez por la situación de preocuparse porque «no se muestra nada», cuando en realidad ha quedado el filtro de una investigación anterior. Si algo en la visualización parece raro, sospecha primero de Reset Filter (Ctrl+R) en el menú Filter.
• De forma predeterminada ya hay varios Exclude configurados. El propio ProcMon, la E/S de paginación, etc., se excluyen desde el principio. En investigaciones cuyo requisito sea «capturar todo el sistema sin omisiones», ten presente la existencia de estos filtros predeterminados.

4. Cómo interpretar la columna Result: lo que parece anómalo pero es normal

Cuando se acota con el filtro a los casos anómalos, sorprende ver que aparecen muchísimos «resultados con pinta de anómalos». Lo importante aquí es que la mayoría de los valores anómalos de la columna Result forman parte de un comportamiento normal. A continuación resumimos cómo interpretar los principales valores de Result.

De estos, los tres protagonistas de la investigación son NAME NOT FOUND, ACCESS DENIED y SHARING VIOLATION. Cada uno tiene un patrón de investigación habitual, así que en el próximo capítulo los veremos desde el lado de los síntomas.

Por el contrario, un patrón que se pasa por alto con facilidad es el de «la causa es un SUCCESS». Por ejemplo, no ha sido una ni dos veces que la respuesta a «no se refleja el archivo de configuración que corregí» resultó ser un SUCCESS al leer un archivo de configuración antiguo situado en otro lugar. Si solo se miran los casos anómalos, se pasa por alto esta «respuesta incorrecta» que se cargó con normalidad, así que lo más seguro es acotar por Path y ver todos los accesos a ese tipo de archivo, incluidos los que tuvieron éxito.

5. Patrones habituales de investigación según el síntoma

5.1 «Corregí la configuración, pero no se refleja»: identificar desde dónde se está leyendo

Si aplicas un Include con Path / contains / nombre_del_archivo_de_configuración y arrancas la aplicación, obtienes una lista de desde qué carpetas y en qué orden buscó la aplicación un archivo con ese nombre. La verdad suele ser una de las siguientes:

• Se estaba leyendo una copia bajo %APPDATA% o ProgramData, en lugar de la misma carpeta que el ejecutable (el diseño copiaba el archivo en el primer arranque)
• El acceso al registro o a carpetas del sistema desde un proceso de 32 bits sufrió la redirección de WOW64, y el lugar donde se creía estar mirando no coincidía con el lugar real
• La escritura en Program Files, la carpeta de instalación, se virtualizó (VirtualStore), y la lectura/escritura terminó convirtiéndose en otro lugar distinto

En cualquiera de los casos, con ProcMon la ruta completa aparece en Path, así que se ve de un vistazo. La cara opuesta de este problema, cómo diseñar la ubicación del archivo de configuración, la explicamos en «No solo appsettings.json: la práctica de la gestión de configuración».

5.2 «No arranca solo en este entorno»: seguir la búsqueda de DLL

Si la aplicación se cae justo después de arrancar o aparecen errores del tipo «no se encuentra la DLL», aplica un Include por proceso, añade Path / ends with / .dll y observa la cadena de NAME NOT FOUND. La búsqueda de DLL de Windows recorre las carpetas en un orden fijo, así que en el registro de ProcMon aparece tal cual la forma: «los NAME NOT FOUND se alinean siguiendo el orden de búsqueda y en algún punto hay un SUCCESS (o no se encuentra hasta el final)». La DLL culpable es la que nunca llega a un SUCCESS. A la inversa, aquí también se descubre el patrón de «hay SUCCESS, pero se está usando una DLL antigua en un lugar no deseado». Para la lógica del orden de búsqueda, léase también «El mecanismo de resolución de nombres de DLL en Windows».

El error «la clase no está registrada» relacionado con COM/ActiveX es del mismo tipo, y se observa como un NAME NOT FOUND bajo el CLSID de RegOpenKey. Los incidentes en los que, por confundir 32 y 64 bits, se consulta la vista equivocada del registro, se resuelven más rápido con ProcMon, siguiendo el procedimiento descrito en «Causas y procedimiento de verificación cuando ActiveX no funciona en Office 2024/Microsoft 365».

5.3 «Aparece ACCESS DENIED»: sospechar de con qué privilegios se está ejecutando

Cuando encuentres un ACCESS DENIED, haz doble clic en ese evento y consulta la pestaña Process. Ahí aparece con qué usuario se estaba ejecutando ese proceso, y así se descubren discrepancias como «el servicio se ejecutaba con una cuenta de servicio restringida en lugar de SYSTEM» o «solo al iniciarse desde el Programador de tareas era un usuario distinto». Si el objetivo es un archivo, contrastarlo con la ACL de esa ruta confirma la causa. Además, en los casos en los que interviene un antivirus, es frecuente ver que justo antes o después otro proceso (el motor del antivirus) toca la misma ruta, y esto también se convierte en una evidencia propia de ProcMon, gracias a que registra la secuencia temporal.

5.4 «A veces falla el procesamiento de un archivo»: buscar al causante del SHARING VIOLATION

En una violación de uso compartido, la secuencia temporal lo es todo para la investigación. Si aplicas un Include por Path y capturas sin filtrar por proceso, en las líneas anteriores y posteriores al instante del fallo aparece quién tenía abierto el mismo archivo. Los sospechosos habituales son el software de copia de seguridad, el antivirus o procesos residuales de Excel. El diseño para evitar que este conflicto llegue a producirse en la integración de archivos se resume en «Conceptos básicos del control de exclusión en la integración de archivos», y el problema de que quede un proceso de Excel residual se trata en «El problema de que EXCEL.EXE permanezca al operar Excel desde C#». Cabe añadir que si solo quieres saber «quién lo tiene agarrado en este preciso instante», la búsqueda de identificadores de Process Explorer (Ctrl+F) es más rápida que ProcMon.³

5.5 «El arranque es lento»: hacerse una idea de dónde se consume el tiempo

Si añades la columna Duration en la configuración de columnas, se ve el tiempo que tomó cada operación individual. Además, con Process Activity Summary o File Summary del menú Tools, se pueden agregar el número de operaciones y el tiempo por proceso o por archivo. Esto es suficiente para hacerse una idea de casos como «se hicieron decenas de miles de lecturas del registro durante el arranque» o «el acceso a una ruta de red se quedó esperando hasta el tiempo de espera agotado (timeout)». Sin embargo, el perfilado en profundidad de dónde se consume la CPU no es el terreno de ProcMon. Si la lentitud se debe al cómputo y no a la E/S, el relevo lo toman PerfView y dotnet-trace.

5.6 Problemas en el arranque o al iniciar sesión: el registro de arranque (boot logging)

En casos como «el servicio falla antes de iniciar sesión» o «la aplicación registrada en el inicio no arranca», donde el problema ocurre antes de que se pueda iniciar ProcMon manualmente, se usa Enable Boot Logging del menú Options. Se registran los eventos desde el inicio del arranque en el siguiente reinicio, y la próxima vez que se inicie ProcMon se pedirá guardarlos. El registro desde el arranque se ofrece como una función oficial de ProcMon,¹ y en investigaciones relacionadas con el orden de inicio o con scripts de inicio de sesión, es la única forma de observarlo.

6. Guardar y entregar el registro: cuando se pide al cliente que lo capture

En la práctica de la investigación de fallos, no es raro que el entorno donde se reproduce el problema exista únicamente en el lado del cliente. El registro de ProcMon se puede guardar como archivo PML, y al abrirlo en otra máquina se ven todas las columnas y todos los detalles, así que es posible dividir el trabajo: «que lo capture el cliente y lo analicemos nosotros». El procedimiento que solemos entregar al pedirlo tiene esta forma:

1. Ejecutar Procmon.exe como administrador y aceptar el acuerdo de licencia
2. Una vez iniciado, detener primero la captura con Ctrl+E y borrar la vista con Ctrl+X
3. Iniciar la captura con Ctrl+E y reproducir la operación que causa el problema
4. En cuanto se reproduzca (o aparezca el error), detener inmediatamente con Ctrl+E
5. En File > Save, elegir All events en lugar de Events displayed using current filter, guardar en formato PML, comprimirlo en ZIP y enviarlo

El punto clave es «All events» del paso 5. Aunque en la pantalla del cliente haya quedado un filtro, el registro en sí contiene el total de eventos, así que nosotros podemos volver a acotarlo libremente. En problemas que tardan en reproducirse o cuyo momento de aparición es impredecible, dejarlo tal cual consume memoria de forma continua, así que hay que indicar al menos una de estas dos opciones: activar Filter > Drop Filtered Events para registrar solo el proceso objetivo, o cambiar el destino de guardado a un archivo en lugar de memoria virtual con File > Backing Files. Si se deja correr toda la noche sin conocer estas dos opciones, se agota la memoria y ProcMon llega a su límite antes que el propio objeto de la investigación.

Si se quiere automatizar, también se pueden usar modificadores de línea de comandos. Con /AcceptEula se suprime el diálogo de aceptación, con /BackingFile se especifica el archivo de destino del registro, con /Runtime se indica una detención automática tras un número de segundos, y con /Terminate se finaliza un ProcMon en ejecución; combinando estas opciones se puede lograr que «cuando ocurra un incidente, el operador ejecute un solo script por lotes y quede la evidencia guardada». La idea de decidir de antemano qué evidencias recopilar en caso de incidente es común a la recopilación de volcados de memoria (crash dump) y al diseño del registro de eventos.

7. Los límites de ProcMon y cómo diferenciarlo de otras herramientas

ProcMon es una herramienta para observar «la secuencia temporal de las operaciones» y no sirve para todo tipo de investigación. En nuestras investigaciones, el reparto de roles es el siguiente.

Hay tres puntos límite en los que es fácil dudar.

• Red: ProcMon registra los eventos de conexión y envío/recepción de TCP/UDP (qué proceso se comunicó con qué destino), pero no se ve el contenido de los paquetes. Para la investigación a nivel de protocolo, recurre a Wireshark o a pktmon, la herramienta estándar de Windows.⁴
• Memoria: «El uso de memoria no deja de crecer» no se puede rastrear con ProcMon. Si es el montón administrado (managed heap), procede con la distinción entre GC y fuga de memoria; si son identificadores, con el procedimiento de investigación de fugas de identificadores.
• Pila (stack): en realidad, ProcMon también registra la pila del hilo que emitió cada evento (doble clic en el evento → pestaña Stack), y si se configuran los símbolos, se puede identificar a nivel de código «quién emitió este acceso al archivo». Llegados a este punto, se conecta directamente con el mundo de WinDbg, y cobra importancia la gestión de los símbolos (PDB).

8. Resumen: observar los hechos antes de leer el código

Lo primero que hay que hacer al investigar un fallo dependiente del entorno no es leer el código ni formular hipótesis, sino tomar un registro de lo que realmente ocurrió. ProcMon es la vía más corta para ello: con un minuto de instalación y unos minutos de captura, se obtienen hechos irrefutables sobre qué ruta se tocó, en qué orden, con qué permisos y en qué se falló. Con estos tres puntos —los dos pasos del filtro (proceso → Result), cómo leer un Result que parece anómalo pero es normal, y la entrega guardando todos los eventos— una investigación que estaba estancada en «no se reproduce en la máquina de desarrollo» puede avanzar un paso ese mismo día.

En nuestra empresa nos encargamos de la investigación de fallos cuyas condiciones de reproducción se desconocen, de preparar los procedimientos de recopilación de evidencias para incidentes que solo ocurren en el entorno del cliente, y del análisis de causas combinando ProcMon, WinDbg y PerfView. Podemos ayudar incluso desde la etapa en la que «el registro no muestra nada, pero la aplicación no funciona».

Artículos relacionados

• Leer volcados de memoria con WinDbg + SOS: introducción práctica al análisis tras la recopilación
• Identificar la lentitud con PerfView y dotnet-trace: introducción práctica a la investigación de rendimiento en .NET
• Introducción a la recopilación de volcados de memoria en Windows: WER/ProcDump/WinDbg
• El mecanismo de resolución de nombres de DLL en Windows: orden de búsqueda y SxS
• Investigación de bloqueos en cámaras industriales de funcionamiento prolongado: parte de fuga de identificadores

Áreas de consultoría relacionadas

En KomuraSoft LLC (合同会社小村ソフト) nos encargamos de la investigación de causas de fallos dependientes del entorno y difíciles de reproducir, de preparar los procedimientos de recopilación de evidencias en caso de incidente, y del apoyo en la resolución de problemas de aplicaciones Windows existentes.

• Investigación de fallos y análisis de causas
• Consultoría técnica y revisión de diseño
• Modificación y mantenimiento de software Windows existente
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Es seguro ejecutar ProcMon en un entorno de producción?

En la práctica, una captura de corta duración se realiza con frecuencia, pero no es incondicionalmente segura. ProcMon carga un controlador y registra una gran cantidad de eventos, por lo que en servidores con un volumen alto de eventos consume CPU y memoria de forma notable. Hay tres medidas: (1) iniciar la captura justo antes de la operación que reproduce el problema y detenerla inmediatamente después, para minimizar el tiempo de captura; (2) si se necesita una monitorización prolongada, activar Drop Filtered Events en el menú Filter para no conservar los eventos fuera del filtro; y (3) configurar Backing File para que el destino de grabación sea un archivo en lugar de memoria. Además, se recomienda someterlo al mismo proceso de aprobación que cualquier otro cambio habitual, por ejemplo ejecutándolo fuera del horario laboral o después de tomar una instantánea (snapshot).

Hay demasiados eventos y no encuentro la línea que busco. ¿Cómo debería filtrar?

Lo habitual es aplicar primero un Include por Process Name para quedarse solo con el proceso objetivo, y después acotar por Result a los casos anómalos (NAME NOT FOUND, ACCESS DENIED, etc.). Una vez que encuentres una línea que se acerque a lo que buscas, haz clic derecho sobre ella y usa las opciones Include o Exclude que aparecen para ir acotando de forma interactiva. Por el contrario, también es habitual el fallo de «guardar con el filtro aplicado y descubrir que faltaba información», así que cuando guardes el registro en un archivo para entregarlo a otra persona, ten presente que el filtro es solo una restricción de la vista y guarda todos los eventos. Además, la configuración del filtro se conserva en el siguiente inicio, así que si «no se muestra nada», sospecha primero de que ha quedado un filtro antiguo de una sesión anterior y compruébalo con Reset Filter en el menú Filter.

¿El valor BUFFER OVERFLOW en la columna Result es un indicio de un error o de un ataque?

No. No tiene relación con el ataque de desbordamiento de búfer del ámbito de la seguridad; es un intercambio normal de la API en el que «los datos necesarios eran más grandes que el búfer preparado por el llamador, así que se devolvió el tamaño requerido». Muchas API están diseñadas para llamarse primero con un búfer pequeño, obtener así el tamaño necesario, volver a reservar memoria y llamar de nuevo, así que si justo después aparece un SUCCESS en la misma ruta, no hay problema. De igual manera, NAME NOT FOUND suele ser simplemente «no se encontró en un paso intermedio del orden de búsqueda», y si finalmente hay un SUCCESS en algún punto, no es anómalo. Un Result de tipo anómalo solo puede considerarse la causa real cuando se confirma que el fallo de esa operación está causalmente conectado con el síntoma de la aplicación.

¿Cómo se diferencia el uso de Process Explorer y Process Monitor?

Process Monitor es una herramienta que registra en el tiempo «el flujo de operaciones» (cuándo, qué proceso, sobre qué ruta, qué hizo y qué resultado obtuvo), mientras que Process Explorer es una herramienta para ver «el estado en este preciso instante» (qué proceso tiene abiertos qué archivos o DLL, el uso de CPU y memoria). Por ejemplo, si quieres saber «no puedo eliminar este archivo, ¿quién lo tiene bloqueado?», la búsqueda de identificadores (handles) de Process Explorer es la vía más rápida; si quieres saber «cuándo y en qué orden lee la aplicación este archivo», es Process Monitor. En la práctica conviene tener ambas siempre a mano como parte de Sysinternals Suite, y recordar: el estado con Process Explorer, el historial con Process Monitor; así no habrá dudas.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.