Администрирование · 12 мин
Как прочитать дампы 1С и понять причину аварийного завершения
Разбираем, как прочитать дампы 1С: виды дампов, инструменты анализа, типовые ошибки и порядок действий при аварийном завершении платформы.
Когда платформа 1С:Предприятие падает с ошибкой, она часто оставляет после себя аварийный дамп — файл с «снимком» памяти процесса в момент сбоя. По этому файлу можно понять, что именно вызвало падение: ошибку во внешней компоненте, нехватку памяти, повреждённую базу или проблему в самом коде конфигурации. Умение читать дампы экономит часы тестирования «методом научного тыка».
Под «дампами 1С» обычно понимают три разные вещи: аварийные дампы процесса (minidump или full dump), которые платформа или Windows создаёт при падении; технологический журнал, который фиксирует события до сбоя; и дампы базы данных (например, выгрузку dt или SQL-бэкап). В этой статье речь идёт именно об аварийных дампах процесса — самых информативных при диагностике падений.
Анализ дампа — задача на стыке администрирования и разработки. Полноценно разобрать стек вызовов без символов отладки сложно, но даже базовое чтение дампа позволяет определить модуль-виновник, тип исключения и обстоятельства сбоя. Этого достаточно, чтобы принять решение: обновить платформу, отключить компоненту или обратиться в поддержку с готовым материалом.
Какие дампы создаёт 1С и где их искать
При аварийном завершении клиентского или серверного процесса 1С (1cv8.exe, rphost, ragent, rmngr) Windows может создать дамп автоматически через службу WER (Windows Error Reporting). Стандартные расположения: %LOCALAPPDATA%\CrashDumps для пользовательских процессов и %ProgramData%\Microsoft\Windows\WER для системных отчётов. Платформа 1С также может писать собственные дампы в каталог, указанный в настройках технологического журнала.
Различают два основных вида дампов. Minidump — компактный файл, содержащий стек вызовов, список загруженных модулей и базовую информацию об исключении; его достаточно для определения модуля-виновника. Full dump — полный снимок памяти процесса, который может занимать гигабайты, но позволяет исследовать содержимое переменных и состояние объектов. Для первичной диагностики обычно хватает minidump.
Если дампы не создаются автоматически, их можно получить принудительно: через Диспетчер задач (правый клик по процессу → «Создать файл дампа памяти») — но только пока процесс ещё жив, или настроив автоматический сбор через реестр Windows либо утилиту ProcDump. Для сервера 1С, где сбои происходят непредсказуемо, заранее настроенный ProcDump — самый надёжный вариант.
Как настроить автоматический сбор дампов
Чтобы не гадать после сбоя, настройте сбор дампов заранее. Самый простой способ для Windows — добавить параметры в реестр по пути HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps: указать папку сохранения (DumpFolder), тип дампа (DumpType: 1 — minidump, 2 — full dump) и максимальное количество файлов. После этого система будет автоматически складывать дампы всех падающих процессов в заданный каталог.
Для прицельного сбора дампов конкретного процесса удобна утилита ProcDump из комплекта Sysinternals. Она умеет создавать дамп при необработанном исключении, при превышении порога памяти или по конкретному коду исключения. Это особенно полезно для rphost, который может падать раз в несколько дней под нагрузкой.
procdump -accepteula -e -ma -x C:\Dumps "C:\Program Files\1cv8\...\bin\rphost.exe"Параметр -e означает дамп при необработанном исключении, -ma — полный дамп с памятью, -x — запуск процесса под контролем ProcDump. Для уже работающего процесса вместо пути к exe укажите PID. Учтите, что полный дамп большого rphost может занять десятки гигабайт — проверьте свободное место на диске заранее.
Как открыть и прочитать дамп в WinDbg
Основной инструмент анализа — WinDbg (классический или WinDbg Preview из Microsoft Store). Откройте файл дампа через File → Open Dump File. Первое, что стоит сделать — выполнить команду !analyze -v: отладчик автоматически определит тип исключения, покажет стек вызовов проблемного потока и укажет модуль, в котором произошёл сбой.
Ключевые поля в выводе анализа: EXCEPTION_CODE (код исключения, например c0000005 — нарушение доступа к памяти), FAULTING_MODULE или MODULE_NAME (модуль-виновник) и STACK_TEXT (стек вызовов). Если в верхних фреймах стека фигурирует сторонняя DLL — внешняя компонента, драйвер принтера, антивирусный модуль — с высокой вероятностью именно она является причиной падения.
- 1Откройте дамп: File → Open Dump File
- 2Выполните команду !analyze -v и дождитесь результата
- 3Найдите EXCEPTION_CODE и MODULE_NAME — это тип сбоя и виновник
- 4Изучите STACK_TEXT: верхние фреймы показывают, где произошло падение
- 5Командой lmvm имя_модуля посмотрите версию проблемной DLL
- 6Сопоставьте вывод с событиями технологического журнала за то же время
Без символов отладки (PDB-файлов) имена функций внутри модулей 1С будут отображаться как смещения адресов — это нормально. Для диагностики обычно достаточно увидеть, что падение произошло внутри конкретной DLL: например, в модуле внешней компоненты, в библиотеке СУБД-клиента или в самом ядре платформы. Символы для системных библиотек Windows подтягиваются автоматически с сервера Microsoft.
Как интерпретировать типичные коды ошибок
Код исключения — главная зацепка при чтении дампа. Он указывает на характер проблемы ещё до анализа стека. Ниже — наиболее частые коды, встречающиеся в дампах 1С, и их типовые причины.
| Код исключения | Значение | Типичные причины в 1С |
|---|---|---|
| c0000005 | Нарушение доступа к памяти (Access Violation) | Внешние компоненты, повреждённая база, ошибки платформы |
| c00000fd | Переполнение стека | Бесконечная рекурсия в коде конфигурации |
| e0434352 | Исключение .NET | COM-объекты, .NET-компоненты, интеграционные решения |
| c0000409 | Нарушение целостности стека (buffer overrun) | Устаревшие DLL, конфликт антивируса с платформой |
| 80000003 | Точка останова | Намеренная остановка, отладочные проверки в коде |
Самый частый случай — c0000005. Сам по себе этот код говорит лишь о том, что код попытался обратиться к недопустимому адресу памяти. Причину подсказывает модуль из стека: если это DLL внешней компоненты — отключите её и проверьте, пропал ли сбой; если системная библиотека — проверьте антивирус и обновления Windows; если модуль платформы 1С — вероятен известный дефект конкретной версии, стоит проверить обновления.
Как выбрать действие по результату анализа
Как связать дамп с технологическим журналом
Дамп показывает момент смерти процесса, но не показывает, что происходило до сбоя. Эту картину восполняет технологический журнал 1С. Настройте его через файл logcfg.xml: включите события EXCP (исключения), EXCPCNTX (контекст исключений), а при необходимости — DBMSSQL или DBPOSTGRS для запросов к СУБД. Журнал размещайте на диске с достаточным объёмом и настройте ротацию.
Методика сопоставления проста: из дампа возьмите точное время сбоя (WinDbg показывает его в шапке анализа), затем найдите в техжурнале события за несколько секунд до этого момента. Часто там обнаруживается последний выполнявшийся запрос, операция или вызов — это и есть контекст, который привёл к падению. Например, если падение произошло при формировании конкретного отчёта, в журнале будет виден его запрос.
Событие EXCPCNTX в технологическом журнале фиксирует контекст исключений, включая те, что были обработаны и не привели к падению. Если в журнале регулярно встречается одно и то же исключение в одном и том же месте кода, а затем процесс падает — почти наверняка эти события связаны, и исправлять нужно именно тот участок кода.
Частые ошибки при работе с дампами
Первая ошибка — анализировать дамп в отрыве от версий ПО. Одна и та же ошибка может быть давно исправлена в свежем релизе платформы, поэтому перед глубоким разбором проверьте версию платформы (команда lmvm в WinDbg покажет версии модулей) и сопоставьте с известными исправлениями. Часто «загадочное падение» решается простым обновлением.
Вторая ошибка — собирать дампы без технологического журнала. Дамп без контекста даёт лишь половину картины: вы увидите, где упал процесс, но не поймёте, какая операция пользователя к этому привела. Третья типичная проблема — нехватка места: полный дамп большого процесса может не записаться целиком, и повреждённый файл не откроется в отладчике. Всегда проверяйте, что дамп создан полностью и его размер адекватен.
Когда самостоятельного анализа недостаточно
Базовое чтение дампа доступно любому администратору, но есть ситуации, где нужны глубокие знания отладки: сбои внутри ядра платформы без очевидного виновника, повреждения кучи (heap corruption), которые проявляются далеко от места реальной ошибки, и гонки потоков в многопоточном коде. В таких случаях дамп и техжурнал передают в техническую поддержку фирмы «1С» или разработчику компоненты — с готовым материалом обращение решается заметно быстрее.
Перед отправкой соберите комплект: сам дамп, фрагмент технологического журнала за период сбоя, версии платформы и конфигурации, описание действий, приводящих к падению, и информацию о повторяемости. Если сбой воспроизводится на конкретной операции — это самый ценный факт, укажите его первым.
Как проверить результат
Команда !analyze -v выдаёт код исключения и стек
Отладчик сообщает о повреждённом файле — дамп не дописался
Падение воспроизводится на одной операции
Сбои случайны и в разных модулях — проверяйте память сервера и диски
Сбои прекратились — виновник найден
Падения продолжаются — анализируйте следующий модуль в стеке
Что важно запомнить
Настройте сбор дампов и технологический журнал заранее, до сбоя. Анализ начинайте с кода исключения и модуля-виновника в WinDbg, затем сопоставляйте с событиями техжурнала. Чаще всего виноваты внешние компоненты, антивирус или конкретная версия платформы. Помните о конфиденциальности данных в полных дампах.
Частые вопросы о чтении дампов 1С
Чем открыть файл дампа 1С, если нет WinDbg?
Минимальную информацию даёт «Просмотр событий» Windows: в журнале «Приложение» записи об ошибке приложения содержат имя модуля-виновника и код исключения. Также дампы небольшого размера можно открыть в Visual Studio (File → Open → File), которая покажет стек и модули без глубокой настройки.
Почему при падении 1С дамп не создаётся?
Чаще всего не настроен LocalDumps в реестре, не хватает места на диске или процесс завершается не аварийно, а штатно (например, его «убивает» кластер серверов 1С при превышении лимита памяти). Проверьте настройки WER и используйте ProcDump для гарантированного сбора.
Можно ли по дампу понять, какой пользователь вызвал сбой?
Напрямую в дампе эта информация обычно недоступна в читаемом виде. Пользователя и операцию определяют по технологическому журналу: находят события на том же рабочем процессе в момент сбоя и смотрят имя пользователя и контекст вызова.
Что делать, если виновник — сама платформа 1С?
Проверьте, не исправлена ли ошибка в более новых релизах платформы, и обновитесь на тестовой среде. Если версия актуальная — оформите обращение в поддержку с дампом, техжурналом и сценарием воспроизведения. Как временную меру иногда помогает обходной путь: изменение алгоритма операции, вызывающей падение.
Чем отличается дамп процесса от выгрузки базы в dt?
Это разные вещи. Дамп процесса — снимок памяти программы в момент сбоя, нужен для диагностики падений. Файл dt — выгрузка информационной базы для переноса или архивации, к аварийным дампам отношения не имеет и для анализа сбоев не используется.
Опасно ли включать постоянный сбор дампов на сервере?
Сам по себе сбор дампов не нагружает систему — файл создаётся только в момент сбоя. Риски другие: расход дискового пространства при частых падениях и конфиденциальность содержимого. Ограничьте количество хранимых дампов и доступ к папке, и мониторьте свободное место.