Reportcrash mac os что это
Как исправить повышенную нагрузку процессора в macOS Catalina
Пользователи, обновившиеся до macOS Catalina 10.15.7, жалуются на повышенную нагрузку процессора.
Это происходит из-за процесса accountsd, который отображается в системе, как потребляющий свыше 400% мощности. Раньше эта проблема тоже была, но возникала крайне редко — теперь намного чаще.
Accountsd – это демон, часть платформы Accounts. В документации для разработчиков Apple говорится, что эта структура помогает пользователям получать доступ и управлять своими внешними учетными записями из приложений, не требуя от них ввода учетных данных.
Как исправить ошибку
Решений несколько, не всем могут подойти, однако многие юзеры говорят про то, что ошибка исчезла.
Вариант #2. Некоторые пользователи решили проблему, сбросив SMC или NVRAM своего Mac.
1. Выключите Mac.
2. Нажмите кнопку питания и удерживайте ее в течение 10 секунд, затем отпустите кнопку.
3. Подождите несколько секунд, затем нажмите кнопку питания, чтобы включить компьютер Mac.
Вариант #3. Один пользователь Stack Exchange считает, что проблема связана с ошибкой индексирования файлов на Mac. Их решение включает в себя сброс индексации.
Процесс индексирования может временно замедлить работу вашего Mac, поэтому рекомендуется выполнить эти шаги в одночасье.
Артём Баусов
Главный по новостям, кликбейту и опечаткам. Люблю электротехнику и занимаюсь огненной магией. Telegram: @TemaBausov
Вышел трейлер продолжения фильма Борат. Релиз 23 октября
Apple Watch слишком часто отправляют людей к врачам. Только 10% подозрений подтвердились
Apple Music подводит итоги в России: самые популярные треки и альбомы за 2021 год
Логотипы всех Apple Store покрасили в красный цвет ко Всемирному дню борьбы со СПИДом
Apple знает о проблемах с зарядкой MacBook Pro 2021 и будет их исправлять
Зеленский заявил, что Apple поможет в переписи населения Украины
Apple объявила победителей премии Apple Music Awards 2021. Артистом года в России стал Скриптонит
Обзор практически ЛУЧШИХ наушников Sony WF-1000XM4 среди беспроводных. LDAC творит чудеса
Мечта геймера! Обзор ASUS ROG Zephyrus S17 с топовой видеокартой, которую отдельно сейчас не купишь
Обзор игры Battlefield 2042. Стыдно
🙈 Комментарии 30
Уже один раз словил – ребут помог
меня больше интересует как победить тоже самое, но с процессом photoanalysisd.
🙂
Принудительное отключение процесса для всего компьютера
Вы можете полностью запретить photoanalysisdзапуск процесса, введя команду in Terminal. Команде требуются права администратора, которые SIPвременно отключены, в противном случае вы получите сообщение permission deniedоб ошибке.
Таким образом, вы можете ввести команду в Терминале режима восстановления (загрузка с помощью Cmd (⌘) – Option (⌥) – R) или из сеанса пользователя, пока SIPон отключен (но не забудьте включить его снова после этого). В терминале введите следующую команду
PS: Если вы обновитесь до более новой версии MacOS, вам нужно будет выполнить этот шаг B), так как разрешения будут восстановлены.
PSS: Если вы когда-нибудь захотите включить его снова, возможно, вы потеряли отслеживание этой страницы … поэтому поместите заметку об этом где-нибудь. По крайней мере, знайте, что обновление до новейшего сбрасывает.
Не пойму. На Catalina 10.5.6 такой прикол возникал. При чем поочерёдно с нагрузкой приложения Почта. Служба поддержки Apple в качестве основного решения предлагает использовать как раз таки обновление до 10.5.7. Установил. Пока все гуд.
Кажется, что VDCAssistant вызывает вечные отчеты о сбоях
Как указано выше, VDCAssistant, по-видимому, вызывает вечные отчеты о сбоях до такой степени, что системный процесс ReportCrash будет использовать 50-100% от процессора.
Информация о приложении: Клиент пытается получить доступ к дисплею по индексу (1) вместо идентификатора отображения. abort () называется
Эти отчеты о сбоях также, похоже, исчезают и снова появляются. (т. е. количество отчетов о сбоях в Console.app никогда не растет, но постоянно генерируется). Процесс не может быть принудительным.
Я понятия не имею, что вызывает это, поскольку я не использую камеру iSight, и ничто другое не связано с ноутбуком (macbook pro 4,1 osx10.9.2)
Выход из системы не излечивает его, но перезапуск будет.
7 ответов
и перезапуск решает проблему для большинства людей, отправляющих в этот список.
Список обнаруженных мной приложений может вызвать проблемы, главным образом из длинного потока на форуме поддержки Apple :
Временное обходное решение найдено
VDCAssistant продолжал перезапуск и сбой, порождая процесс ReportCrash, в котором было много CPU. iSight не работает. Чтобы сохранить работу iMac в начале 2009 года (2009)
Это, похоже, остановило цикл сбоя /отчет /респаун. Я не знаю, есть ли у него какие-либо другие эффекты, но моя загрузка процессора вернулась к нормальной работе.
По-видимому, это потенциально вызвано сторонними приложениями, используемыми для зеркалирования или потоковой передачи изображений. В моем случае это было вызвано AirDisplay и удалением этой программы. Попробуйте загрузиться в безопасный режим, и когда проблема исчезнет в безопасном режиме, это почти наверняка вызвано сторонним программным обеспечением.
Как объяснялось выше, отключение VDCAssistant, похоже, разрешает эту проблему. Однако, даже после отключения этого, есть некоторые другие ошибки, которые могут появиться, например. эта ошибка регистрируется в консоли несколько раз в секунду:
Я не нашел обходного пути для этого, кроме перезагрузки и /или отключения адаптера DisplayLink (причина проблемы для меня). Надеюсь, это ожидает патч от Apple.
Открытие Windows 7 через Parallels, похоже, является триггером, который устанавливает каскад аварийной ситуации в движение. Thrashing VDCAssistant, похоже, вылечил его в краткосрочной перспективе. Надеюсь, это не приведет к другим проблемам в будущем.
Google Chrome
Удаление браузера Google Chrome решило проблему для меня.
Я отключил доступ к камере в настройках Chrome. Не помогло.
/Библиотека /Поддержка приложений /Google /
Я загрузил и снова установил приложение Google Chrome. Проблема делает снова.
Ухватился за Chrome и снова удалил приложение. Firefox теперь является моим дополнительным браузером вместо Chrome.
Я знаю, что это слишком поздно, но я просто отключил обмен камерой с Parallels.
Профилактика OS X: возвращаем системе производительность
Продолжаем приводить Mac в порядок. На прошлой неделе мы устроили профилактику накопителю, а сегодня возьмемся непосредственно за операционную систему.
Итак, OS X. Причин снижения производительности, появления различных неполадок в работе и других проблем может быть огромное множество, поэтому рассмотреть их все в рамках одного материала просто не представляется возможным. Поступим проще.
Мы предлагаем вам 6 советов, которые гарантированно не навредят системе и с высокой степенью вероятности повысят производительность компьютера, а также предотвратят возникновение проблем в будущем. Ничего сложного — просто несколько полезных трюков. Поехали!
Совет 1. Проверка списка автозагрузки
Начнем с банального — автозагрузки. Открываем «Системные настройки» и выбираем пункт «Пользователи и группы». Переходим на вторую вкладку под названием «Объекты входа» и внимательно изучаем список приложений, которые запускаются вместе с системой. Если заметили что-то откровенно лишнее, то смело выделяем эту программу и нажимаем на минус внизу. Снятие или установка галочки эффекта не дадут — это всего лишь средство скрыть окно программы после ее автозагрузки при запуске системы.
Очевидно, что Final Cut Pro X при запуске системы – не лучшая идея
Совет 2. Обнуление PRAM
Далее еще один известный, но от этого не менее полезный совет — сбросить PRAM. Эта процедура описана даже на сайте Apple:
PRAM — это небольшой раздел памяти компьютера, где хранится ряд значений параметров, к которым система OS X может быстро получить доступ.
Соответственно, периодический сброс данного раздела позволит «взбодрить систему». Для этого делаем следующее:
После того как система все-таки загрузится, вы можете заметить, что некоторые параметры сбились. Их придется настроить заново в «Системных настройках».
Совет 3. Использование Терминала
В «Терминале» OS X можно вводить команды, которые позволят внепланово запустить процедуры обслуживания системы. Для этого запускаем «Терминал» и копируем туда следующее:
sudo periodic daily
sudo periodic weekly
sudo periodic monthly
После этого потребуется ввести пароль администратора. Обратите внимание, что набираемые символы в «Терминале» не видны. Нажимаем Enter и ждем выполнения всех процедур.
Также из «Терминала» можно перестроить кэш dyld. Нередко его повреждение приводит к «задумчивости» компьютера, когда появляется индикатор загрузки и то или иное приложение становится временно недоступным для работы.
Потребуется ввести пароль, а затем желательно перезагрузить компьютер.
Совет 4. Очистка кэша приложений
Для выполнения этого совета придется завершить все запущенные приложения. Затем открываем Finder и нажимаем комбинацию клавиш Shift-Cmd-G. В появившемся поле вводим адрес
/Library/Caches и попадаем в указанную папку. Отсюда абсолютно все отправляем в корзину.
Все это смело отправляем в корзину
Вновь открываем Finder и нажимаем Shift-Cmd-G. Теперь в поле вводим уже /Library/Caches (отличие в тильде) и опять удаляем все файлы и папки. Очищаем корзину, перезагружаем компьютер.
Этот совет будет полезен, если какое-то приложение стало работать слишком медленно или даже перестало запускаться. После очистки кэша и последующего запуска программы он будет создан заново, но уже лишен проблем.
Совет 5. Заглядывайте в Мониторинг системы
У пользователей Windows есть «Диспетчер задач», а у владельцев компьютеров Mac «Мониторинг системы». Его можно найти среди других системных утилит в Launchpad. После запуска нас интересуют первые две вкладки: ЦП и Память.
Если какой-то процесс отъедает неожиданно много ресурсов процессора, то его необходимо закрыть. Простое правило, позволяющее зачастую определить программу, тормозящую работу всей системы.
На вкладке «Память» тоже стоит обратить внимание на программы, использующее чересчур много оперативной памяти. Например, этим иногда страдает Safari — браузер вроде бы завис, а на деле не может справиться с огромным куском ОЗУ, который отхватил себе у других программ. Если не хотите ждать несколько минут, пока система разберется сама, то лучше помочь Safari завершить работу принудительно.
Совет 6. Используйте специальный софт для профилактики OS X
Проще всего ухаживать за системой при помощи специального программного обеспечения. Такого для OS X в избытке, но самая популярная и, пожалуй, мощная — CleanMyMac 3. Кроме перечисленных выше операций, она обладает массой других возможностей, которые могут оказаться полезными именно вам. Разумеется, утилита платная.
Зачастую любую проблему в OS X можно победить даже без переустановки системы. Перечисленные выше советы — верный шаг к восстановлению прежней работоспособности компьютера. Главное, что следовать им достаточно просто и совершенно безопасно.
Crash Reports: How To Use Them To Troubleshoot Why Your Mac Crashed
This article’s focus is on macOS crash reports. More specifically this article explains how you can (1) locate crash logs (2) and read them to diagnose a crash.
Your Mac can crash, rarely. These crashes usually mean nothing important, if it is rare. Thus it is not something you should worry about. In most cases, restarting your Mac will resolve the issue. Your Mac will automatically reboot itself.
However, if your Mac is crashing frequently, you may want to find our why these crashes occur so that you can prevent them from happening again. And the most important thing you should do is to find more specific error details.
In this article we are going to take a look at using the crash logs that your system generate. These logs will help you identify what’s causing the crash.
Where to find crash reports
There are two ways to access your crash reports. You can use any of the methods:
How to read macOS crash reports
Understaing these reports can be difficult as they are usually big. Here is how you can decipther a crash report:
1. The first section of a crash report includes what process crashed. Something like this:
In this case, said process is WebKit (Safari).
2. The next section of a crash report includes date/time and operating system, like this:
3. The next section includes more crash details (The Exception), something like this:
There are four common exeption types, according to Apple:
EXC_BAD_ACCESS/KERN_INVALID_ADDRESS — This is caused by the thread accessing unmapped memory. It may be triggered by either a data access or an instruction fetch; the Thread State section describes how to tell the difference.
EXC_BAD_ACCESS/KERN_PROTECTION_FAILURE — This is caused by the thread trying to write to read-only memory. This is always caused by a data access.
EXC_BAD_INSTRUCTION — This is caused by the thread executing an illegal instruction.
EXC_ARITHMETIC/EXC_I386_DIV — This is caused by the thread doing an integer divide by zero on an Intel-based computer.
To understand this section, find the thread that crashed. You can easily find that, because the report will say something like this: Thread (thread number) Crashed. This section explains what lead to the crash.
There are four columns here:
From this example, we know that, for example, “com.apple.WebCore 0x00007fff3e26977a WebCore::HTMLMediaElement::mediaCanStart(WebCore::Document&) + 90” is responsible for the crash.
Now you know what caused the crash and series of events triggered the crash. This will help you idendify the problem and then address it appropriately.
If your problem is a third-party app, you may want to contact its developer. Tell them your problem and you may want to send a copy of this crash log. You can click the share icon in the Console app to send the report.
Serhat Kurt
Dr. Serhat Kurt worked as a Senior Technology Director. He holds a doctoral degree (or doctorate) from the University of Illinois at Urbana / Champaign and a master’s degree from Purdue University. Here is his LinkedIn profile.
Thank you for choosing to leave a comment.
How to Read macOS Crash Reports to Troubleshoot Your Mac
App crashes on the Mac are generally pretty rare. But when they do happen, you might want to trace their cause. And if you’re a developer, you need to understand why your app is crashing. Here’s how to read macOS crash reports and sort through the cryptic language.
Opening Crash Reports
When an app crashes on your Mac, it automatically generates a crash report. You’ll see this appear after the crash with a warning dialog saying “[App] has quit unexpectedly.” That crash report is available to read immediately in that window by clicking the “Report …” button. The crash report can also be found in the Console app.
2. Click on “User Reports” in the left menu, then click on the crash report you want to view. All these files will end in “.crash” and include the date and crashed application in the title. The details of the crash report are available in the pane on the right.
Reading macOS Crash Reports
Let’s navigate the crash report from top to bottom.
What crashed?
The first part of the crash report tells you what “process” or application crashed. The most important part for the average troubleshooter is the process name.
When did it crash?
The second part tells us when the crash occurred. It also provides a little information about your system.
What caused the crash?
The next part is the most illuminating. The”exception type” provided by the application tells us what caused the crash. The log also reports which thread crashed: in this case, thread 0.
Apple lists some common exception types in their technical documentation:
As we can see from our crash report, the application tried to access unmapped memory. This is due to a programming error in the application or an unusual user state causing the application to map memory incorrectly.
What lead to the crash?
After that we see a reverse chronological list of what lead up to the crash. These are sorted by thread, starting with thread 0.
There are four columns to this report. The first reports the event’s number in reverse chronological order, starting at 0. The second is the process’s identifier. The third is the address of the process in memory. The fourth is the name of the program’s task.
This “backtrace” can be somewhat baffling. It’s “symbolicated,” meaning some of the memory addresses have been replaced with function names or application tasks. Sometimes this can’t be done completely, leaving unreadable memory addresses scattered through the report.
We see this in the crash report above: com.trankynam.aText is not symbolicated. Even with complete symbolication, it can be hard to read the backtrace. Sometimes developers include useful notes about application tasks and events. Other times, they’re cryptic titles or numerical code. If you can make sense of the symbolication, you might be able to understand what’s happening. But it’s equally as possible that you’ll need to have coded the application yourself to make sense of the backtrace.
Conclusion: Is This Useful?
If you’re a developer, reading crash reports is essential. It helps you understand what part of your application is crashing and why. If you’re a user, they’re not as helpful. But if you have a persistent crash, the crash reports can help you troubleshoot the issue or work with the developer to fix the problem. You might get a useful error code to Google or be able to provide tech support with the right information. If you want the gory details, you can read all about it in Apple’s technical note on crashes.
Never Miss Out
Receive updates of our latest tutorials.
Alexander Fox is a tech and science writer based in Philadelphia, PA with one cat, three Macs and more USB cables than he could ever use.