Cómo activar y configurar Windows Error Reporting (WER) paso a paso

Si administras equipos con Windows en tu día a día, tarde o temprano te tocará pelearte con Windows Error Reporting (WER). A veces es un aliado imprescindible para diagnosticar cuelgues y errores raros, y otras se convierte en un devorador de espacio en disco o en una fuente continua de eventos cuando el servidor no tiene salida a Internet.

En esta guía vas a ver cómo activar, desactivar y afinar al detalle WER en diferentes versiones de Windows, cómo controlar los volcados de memoria (HDMP/MDMP), qué direcciones de red usa, cómo validarlo por Registro e incluso cómo manejarlo por PowerShell y scripts por lotes. Todo explicado en español de España, con ejemplos prácticos y sin dejarte ninguna pieza suelta.

Qué es Windows Error Reporting (WER) y para qué sirve

WER es una plataforma de recopilación y envío de errores integrada en Windows que se activa cuando una aplicación se cuelga, el explorador deja de responder, falla un servicio o se producen errores graves del sistema (como fallos de kernel). En ocasiones esos fallos están relacionados con errores con aplicaciones no comprobadas que requieren pasos específicos para su diagnóstico.

Cuando eso ocurre, el sistema puede generar informes y volcados de memoria que contienen información sobre el proceso, módulos cargados, memoria en uso y otros datos técnicos. Esa información se puede enviar a Microsoft para intentar buscar soluciones conocidas o para que el equipo de producto mejore el sistema y las aplicaciones afectadas.

Además de los informes online, WER puede configurarse para guardar volcados de memoria de modo usuario de forma local, algo muy útil cuando tienes que analizar cuelgues de aplicaciones críticas, servidores sin acceso a Internet o entornos donde la privacidad de los datos es clave.

En muchas organizaciones se decide si conviene habilitar WER, restringirlo o desactivarlo por completo por la política de seguridad, el acceso a Internet o el volumen de errores que se generan en los servidores.

Habilitar Windows Error Reporting (WER) mediante directivas de grupo

En entornos de dominio lo más cómodo es controlar WER a través de GPO para que la configuración sea consistente en todos los equipos. Desde el Editor de administración de directivas de grupo (gpmc.msc) puedes activar o desactivar WER y ajustar qué se envía.

Primero hay que asegurarse de que no exista ninguna directiva que lo bloquee. Para ello, en la configuración del equipo navega hasta la ruta adecuada y revisa las políticas relacionadas con la desactivación del informe de errores.

En el árbol de directivas, accede a Configuración del equipo > Plantillas administrativas > Sistema > Administración de comunicaciones de Internet > Configuración de comunicaciones de Internet. Dentro de esta sección encontrarás la política referente a desactivar el informe de errores de Windows.

Abre la directiva llamada Desactivar Informe de errores de Windows y marca la opción “Deshabilitada”. Con ello estás indicando que no quieres que WER se bloquee a nivel de comunicaciones. Aplica los cambios con “Aplicar” y “Aceptar”.

A continuación, en el mismo Editor de directivas, entra en Configuración del equipo > Plantillas administrativas > Componentes de Windows > Informe de errores de Windows. Allí encontrarás la política Deshabilitar Informe de errores de Windows, que controla directamente si el servicio está operativo.

Abre esa directiva y vuelve a seleccionar la opción “Deshabilitada” para que WER quede formalmente habilitado en el sistema. De nuevo, confirma con “Aplicar” y “Aceptar” para que la configuración se replique a los equipos de la OU a la que se ha vinculado la GPO.

Configurar el nivel de datos de diagnóstico en Windows

El comportamiento de WER está muy ligado a la configuración de datos de diagnóstico y telemetría de Windows. Dependiendo del nivel configurado, se pueden enviar desde datos mínimos hasta información adicional que incluye volcados y registros más detallados.

Para ajustar este comportamiento se usan, de nuevo, las ramas de recopilación de datos y versiones preliminares en las directivas de grupo, con ligeras diferencias entre Windows 11 y Windows 10.

Configurar datos de diagnóstico en Windows 11

En equipos con Windows 11, abre el Editor de directivas de grupo y entra en Configuración del equipo > Plantillas administrativas > Componentes de Windows > Recopilación de datos y versiones preliminares. Aquí encontrarás varias opciones para controlar qué tipo de información se recoge y se envía.

Localiza la directiva Permitir datos de diagnóstico y ábrela. Marca la opción “Habilitada” y, en el desplegable de Opciones, selecciona Enviar datos de diagnóstico opcionales. Este nivel permite que WER y otros componentes recojan más detalles técnicos, algo muy útil en entornos de soporte y troubleshooting avanzado.

Confirma con “Aplicar” y “Aceptar” y, a continuación, busca la política Configurar la configuración de la interfaz de usuario de los datos de diagnóstico. Esta directiva sirve para determinar qué ve el usuario final en la interfaz de privacidad.

Activa esta política con “Habilitada” y elige en el desplegable la opción Deshabilitar la configuración de participación de datos de diagnóstico. De esta forma, los usuarios no podrán modificar por su cuenta el nivel de diagnóstico que hayas definido a nivel corporativo. Vuelve a aplicar y aceptar los cambios para que la política quede fijada.

Configurar datos de diagnóstico en Windows 10

En Windows 10 la ruta de configuración es similar. Debes entrar en Configuración del equipo > Plantillas administrativas > Componentes de Windows > Recopilación de datos y versiones preliminares. Dentro de esa sección se encuentra una política fundamental llamada Permitir telemetría.

Abre la directiva “Permitir telemetría” y establece su estado en “Habilitada”. En el cuadro de Opciones se ofrece una lista de niveles que varía ligeramente según la versión de Windows 10 instalada.

Para sistemas con Windows 10 versión 1903 o posterior, el valor que corresponde al nivel más detallado es “Opcional”. En cambio, para versiones Windows 10 1809 o anteriores, el nivel máximo se denomina “Completo”. Escoge la opción adecuada según el build del sistema que estés gestionando.

Guarda los cambios con “Aplicar” y “Aceptar”. A partir de aquí, y especialmente para versiones 1803 y superiores, podrás refinar aún más lo que el usuario ve en la interfaz de telemetría.

Busca después la política Configurar la configuración de la interfaz de usuario de telemetría. Habilítala y selecciona la opción Deshabilitar configuración de participación de telemetría en el desplegable de Opciones. Así bloqueas la posibilidad de que el usuario cambie la telemetría desde la configuración gráfica de Windows. De nuevo, aplica y acepta para cerrar la ventana de la directiva.

Puntos de conexión de red utilizados por WER y datos de diagnóstico

Cuando WER y los componentes de diagnóstico están activos, Windows puede conectarse a una serie de endpoints de Microsoft para enviar informes y volcados. En redes restringidas, cortafuegos perimetrales o servidores sin salida a Internet es fundamental conocer estas direcciones.

El tráfico de WER suele pasar por el puerto TCP 443 usando HTTPS con cifrado SSL/TLS, y con técnicas de anclaje de certificados para garantizar que se conecta realmente a servidores de Microsoft. Si este tráfico se bloquea, verás intentos recurrentes de conexión e incluso eventos relacionados en el visor.

Puntos de conexión más habituales a los que puede acceder WER:

• watson.microsoft.com para prácticamente todas las versiones de Windows.
• watson.telemetry.microsoft.com a partir de Windows 10 versión 1803.
• Distintos hosts de Azure Blob Storage como umwatsonc.events.data.microsoft.com o direcciones del tipo ceuswatcab01.blob.core.windows.net, eaus2watcab01.blob.core.windows.net o weus2watcab02.blob.core.windows.net, usados en versiones más modernas como Windows 10 1809 y posteriores.

Si tienes que permitir solo ciertos dominios en el firewall para que WER funcione correctamente, deberás incluir esta lista de hostnames. En escenarios aislados (por ejemplo, servidores sin Internet) es habitual desactivar el envío o limitarlo estrictamente para que el sistema no insista en conectar a estos endpoints.

Limitar el tipo de datos adicionales que se envían a Microsoft

Aunque WER esté habilitado y los datos de diagnóstico se permitan en modo opcional, es posible que quieras controlar qué tipo de volcados de memoria se comparten con Microsoft por motivos de confidencialidad o cumplimiento normativo.

Las políticas descritas en las secciones anteriores pueden hacer que WER solo remita minivolcados de kernel y volcados ligeros de modo usuario. Sin embargo, si has optado por el nivel de datos opcionales, puedes ajustar todavía más estos límites usando directivas adicionales.

En Windows 11 y en Windows 10 a partir de la versión 1909, ve de nuevo a Configuración del equipo > Plantillas administrativas > Componentes de Windows > Recopilación de datos y versiones preliminares. En esa sección encontrarás políticas específicas para acotar los tipos de volcados.

Abre la directiva Limitar colección de volcados de memoria y ponla en estado “Habilitada”. De esta forma, solo se recogerán los volcados permitidos por la política, evitando capturas excesivamente grandes o con demasiada información sensible. Aplica y acepta la configuración.

A continuación, busca la directiva Limitar recopilación de registros de diagnóstico. Habilítala también para restringir el volumen y el tipo de registros que se incluyen en la telemetría asociada. Tras seleccionar “Habilitada”, pulsa “Aplicar” y “Aceptar” para guardar definitivamente los cambios.

Verificar la configuración correcta mediante el Registro

Una vez que has desplegado las GPO que controlan WER y los datos de diagnóstico, es recomendable validar en una máquina de prueba que las claves de Registro se han aplicado tal y como esperas. Para ello puedes usar regedit.exe en un equipo afectado por la política.

En primer lugar, comprueba la clave HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DataCollection. Aquí deberían reflejarse los valores que hayas definido para telemetría y restricciones de recopilación.

Algunos valores típicos que suelen aparecer en esta clave son:

Nombre de la clave del Registro	Datos esperados
AllowTelemetry	0x00000003 para nivel opcional/completo
DisableTelemetryOptInSettingsUx	0x00000001 para bloquear cambios de usuario
LimitDiagnosticLogCollection	0x00000001 si has limitado los registros de diagnóstico
LimitDumpCollection	0x00000001 cuando restringes los volcados de memoria

Después revisa la clave HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\PCHealth\ErrorReporting. Aquí suele existir un valor DoReport configurado a 0x00000001, lo que indica que el reporte de errores está permitido según la política corporativa.

Otra clave relevante es HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Windows Error Reporting. En esta ubicación te interesan especialmente los valores Disabled y DontSendAdditionalData, que determinan si WER está apagado o si puede remitir datos complementarios.

Nombre de la clave del Registro	Datos esperados
Disabled	0x00000000 para mantener WER habilitado
DontSendAdditionalData	0x00000001 para bloquear el envío de datos extra

Finalmente, en la ruta HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\Consent se encuentra un valor importante llamado DefaultConsent. Con un dato configurado como 0x00000004, el sistema ajusta el comportamiento por defecto respecto al consentimiento de envío de informes.

Activar y desactivar WER con comandos PowerShell

Además de las GPO y el Registro, Windows incorpora cmdlets específicos para manejar WER desde PowerShell, algo muy cómodo cuando quieres operar sobre servidores aislados o automatizar tareas en scripts.

El cmdlet principal para habilitar la funcionalidad es Enable-WindowsErrorReporting. Sin parámetros adicionales, su sintaxis es muy sencilla:

Enable-WindowsErrorReporting

Al ejecutar este comando en una consola de PowerShell con privilegios elevados, el sistema activa Windows Error Reporting en ese equipo. Internamente ajusta los valores necesarios para que los informes de errores vuelvan a generarse y enviarse conforme a la configuración de telemetría definida.

Este cmdlet devuelve un resultado de tipo Boolean. Si la operación se completa correctamente, el valor de retorno será $True; en caso contrario, obtendrás $False, lo que te permite integrar una comprobación sencilla en tus scripts de despliegue o mantenimiento.

Ejemplo de uso directo:

PS C:\> Enable-WindowsErrorReporting

Para comprobar el estado actual de WER puedes recurrir al cmdlet Get-WindowsErrorReporting, que te indicará si está activado o no. Y si más adelante quieres deshabilitarlo, dispones del cmdlet complementario Disable-WindowsErrorReporting, que apaga la característica y evita que se envíen más informes de fallos a Microsoft desde ese equipo.

Activar o desactivar WER con scripts PowerShell y Batch remotos

En soluciones de gestión remota como ciertas plataformas MDM o EMM, es frecuente que se permitan scripts personalizados para habilitar o deshabilitar WER en masa. Normalmente se basan en modificar claves de registro o en invocar a los cmdlets indicados en los apartados anteriores.

Un script de PowerShell puede, por ejemplo, leer el estado actual del servicio de informes de errores y escribir en el historial de acciones si está “Enabled” o “Disabled” tras su ejecución. Cuando el script se ejecuta con éxito, es habitual que la consola de administración muestre “True” como resultado para indicar que la operación ha ido bien.

En el caso de scripts por lotes (Batch), la lógica suele ser similar pero editando directamente la clave HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting. Un comando típico para habilitar WER consistirá en crear o modificar el valor Disabled asignándole el dato 0, permitiendo así que el sistema recopile y envíe informes.

Del mismo modo, para desactivar WER mediante un .bat se modifica el valor Disabled a 1, bloqueando la recopilación y el envío de errores hacia los servidores de Microsoft. Si todo va bien, estas acciones suelen registrar el mensaje “The operation completed successfully” en el historial de la herramienta remota.

Rellenado del Visor de eventos y servidores sin acceso a Internet

En algunos entornos, especialmente en servidores aislados o sin conectividad externa, WER puede acabar llenando el Visor de eventos con mensajes repetitivos indicando intentos fallidos de conexión o envío de informes.

Este comportamiento se debe a que el servicio intenta contactar con los endpoints de Microsoft descritos antes, pero como la salida está bloqueada, reintenta periódicamente, generando más eventos y, en ocasiones, cierto ruido en el registro de sucesos.

Para estas situaciones puedes optar por desactivar WER a nivel de política, usar las claves del Registro para marcarlo como deshabilitado o restringir que se intente enviar datos adicionales a través de la combinación de valores como Disabled y DontSendAdditionalData. Otra opción es mantener el informe activo pero sólo para volcados locales, sin telemetría saliente.

Gestión de archivos HDMP y MDMP y consumo de espacio en disco

Algo que a menudo pasa desapercibido es el espacio en disco que pueden llegar a ocupar los archivos HDMP y MDMP generados por WER cuando se producen muchos errores en poco tiempo, por ejemplo en un servidor de aplicaciones como SharePoint.

Los archivos HDMP suelen contener un volcado completo con mucha información del proceso, mientras que los MDMP (minidumps) son volcados comprimidos con un subconjunto de datos. Ambos se almacenan en diversas rutas según la versión de Windows, y pueden dejar el disco del sistema al borde del colapso si no se controlan.

En sistemas antiguos como Windows Server 2003 o Windows XP, los volcados a menudo se guardan en la carpeta C:\WINDOWS\pchealth\ERRORREP\UserDumps. En versiones más actuales como Windows 7 o Windows Server 2008, los informes suelen ir a directorios como:

• C:\ProgramData\Microsoft\Windows\WER\ReportArchive
• C:\ProgramData\Microsoft\Windows\WER\ReportQueue
• C:\Users\NombreUsuario\AppData\Local\Microsoft\Windows\WER\ReportArchive
• C:\Users\NombreUsuario\AppData\Local\Microsoft\Windows\WER\ReportQueue

En estos directorios encontrarás ficheros con nombres del estilo w3wp.exe{fecha}.mdmp o w3wp.exe{fecha}.hdmp, asociados al proceso que ha fallado (por ejemplo, el worker process de IIS en servidores SharePoint). Si los volcados se generan por fallos en librerías, puedes revisar guías para resolver errores DirectX y DLL relacionados.

Si detectas que estos volcados están creciendo sin control, puedes deshabilitar WER temporalmente, limpiar las carpetas o configurar adecuadamente los límites de colección de volcados (DumpCount, DumpType, etc.) para que el sistema se autorregule y no deje el disco sin espacio libre.

Deshabilitar WER en versiones antiguas de Windows (XP/2003)

En sistemas como Windows 2003 o Windows XP, la administración del informe de errores se hacía en parte desde el cuadro de propiedades del sistema. Era posible desactivar globalmente la recopilación o habilitarla solo para determinadas aplicaciones.

El procedimiento típico consistía en abrir “Mi PC” con botón derecho, ir a “Propiedades”, entrar en la pestaña “Avanzado” y pulsar sobre la opción de “Error Reporting”. Desde ahí se permitía desactivar completamente el informe o configurar qué programas debían informar y cuáles no.

Aunque hoy estas versiones están fuera de soporte, muchos entornos heredados siguen presentes, por lo que saber que WER se puede gestionar desde esa interfaz y desde rutas de carpeta como UserDumps resulta todavía útil para labores de limpieza y mantenimiento.

Configurar WER mediante Registro en Windows 7, Windows 8 y Windows Server 2008

En versiones más modernas como Windows 7 y Windows Server 2008, además de las opciones gráficas, puedes controlar WER desde el Editor del Registro. La clave base es HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting.

Para desactivar el informe de errores por completo, se suele crear o modificar el valor Disabled de tipo DWORD y ponerlo a 1. De esta forma, el servicio deja de generar y enviar informes. Si quieres reactivarlo, basta con establecer el valor a 0 o eliminar la entrada.

En cuanto a la parte gráfica, el sistema también permitía ciertos ajustes desde “Propiedades del sistema” > “Opciones avanzadas” > “Rendimiento” > “Configuración” y, por ejemplo, revisar opciones relacionadas con Data Execution Prevention (DEP). Aunque no es exactamente lo mismo que WER, se relaciona con la manera en que Windows protege y reacciona ante determinados fallos.

Habilitar registro detallado de cuelgues de aplicaciones (ejemplo con explorer.exe)

En ocasiones, para diagnosticar por qué una aplicación concreta se bloquea, conviene forzar la generación de volcados locales detallados. Un caso clásico es el del proceso explorer.exe, que, cuando se atasca, deja al usuario con el escritorio congelado; como alternativa para mitigar el impacto puedes reiniciar el Explorador de archivos mientras preparas la captura.

Esto se puede conseguir creando un archivo .reg que añada varias claves al Registro. Por ejemplo, bajo HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\Explorer.exe se pueden definir parámetros como DumpFolder (por ejemplo, “C:\\WER Dumps”) y DumpType con un valor 2 para indicar un volcado completo.

Adicionalmente, en HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\explorer.exe se pueden configurar valores como GlobalFlag y PageHeapFlags para activar técnicas de depuración avanzadas que obliguen a WER a generar información exhaustiva en caso de cuelgue.

Tras importar ese .reg y una vez producida la incidencia, el servicio de informes de errores creará volcados en la carpeta configurada, por ejemplo C:\WER Dumps, que posteriormente se pueden revisar con herramientas de análisis de volcados como WinDbg o utilidades más sencillas.

Configurar volcados de modo usuario completos con WER (LocalDumps)

A partir de Windows Server 2008 y Windows Vista SP1 se introdujo la posibilidad de que WER guardase volcados locales de modo usuario completos cuando una aplicación se bloquea. Esta función no viene activada por defecto y requiere permisos de administrador para configurarse.

La configuración se realiza en la clave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps. Aquí se pueden definir varios valores que controlan dónde se almacenan los volcados, cuántos se guardan y de qué tipo son.

Los valores de Registro más importantes son:

Valor	Descripción	Tipo	Valor predeterminado
DumpFolder	Ruta donde se guardan los volcados. Si se cambia, hay que asegurarse de que la carpeta tenga permisos adecuados para que el proceso que se bloquea pueda escribir allí.	REG_EXPAND_SZ	%LOCALAPPDATA%\CrashDumps
DumpCount	Número máximo de archivos de volcado almacenados en la carpeta. Cuando se supera, el volcado más antiguo se sobrescribe por uno nuevo.	REG_DWORD	10
DumpType	Indica el tipo de volcado: 0 (personalizado), 1 (minidump) o 2 (completo). El valor determina cuánta información se incluye en el archivo.	REG_DWORD	1
CustomDumpFlags	Se usa solo si DumpType es 0. Es una combinación bit a bit de valores de MINIDUMP_TYPE para ajustar qué datos específicos se capturan en el volcado personalizado.	REG_DWORD	Normalmente 0x00000121 (que combina varios flags como MiniDumpWithDataSegs, MiniDumpWithUnloadedModules y MiniDumpWithProcessThreadData).

Estos parámetros se consideran una configuración global. Si quieres afinar el comportamiento para una aplicación concreta, puedes crear una subclave con el nombre exacto del ejecutable dentro de LocalDumps, por ejemplo LocalDumps\MiAplicacion.exe, y definir ahí sus propios valores de DumpFolder, DumpCount, etc.

Cuando una aplicación se cuelga, el sistema revisa primero la configuración global y luego aplica cualquier ajuste específico por aplicación si existe. Una vez se genera el volcado, la aplicación puede cerrarse con normalidad o intentar recuperarse si está preparada para ello.

Un detalle interesante es que estos volcados locales se gestionan de forma independiente al resto de la infraestructura WER. Puedes tener la recogida local activa aunque WER esté desactivado a nivel de envío de informes o incluso si el usuario ha cancelado el reporte.

Herramientas y mejoras para trabajar con volcados en Windows 11

En las versiones más actuales como Windows 11 se han añadido mejoras que facilitan la creación y el análisis de volcados, tanto desde la interfaz gráfica como desde herramientas especializadas.

El Administrador de tareas incluye una opción para generar un volcado de memoria activa de cualquier proceso de modo usuario o incluso de procesos de kernel. Basta con ir a la pestaña “Procesos” o “Detalles”, pulsar con botón derecho sobre el proceso y elegir “Crear archivo de volcado de memoria activa”.

También se ha potenciado la utilidad ProcDump de Sysinternals, que ahora admite más disparadores, como la creación o finalización de hilos, ciertos contadores de rendimiento o la detección de ventanas bloqueadas. En Windows 11, ProcDump es capaz de trabajar con todos los tipos de triggers introducidos desde Windows 8.1 en adelante.

En el ámbito de la depuración, herramientas como WinDbg y CDB permiten analizar tanto minidumps como volcados completos. Se han actualizado para manejar mejor los volcados de modo usuario, pudiendo incluso leer volcados directamente desde archivos CAB o analizar varios archivos de volcado a la vez, algo muy útil cuando tienes incidentes recurrentes; también puedes diagnosticar errores con Dependency Walker para complementar el análisis.

Uso de TSS para recopilar trazas de rendimiento y red

En escenarios de soporte avanzado, Microsoft recomienda en ocasiones usar scripts como TSS.ps1 para recopilar información detallada sobre el sistema, incluyendo datos de rendimiento, configuración y trazas de red asociadas a WER y otros componentes.

El flujo típico consiste en descargar TSS en todos los nodos afectados y descomprimirlo en una carpeta estándar como C:\tss. Luego se abre un PowerShell con privilegios de administrador en esa misma ruta.

Desde ahí, es posible lanzar diferentes escenarios de recopilación usando comandos del tipo:

TSS.ps1 -SDP PERF,SETUP
TSS.ps1 -Scenario NET_WFP

Al ejecutarlos, el script te pedirá aceptar los términos de licencia (EULA) y, una vez dado el consentimiento, comenzará a recopilar automáticamente los datos necesarios. Puede tardar un rato dependiendo del volumen de información y de la carga del sistema.

Al finalizar, los resultados suelen comprimirse en un archivo ZIP dentro de una carpeta del estilo C:\MS_DATA\SDP_PERFSETUP\, que puedes subir a un área de trabajo de soporte de Microsoft para que sea analizado por los ingenieros.

Dominar Windows Error Reporting supone entender cómo se relacionan las directivas de grupo, la telemetría, el Registro, los volcados locales y las herramientas de análisis. Ajustando bien estos elementos puedes conseguir que tus equipos informen lo justo y necesario, que los servidores no se queden sin espacio por culpa de HDMP/MDMP, que las redes restringidas no sufran intentos constantes de conexión y, al mismo tiempo, disponer de la información imprescindible para diagnosticar y resolver cuelgues y fallos críticos cuando se presentan.