Чем посмотреть дамп 1С: рабочие инструменты и порядок анализа

Словом «дамп» в контексте 1С называют два разных объекта, и путаница между ними — первая причина бесплодных попыток «открыть файл». Первый тип — дамп памяти процесса (файл .dmp), который создаётся при аварийном завершении платформы или принудительно для диагностики зависания. Второй — файл выгрузки информационной базы (.dt), который администраторы тоже часто называют дампом. Инструменты для этих файлов совершенно разные.

Дамп памяти (.dmp) содержит снимок адресного пространства процесса 1cv8.exe, rphost.exe или ragent.exe на момент сбоя. Его нельзя «прочитать как текст»: это бинарный слепок памяти, который анализируют отладчиками. Файл выгрузки (.dt) — это архив базы в формате платформы, который восстанавливается через конфигуратор, а не «просматривается» напрямую.

Выбор инструмента зависит от задачи: понять причину падения, найти зависший запрос, вытащить данные из выгрузки или просто оценить, что вообще находится в файле. Ниже разобраны рабочие варианты для каждого сценария — от штатных средств Windows до отладчиков и специализированных утилит.

Сначала определите, какой у вас дамп

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

Если файл получен от коллег или скачан с сервера без пояснений, откройте его в любом hex-редакторе и посмотрите первые байты. У дампов памяти Windows в начале стоит сигнатура MDMP, у файлов выгрузки 1С — собственная структура, начинающаяся с текстового заголовка. Это надёжный способ отличить форматы, когда расширение переименовано.

Как посмотреть дамп памяти через WinDbg

WinDbg (входит в Windows SDK, также доступен как WinDbg Preview в Microsoft Store) — основной инструмент анализа дампов .dmp. Он показывает стеки вызовов потоков, загруженные модули и состояние процесса на момент сбоя.

1. 1
   Установите WinDbg из Microsoft Store или через Windows SDK (компонент Debugging Tools)
2. 2
   Откройте файл через File → Open Dump File и дождитесь загрузки
3. 3
   Выполните команду !analyze -v для автоматического анализа исключения
4. 4
   Командой ~* kb выведите стеки всех потоков и найдите поток с исключением
5. 5
   Настройте символы командой .symfix и перезагрузите их через .reload, чтобы стеки стали читаемыми

Ключевое, что даёт WinDbg, — стек вызовов в момент падения. Если в верхних фреймах видны модули самой платформы (например, frame.dll, core83.dll), проблема скорее в платформе или коде конфигурации. Если падает сторонняя DLL (драйвер, антивирус, COM-компонента), направление поиска меняется. Без файлов символов стеки будут состоять из адресов, поэтому настройка путей к символам Microsoft (.symfix) заметно улучшает читаемость.

Полноценный анализ дампа требует опыта чтения стеков и понимания внутреннего устройства Windows. Если стек указывает на внутренние модули платформы без очевидной причины, разумный шаг — передать дамп в поддержку 1С через портал, приложив описание сценария и версию платформы.

Альтернативы: DebugDiag, Process Explorer и ProcDump

DebugDiag от Microsoft — более «дружелюбный» инструмент: он сам строит отчёт по дампу с перечнем потоков, исключений и подозрительных модулей. Для первичной оценки (что упало, какой модуль виноват) его часто достаточно, и глубоких навыков отладки он не требует.

Process Explorer и ProcDump из пакета Sysinternals нужны не столько для просмотра, сколько для получения дампа. Если 1С завис, но не упал, дамп снимают принудительно: в Process Explorer правой кнопкой по процессу → Create Dump → Create Full Dump. ProcDump делает то же из командной строки и умеет автоматически создавать дамп при падении или превышении порога памяти.

procdump -ma -e 1cv8.exe C:\dumps\

Команда выше создаст полный дамп процесса клиента 1С при возникновении необработанного исключения. Для серверного процесса замените имя на rphost.exe; если рабочих процессов несколько, указывайте конкретный PID вместо имени.

Как «посмотреть» файл выгрузки .dt

Файл .dt — это не дамп памяти, а упакованная копия информационной базы. Штатный способ работы с ним один: создать пустую базу, зайти в конфигуратор и выполнить «Администрирование → Загрузить информационную базу». После загрузки данные доступны обычными средствами — через конфигуратор, запросы или пользовательский режим.

Если нужно быстро проверить, что внутри .dt, без полной загрузки, есть неофициальные варианты. Утилита v8unpack (открытый проект) разбирает файл выгрузки на составляющие — конфигурацию, таблицы, метаданные. Это полезно, когда нужно извлечь только конфигурацию или оценить целостность файла. Инструмент не поддерживается вендором, поэтому используйте его на копии файла.

Минимальную проверку содержимого можно сделать и вручную: .dt имеет блочную структуру, и в hex-редакторе видны имена объектов метаданных в читаемом виде. Это позволяет убедиться, что файл действительно выгрузка нужной конфигурации, прежде чем тратить время на загрузку.

Дампы технологического журнала и аварийные дампы платформы

Платформа 1С умеет создавать дампы автоматически при аварийном завершении, если это включено в настройках технологического журнала (файл logcfg.xml, элемент dump). Такие дампы складываются в указанный каталог и обычно являются мини-дампами — компактными слепками с основной информацией об исключении.

Анализируются эти файлы теми же WinDbg и DebugDiag. Практический момент: мини-дамп без символов платформы часто показывает только то, что исключение произошло внутри модулей 1С. В такой ситуации самый продуктивный путь — отправить дамп вместе с логом технологического журнала в поддержку, а самостоятельно сосредоточиться на воспроизводимости: на какой операции, у каких пользователей и с какой периодичностью происходит падение.

Частые ошибки при работе с дампами

Отдельно стоит упомянуть разрядность: если клиент 1С 32-битный, а дамп снят 64-битной утилитой, WinDbg покажет искажённые стеки. Признак — нереалистичные адреса и отсутствие знакомых модулей. Решение — переснять дамп инструментом той же разрядности, что и процесс.

Как проверить, что анализ дал результат

Если анализ зашёл в тупик, не удаляйте дамп: сохраните его вместе с версией платформы, конфигурацией режима работы (файловый/клиент-серверный) и описанием действий пользователя. Этот комплект понадобится и при обращении в поддержку, и при повторном анализе после обновления платформы.

FAQ