Reportcrash mac os что это
Перейти к содержимому

Reportcrash mac os что это

  • автор:

How to Fix ReportCrash High CPU on Mac & Disable ReportCrash?

What is ReportCrash on Mac

If your Mac is running slow, making loud fan noises, or quickly consuming the battery, you may find the ReportCrash process taking high CPU usage in Activity Monitor. You might have tried to force quit the process, but it would restart after a few seconds and continues to strain your Mac’s processor.

In this article, we’ll detail the steps to troubleshoot the macOS ReportCrash process high CPU issue. Before getting to it, it’s essential to learn what the process is used for.

Fix Mac ReportCrash high CPU on Catalina/Big Sur/Monterey/Ventura or others:

Step 1: Identify the culprit causing ReportCrash to use high CPU Check «Crash Reports» or «system.log» in Console
Step 2: Delete or uninstall the offending process or app Locate the process in Finder or fully uninstall the app
Step 3: Disable ReportCrash on Mac Run the following Terminal commands:
launchctl unload -w /System/Library/LaunchAgents/
sudo launchctl unload -w /System/Library/LaunchDaemons/

What is ReportCrash on Mac?

ReportCrash is a macOS process that’s responsible for analyzing crashing processes and generating crash reports. When an app or process unexpectedly stops, ReportCrash will be activated to examine what went wrong with the app or process at the moment it crashed and save its findings to Mac’s internal hard drive.

The created crash reports are valuable to not only software developers but also to those who need to find the culprit causing ReportCrash to drain a significant amount of your Mac’s CPU power.

When an app crashes, you may receive a modal dialog containing the crash report. The display was used to be made by the Crash Reporter. However, in recent macOS versions, Crash Reporter has been replaced by Problem Reporter, located in /System/Library/CoreServices.

Where ReportCrash is located on Mac

Share the information to benefit others!

How to fix ReportCrash high CPU usage on Mac?

The macOS ReportCrash process usually won’t draw any CPU from your Mac when there’s no crash happening. If it’s soaking up a considerable percentage of your Mac’s CPU, it’s mainly because a process or app is constantly launching and crashing.

To stop ReportCrash from using high CPU usage, you can follow the steps below.

Step 1: Identify the process that’s rendering ReportCrash’s high CPU consumption

The first step is to figure out which process is triggering ReportCrash to run non-stop. Open the Console app from the Applications/Utilities folder and select «Crash Reports» from the left side. Then you can check the app that has crashed.

Check crash reports in Console

Besides, you can also select «system.log» and look for messages that keep repeating or the potential suspect. You’ll likely see messages like «Service only ran for 2 seconds. Pushing respawn out by 8 seconds.», which indicates a service is in a vicious circle of launching, crashing, and relaunching.

Check system log to find the cuplrit causing ReportCrash to tax CPU

Step 2: Delete the offending process or uninstall the troublesome app

① If you’ve located the directory where a suspicious process resides, you can search for it online and decide whether it’s necessary for your Mac. If it’s an app leftover, you can delete it. (If it’s part of an app you’re using, uninstall the app.)

Open Finder and click Go > Go to Folder from the menu bar, then copy the path into the search bar to locate the item and get rid of it.

② If you suspect an app, you can completely uninstall it. Note that if an app isn’t completely uninstalled, the remaining process may try to launch the app and fail, thus causing the CPU usage of ReportCrash to spike.

We recommend you use iBoysoft MagicMenu to fully uninstall the troublesome app. It can scan your Mac to find the relevant files of the app and allows you to delete them efficiently. Here’s how to use it:

Step 1: Download and install iBoysoft MagicMenu.



Step 2: Right-click on the app in your Applications folder and click Uninstall.

Fully uninstall apps on Mac

Step 3: After all files of the app are found, click Uninstall to permanently delete them.

Uninstall the offending app that is causing ReportCrash high CPU usage

Make sure there’s no file about the app in the following directories:

Step 3: Disable ReportCrash if the above doesn’t work

If you can’t find the process that’s causing troubles or the above steps don’t work, you can disable ReportCrash on Mac.

How to disable ReportCrash on Mac:

How to disable ReportCrash on Mac

  1. Open Terminal.
  2. Copy and paste the commands below into Terminal and hit Enter. launchctl unload -w /System/Library/LaunchAgents/
    sudo launchctl unload -w /System/Library/LaunchDaemons/
  3. Input your admin password and press Enter.

If want to reenable ReportCrash on Mac, run the following commands in Terminal:

launchctl load -w /System/Library/LaunchAgents/
sudo launchctl load -w /System/Library/LaunchDaemons/

Please share this post if you find it helpful!

Jenny is a technical writer at iBoysoft, specializing in computer-related knowledge such as macOS, Windows, hard drives, etc. She’s also been producing top-notch articles for other famous technical magazines and websites.

Jessica Shee is a senior tech editor at iBoysoft. Throughout her 4 years of experience, Jessica has written many informative and instructional articles in data recovery, data security, and disk management to help a lot of readers secure their important documents and take the best advantage of their devices.

‘ReportCrash’ process in activity monitor popping out with high cpu usage

I’ve upgraded my macbook white to Leopard and did all the usual mantainance routines.

However my fan noise has gone up considerably from Tiger infact fan is always spinning at around 6000 rpm. CPU temp is about 60 degree.

I’ve just Firefox open and looking at the activity monitor for possible CPU eaters the only abnormal thing I can find is this ‘ReportCrash’ process continuosly popping in and out and taking between 50 and 99% of CPU usage.

Any ideas why and if it’s indeed a normal behaviour?

thanks in advance

Show more Less

macbook white 2Ghz Core 2 Duo, Mac OS X (10.5.8), Fireface 400

Posted on May 1, 2010 4:27 AM

Me too (183) Me too Me too (183) Me too Reply
Question marked as Best reply
User level: Level 9
54,333 points

Posted on May 1, 2010 10:20 AM

The CrashReporter kicks in any time an application crashes. It saves the application state to (hopefully) aid the developer in working out why the app crashed.

In your case it sounds like you have some process that’s launching, crashing (and invoking CrashReporter) and then re-launching, repeating this cycle ad infinitum.

You need to identify which process is triggering this cycle and stop it.

Fortunately CrashReporter is pretty verbose in its logging and given the frequency it shouldn’t be hard to find the culprit. Just look towards the end of your system.log, either via /Applications/Utilities/ or via the terminal.

Crash report mac os как исправить?

Привет всем!
Подскажите пожалуйста в чем может быть проблема:
Имею мак 13 года a1465 11″
макбук может стабильно работать день два, но потом резко словить crash и перезагрузиться причем не один раз, так же могут рандомно крашиться приложения
в логах постоянно разные ошибки вроде и SMC u NVRAM сбрасывал, но перезагружаться он не перестал
делал все возможные тесты оперативки

прикладываю логи
подскажите пожалуйста как поступить

  • Вопрос задан более трёх лет назад
  • 1150 просмотров

2 комментария

Средний 2 комментария

Как читать отчеты о сбоях в Mac OS для устранения неполадок

Обычно сбой приложений на Mac случается очень редко. Но когда это произойдет, вы можете захотеть отслеживать эти проблемы. А если вы разработчик, вам нужно понимать, почему ваше приложение дает сбой. Вот как читать и сортировать отчеты о сбоях macOS по языку кодировки.

Как читать отчеты о сбоях Mac OS для устранения неполадок - Mac

Открытые отчеты о сбоях

Как читать отчеты о сбоях Mac OS для устранения неполадок - Mac

Когда приложение выходит из строя на вашем Mac, оно автоматически генерирует отчет о сбое. Вы увидите, что это появляется после сбоя в диалоговом окне с предупреждением: «[Приложение] неожиданно остановилось». Этот отчет о сбое доступен для немедленного чтения в этом окне, нажав кнопку «Отчет…». Отчет о сбое также можно найти в приложении консоли.

1. Откройте приложение консоли, набрав «Консоль» в Spotlight или перейдите в «Приложение -> Утилиты ->».

Как читать отчеты о сбоях Mac OS для устранения неполадок - Mac

2. Щелкните «Отчеты пользователей» в левом меню, затем щелкните отчет о сбоях, который вы хотите просмотреть. Все эти файлы заканчиваются на «.crash» и включают в заголовок дату и сломанное приложение. Подробная информация об отчете о сбое доступна на панели справа.

Как читать отчеты о сбоях Mac OS для устранения неполадок - Mac

Прочтите отчеты о сбоях Mac OS

Давайте рассмотрим отчет о сбое сверху вниз.

Что именно вылетает?

Как читать отчеты о сбоях Mac OS для устранения неполадок - Mac

Первая часть отчета о сбоях покажет вам, «вылетает» ли процесс или приложение. Самая важная часть для средства устранения неполадок — это название процесса.

Process: aText [11473] Path: /Applications/ Identifier: com.trankynam.aText Version: 2.19 (62) Code Type: X86-64 (Native) Parent Process: . [1] Responsible: aText [11473] User ID: 501

Когда были праздники?

Как читать отчеты о сбоях Mac OS для устранения неполадок - Mac

Вторая часть сообщает нам, когда произошла неисправность. Он также предоставляет небольшую информацию о вашей системе.

Date/Time: 2018-03-15 00:58:10.552 -0400 OS Version: Mac OS X 10.12.6 (16G1036) Report Version: 12 Anonymous UUID: 6C985CFD-6975-3F30-50EB-0713315F5090 Time Awake Since Boot: 630000 seconds System Integrity Protection: enabled

Что вызвало неисправность?

Как читать отчеты о сбоях Mac OS для устранения неполадок - Mac

Следующая часть наиболее показательна. «Тип исключения», предлагаемый приложением, сообщает нам, что вызвало неисправность. Журнал также сообщает, какой поток потерпел крах: в данном случае поток 0.

Crashed Thread: 0 Dispatch queue: Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x000040dedeadbec0 Exception Note: EXC_CORPSE_NOTIFY Termination Signal: Segmentation fault: 11 Termination Reason: Namespace SIGNAL, Code 0xb Terminating Process: exc handler [0]

Списки Apple Некоторые распространенные типы исключений В его технической документации:

Плохой доступ к памяти (EXC_BAD_ACCESS / SIGSEGV / SIGBUS) — программа пытается получить доступ к памяти неправильно или с недопустимым адресом. С кодом, объясняющим проблему с памятью.

Аномальный выход (EXC_CRASH / SIGABRT) — Аномальный выход, обычно из-за незавершенного исключения C ++ и вызова abort ()

Trace Trap (EXC_BREAKPOINT / SIGTRAP) — то же самое, что и SIGABRT, но это завершение дает присоединенному отладчику возможность прервать процесс в точке останова и отследить ошибку.

Недопустимые инструкции (EXC_BAD_INSTRUCTION / SIGILL) — обработка выдала обработку, которая не была понята или не могла быть обработана.

Выйти (SIGQUIT) — процесс был прерван другим процессом с достаточными привилегиями. Обычно процесс мониторинга завершает процесс злоупотребления служебным положением.

Завершить (SIGKILL) — процесс был завершен по запросу системы. Для объяснения исключения будет добавлен код выхода.

Как видно из отчета о сбое, приложение пыталось получить доступ к не карантинной памяти. Это происходит из-за ошибки программирования в приложении или необычного состояния пользователя, из-за которого приложение неправильно отображает память.

Что приводит к неисправностям?

Как читать отчеты о сбоях Mac OS для устранения неполадок - Mac

Затем мы видим обратный хронологический список того, что вызывает сбой. Они сортируются по потокам, начиная с потока 0.

В этом отчете четыре столбца. Первый сообщает номер события в обратном хронологическом порядке, начиная с 0. Второй — это идентификатор процесса. Третье — это адрес процесса в памяти. Четвертый — это название задачи программы.

Эта «отмена» может немного сбить с толку. Они являются «символическими», что означает, что некоторые адреса памяти были заменены именами функций или задач приложения. Иногда это невозможно сделать полностью, в результате чего нечитаемые адреса памяти засоряются отчетом.

Мы видим это в отчете о сбое выше: com.trankynam.aText не является токеном. Даже при полном кодировании фон может быть трудночитаемым. Разработчики программного обеспечения иногда включают полезные примечания о задачах и событиях приложения. В других случаях это зашифрованные адреса или числовой код. Если вы сможете понять символизм, вы сможете понять, что происходит. Но в максимально возможной степени вам нужно будет написать приложение самостоятельно, чтобы понять обратную трассировку.

Заключение: полезно ли это?

Если вы разработчик программного обеспечения, обязательно прочтите отчеты о сбоях. Это поможет вам понять, какая часть вашего приложения вызывает проблемы и почему. Если вы пользователь, они бесполезны. Но если у вас постоянный сбой, отчеты о сбоях могут помочь вам устранить проблему или поработать с разработчиком, чтобы исправить проблему. Вы можете получить код ошибки, исправленный через Google, или отправить его в службу технической поддержки с правильной информацией. Если вам нужны серьезные подробности, вы можете прочитать все об этом на Техническое примечание Apple о сбоях.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *