Uso elevado de CPU por ReportCrash en Mac

¿Qué es ReportCrash en Mac?

En macOS, ReportCrash es el gestor de fallos integrado que opera bajo el proceso padre "launchd". Siempre que una aplicación o proceso en segundo plano muere inesperadamente, este componente se despierta, inspecciona lo sucedido y escribe un informe de diagnóstico en el disco para que los desarrolladores (y a veces tú) puedan ver qué salió mal.

Técnicamente, ReportCrash se ejecuta en dos variantes:

• como un LaunchAgent para procesos a nivel de usuario, escribiendo informes en tu carpeta
  ~/Library/Logs/DiagnosticReports/;
  
• como un LaunchDaemon para procesos del sistema y de root, almacenando informes en directorios de registro de diagnóstico de todo el sistema.

En las versiones recientes de macOS, el familiar diálogo "¿la aplicación se ha cerrado inesperadamente, enviar a Apple?" es parte de una pila de informes más amplia con Problem Reporter como la interfaz visible y ReportCrash haciendo gran parte del trabajo pesado detrás de escena.

En circunstancias normales, apenas notas esta actividad. Una aplicación falla, ReportCrash interviene brevemente, escribe un registro y sale. El uso de la CPU aumenta por un momento y luego vuelve a bajar a cero. Así es como se supone que debe funcionar.

Por qué ReportCrash puede monopolizar la CPU

Cuando ves a ReportCrash consumiendo 50-300% de CPU (en sistemas multinúcleo) y reapareciendo constantemente en el Monitor de Actividad (Activity Monitor), casi nunca es el verdadero culpable. Es el mensajero. El problema real es otra cosa que sigue fallando en un bucle cerrado.

El patrón común es:

1. Un proceso se inicia.
2. Falla casi de inmediato.
3. launchd lo reinicia.
4. ReportCrash se despierta para procesar otro fallo más.
5. Esto se repite sin parar.

Debido a que generar y comprimir informes de fallos no es un trabajo trivial, un proceso atascado en este bucle puede mantener a ReportCrash ocupado las 24 horas. Numerosos informes de usuarios en foros y sitios de preguntas y respuestas muestran la misma historia: un uso alto y persistente de la CPU por ReportCrash casi siempre se correlaciona con un agente en segundo plano, extensión o marco que no deja de fallar y reiniciarse.

Los culpables subyacentes típicos incluyen:

• Demonios de sincronización e indexación (por ejemplo, contactos, sugerencias o servicios relacionados con la búsqueda) que se ahogan con datos corruptos;
• Aplicaciones de la barra de menús de terceros o asistentes que se rompieron después de una actualización de macOS;
• Restos de aplicaciones desinstaladas cuyos LaunchAgents o LaunchDaemons siguen iniciando binarios que ya no existen;
• Herramientas de desarrollo o simuladores (Xcode, simuladores de iOS, etc.) donde un componente falla repetidamente durante las pruebas.

En resumen, ReportCrash es ruidoso porque otra cosa está enferma. El objetivo es encontrar ese "algo", arreglarlo o eliminarlo, y solo entonces considerar tocar al propio ReportCrash.

Por cierto, este patrón es muy similar a otras historias de CPU alta que he cubierto que involucran a chronod, contactsd, syspolicyd y wdavdaemon – un pequeño trabajador en segundo plano se descarrila y arrastra el rendimiento del sistema con él.

Cómo solucionar el alto uso de CPU de ReportCrash en Mac

Paso 1. Identifica qué está fallando en un bucle

Si solo haces una cosa, haz esto. Necesitas saber qué proceso está arrastrando a ReportCrash al modo de sobrecarga.

1. Abre Consola (Console)
   • Pulsa Comando–Espacio, escribe Console y pulsa Intro.
2. En la barra lateral, busca Informes de fallos (Crash Reports) (o usa la sección "Crash Reports" bajo "Informes").
3. Ordena por Fecha y comprueba las entradas más recientes:
   • Probablemente verás el mismo nombre de proceso repetido muchas veces en un corto lapso de tiempo.
4. Si los Informes de fallos parecen vacíos, cambia a:
   • system.log o Todos los mensajes (All Messages), luego busca términos como crash, Service only

Anota:

• el nombre del proceso infractor (por ejemplo, suggestd, una aplicación de la barra de menús, algún asistente),
• su ruta si es visible, y
• aproximadamente con qué frecuencia falla.

Este es tu principal sospechoso.

Paso 2. Elimina o repara la aplicación o componente infractor

Una vez que sepas qué está fallando, la mejor solución suele ser actualizar, restablecer o desinstalar ese elemento específico.

1. Si es una aplicación regular que conoces y usas:
   • Sal de ella si se está ejecutando.
   • Comprueba si hay una actualización en su menú (a menudo NombreApp ▸ Buscar actualizaciones) o a través de la App Store.
   • Si los fallos continúan, intenta una reinstalación limpia:
     • Arrastra la aplicación desde Aplicaciones a la Papelera.
     • Reinicia.
     • Descarga una copia fresca de la fuente oficial y reinstala.
2. Si es una aplicación que ya no te importa:
   • En Aplicaciones, elimínala junto con herramientas auxiliares obvias (desinstaladores, actualizadores).
   • Luego comprueba si hay componentes restantes en:
     • ~/Library/Application Support/
     • ~/Library/LaunchAgents/
     • /Library/LaunchDaemons/
   • Elimina solo los elementos claramente relacionados con esa aplicación (que coincidan con su nombre o proveedor).

3. Si es un servicio del sistema (por ejemplo, suggestd, relacionado con contactos o sincronización de iCloud):
   • Desactiva temporalmente las funciones asociadas:
     • Apaga las cuentas problemáticas en Ajustes del Sistema ▸ Cuentas de Internet.
     • Cambia servicios como Contactos de iCloud, Sugerencias de Siri y Spotlight o elementos similares a desactivado, espera un poco y luego vuelve a activarlos.
   • Si la tormenta de CPU se calma después de desactivar una cuenta o función específica, es probable que sea donde residen los datos corruptos.

La idea es simple: si lo que sigue fallando desaparece o comienza a comportarse bien, ReportCrash ya no tiene razón para ejecutarse sin parar.

Paso 3. Limpia registros de fallos y diagnósticos de gran tamaño

Incluso después de domar el bucle de fallos, el sistema puede estar plagado de miles de informes de fallos antiguos. Por lo general, no causan picos de CPU por sí mismos, pero desperdician espacio en disco y pueden hacer que el análisis sea ruidoso.

Puedes limpiarlos de forma segura de la siguiente manera:

1. En el Finder, pulsa Mayús–Comando–G para abrir Ir a la carpeta…
2. Visita estas ubicaciones una por una:
   • ~/Library/Logs/DiagnosticReports/
   • /Library/Logs/DiagnosticReports/ (es posible que necesites derechos de administrador)
3. Mueve los archivos .crash y .panic más antiguos a la Papelera (o a una carpeta de archivo si quieres una copia de seguridad).
4. Vacía la Papelera cuando estés seguro de que todo es estable.

Esto no detendrá directamente el uso de CPU de ReportCrash si la causa raíz persiste, pero mantiene tu Mac ordenado y puede reducir ligeramente la E/S en segundo plano.

Paso 4. Desactiva elementos de inicio de sesión problemáticos y asistentes en segundo plano

Un escenario muy común es un elemento de inicio de sesión o LaunchAgent para una aplicación olvidada hace mucho tiempo que intenta iniciar algo que ya no existe. Ese binario no se inicia correctamente, falla instantáneamente y ReportCrash se inunda.

Realiza la siguiente limpieza:

1. Comprueba los Ítems de inicio de sesión
   • Ve a Ajustes del Sistema ▸ General ▸ Ítems de inicio de sesión.
   • Bajo tanto Abrir al iniciar sesión como Permitir en segundo plano, desactiva los elementos que no reconozcas o que ya no uses.
2. Inspecciona LaunchAgents y LaunchDaemons
   En el Finder, usa Ir ▸ Ir a la carpeta… y mira en:
   • ~/Library/LaunchAgents/
   • /Library/LaunchAgents/
   • /Library/LaunchDaemons/
   
   
3. Para cada carpeta:
   • Ordena por Nombre y busca elementos que obviamente pertenezcan a aplicaciones desinstaladas.
   • Mueve los archivos .plist sospechosos a una carpeta temporal en tu Escritorio en lugar de eliminarlos directamente.
   • Reinicia y observa el Monitor de Actividad para ver si ReportCrash se calma.

Si todo funciona bien durante unos días, puedes eliminar de forma segura esos archivos .plist en cuarentena. Si algo importante se rompe, muévelos de vuelta.

Paso 5. Prueba en Modo seguro

El Modo seguro es una forma rápida de saber si hay componentes de terceros involucrados. En este modo de diagnóstico, macOS carga solo las extensiones esenciales y desactiva la mayoría de los elementos de inicio y LaunchAgents.

1. Apaga tu Mac.
2. Enciéndelo y mantén pulsada la tecla adecuada para tu tipo de CPU:
   • Mac con Intel: mantén pulsado Mayús inmediatamente después del sonido de inicio hasta que veas la ventana de inicio de sesión.
   • Mac con Apple silicon:
     • Mantén pulsado el botón de encendido hasta que aparezca "Cargando opciones de arranque".
     • Selecciona tu disco de arranque, mantén pulsado Mayús, luego haz clic en Continuar en modo seguro.
3. Inicia sesión y abre el Monitor de Actividad (Activity Monitor).

Si ReportCrash está silencioso en Modo seguro pero se vuelve loco de nuevo después de un reinicio normal, es casi seguro que estás lidiando con software de terceros (elementos de inicio de sesión, extensiones del kernel, herramientas auxiliares). Usa esa pista para revisar los pasos 2 y 4 de manera más agresiva.

Paso 6. Restablece SMC y NVRAM (para casos obstinados)

Aunque no está directamente relacionado con ReportCrash, los fallos de bajo nivel en la gestión de energía o el estado del hardware a veces se manifiestan como fallos aleatorios y repetidos e inestabilidad del sistema. Restablecer el SMC (Macs Intel) y la NVRAM puede ayudar a limpiar esas telarañas.

El procedimiento depende de tu modelo de Mac, pero en grandes rasgos:

• Restablecimiento de NVRAM (Macs Intel):
  1. Apaga tu Mac.
  2. Enciéndelo y mantén pulsado inmediatamente Opción–Comando–P–R.
  3. Mantén pulsadas las teclas durante unos 20 segundos, luego suéltalas.
• Restablecimiento de SMC (Macs Intel):
  Los pasos difieren para MacBook con/sin batería extraíble, iMac y Mac mini. Consulta las instrucciones de Apple para tu modelo exacto y versión de macOS.
  

En los Macs con Apple silicon, no hay un restablecimiento separado de SMC o NVRAM – una secuencia limpia de apagado y encendido hace efectivamente lo mismo.

Si el alto uso de CPU de ReportCrash persiste incluso después de haber descartado causas a nivel de aplicación y realizado estos restablecimientos, estás en territorio de "ajustes avanzados".

Paso 7. (Avanzado) Desactiva temporalmente ReportCrash

Este paso es opcional y está dirigido a usuarios experimentados. En entornos donde existe un bucle de fallos conocido e inevitable (por ejemplo, fuzzing, configuraciones de prueba específicas), algunos administradores optan por desactivar ReportCrash para que no desperdicie recursos generando registros interminables.

Para un Mac doméstico o de oficina normal, recomiendo esto solo como una solución alternativa a corto plazo mientras rastreas el verdadero culpable, no como una solución permanente. Perderás los diagnósticos automáticos de fallos y puedes ocultar signos de problemas más profundos.

Si aún quieres proceder, puedes descargar el LaunchAgent y LaunchDaemon de ReportCrash desde Terminal:

1. Abre Terminal desde Aplicaciones ▸ Utilidades.
2. Ejecuta estos comandos con cuidado (se te pedirá tu contraseña de administrador para el segundo):

launchctl unload -w /System/Library/LaunchAgents/com.apple.ReportCrash.plist
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.ReportCrash.Root.plist

Esto evita que ReportCrash se inicie automáticamente para procesos de usuario y del sistema.

Para volver a habilitar el informe de fallos más tarde, ejecuta:

launchctl load -w /System/Library/LaunchAgents/com.apple.ReportCrash.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.ReportCrash.Root.plist

Una vez más, trata esto como un último recurso, no como tu primer movimiento. Si desactivar ReportCrash parece "resolver" el problema, en realidad solo has quitado el termómetro, no has curado la fiebre.

Cómo prevenir problemas con ReportCrash en el futuro

No puedes detener cada fallo, pero puedes reducir las probabilidades de un incidente de ReportCrash fuera de control siguiendo algunos hábitos:

• Mantén macOS y las aplicaciones principales actualizadas: Las correcciones de estabilidad son una constante en las notas de lanzamiento del sistema y de las aplicaciones.
• Sé exigente con los elementos de inicio: Revisa regularmente los Elementos de inicio de sesión y desactiva cualquier cosa que no necesites cargar en cada arranque.
• Desinstala aplicaciones limpiamente: Cuando dejes de usar una aplicación, elimina sus archivos de soporte y auxiliares de inicio, no solo el paquete principal en Aplicaciones.
• Evita instaladores y paquetes dudosos: El adware y los agentes en segundo plano mal escritos son una fuente común de fallos extraños, no solo de secuestradores de navegador.
• Vigila el Monitor de Actividad: Si tus ventiladores giran de la nada, un vistazo rápido a las pestañas CPU y Energía puede atrapar procesos que se comportan mal antes de que se conviertan en problemas crónicos.

Resumiendo

Cuando el impacto en la CPU entra en acción, culpar al propio ReportCrash es un error. Cuando el proceso monopoliza la CPU durante horas, es un fuerte indicador de que alguna aplicación, servicio o componente restante está atascado en un bucle implacable de fallo y reinicio.

La solución suele ser metódica en lugar de dramática: identifica qué falla, repáralo o elimínalo, limpia los elementos de inicio y los LaunchAgents, y solo entonces considera medidas avanzadas como desactivar ReportCrash temporalmente. Una vez que la inestabilidad subyacente haya desaparecido, tu Mac debería volver a su comportamiento habitual silencioso, fresco y discreto.

Preguntas frecuentes

1. ¿Es ReportCrash un virus o malware en Mac?

2. ¿Es seguro matar el proceso ReportCrash en el Monitor de Actividad?

3. ¿Cómo sé qué aplicación está causando que ReportCrash use mucha CPU?

4. ¿Puedo desactivar los informes de fallos en mi Mac permanentemente?

5. ¿Cuándo debería considerar reinstalar macOS para solucionar problemas de ReportCrash?