Чем открыть MDMP-файл 1С и как его проанализировать

Файл с расширением .mdmp (minidump) — это аварийный дамп памяти, который платформа 1С создаёт при нештатном завершении работы: падении тонкого или толстого клиента, веб-клиента, агента сервера 1С или rphost. Обычно такие файлы появляются в каталоге dumps внутри технологического журнала либо в папке временных файлов пользователя, и их наличие — прямой признак аварийного завершения процесса.

Открыть MDMP «как документ» нельзя: это бинарный снимок памяти процесса, и для его чтения нужны отладчики — WinDbg, Visual Studio или консольные средства Windows. Однако прежде чем погружаться в отладку, стоит понять, какая цель стоит: выяснить причину падения самостоятельно, передать дамп в техподдержку 1С или просто очистить диск от накопившихся файлов.

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

Что такое MDMP-файл и когда 1С его создаёт

Minidump — это компактный снимок состояния процесса в момент сбоя: стеки вызовов потоков, список загруженных модулей (DLL), части памяти и регистры процессора. В отличие от полного дампа, minidump занимает обычно от нескольких мегабайт до нескольких сотен мегабайт и при этом содержит достаточно данных, чтобы определить, в каком модуле произошла ошибка.

Платформа 1С:Предприятие создаёт дампы при фатальных ошибках — нарушении доступа к памяти (access violation), переполнении стека, необработанных исключениях. Типичные ситуации: падение клиента при открытии конкретной формы, авария rphost при выполнении запроса, вылет при работе внешней компоненты или COM-объекта.

Важно понимать: сам по себе MDMP не объясняет, почему произошла ошибка, — он показывает, где она возникла. Если в стеке верхним окажется модуль сторонней компоненты или драйвера, причина, скорее всего, вне платформы 1С.

Где искать MDMP-файлы на компьютере

Расположение дампов зависит от того, какой процесс упал и как настроен технологический журнал. Стандартные места:

• каталог технологического журнала, подпапка dumps — если дампы включены в logcfg.xml;
• папка временных файлов пользователя: %TEMP% (обычно C:\Users\Имя\AppData\Local\Temp);
• для сервера 1С — каталог srvinfo, подпапка reg_1541\dumps или аналогичная для кластера;
• системная папка Windows: C:\ProgramData\Microsoft\Windows\WER\ReportQueue — сюда попадают данные службы отчётов об ошибках.

Быстрее всего найти файлы поиском по диску с маской *.mdmp и сортировкой по дате изменения. Обратите внимание на имя файла: оно часто содержит имя упавшего процесса (например, 1cv8, rphost, rmngr) и метку времени — это помогает связать дамп с конкретным инцидентом.

Чем открыть MDMP: обзор инструментов

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

WinDbg — основной инструмент

WinDbg входит в состав Debugging Tools for Windows, которые устанавливаются вместе с Windows SDK. Это стандарт де-факто для анализа дампов Windows-приложений, включая 1С. Существует классическая версия и современная WinDbg Preview из Microsoft Store — обе справляются с задачей.

Visual Studio

Если на машине установлена Visual Studio, MDMP можно открыть через меню «Файл → Открыть → Файл». Среда покажет сводку дампа, стек вызовов и модули. Это удобно для быстрого просмотра, но для полноценного анализа WinDbg информативнее.

Простой просмотр без отладчика

Если цель — только понять, какой процесс и когда упал, достаточно имени файла и журнала событий Windows (Просмотр событий → Журналы Windows → Приложение). Событие с источником Application Error или Windows Error Reporting содержит имя модуля-виновника, что часто решает вопрос без открытия дампа.

Сравнение инструментов

WinDbg

Подходит для глубокого анализа: стеки, исключения, модули. Требует установки SDK и базовых навыков отладки

Visual Studio

Подходит для быстрого просмотра стека и модулей. Ограничение — нужна установленная среда разработки

Журнал событий Windows

Подходит для определения модуля-виновника без открытия дампа. Не показывает стек вызовов

Передача в техподдержку

Подходит, когда нет навыков отладки. Ограничение — сроки ответа и необходимость описания сценария воспроизведения

Настройка создания дампов в 1С

Если дампы не создаются или нужны более подробные, их формирование настраивается через файл конфигурации технологического журнала logcfg.xml, который размещается в каталоге conf установки платформы (для клиента) или в каталоге кластера сервера.

Минимальная конфигурация для включения дампов выглядит так:

<config xmlns="http://v8.1c.ru/v8/tech-log">
<dump create="true" location="C:\1cdumps" type="1"/>
</config>

Параметр type задаёт тип дампа: 0 — мини-дамп, 1 — дамп с дополнительной информацией о сегментах памяти, 2 — полный дамп. Для первичной диагностики обычно достаточно типа 0 или 1; полный дамп (тип 2) может занимать гигабайты и оправдан только по запросу специалистов поддержки.

Убедитесь, что каталог, указанный в location, существует и у процесса 1С есть права на запись в него. Для сервера 1С запись выполняется от имени учётной записи агента сервера — это частая причина «молчаливого» отсутствия дампов.

Как открыть и проанализировать MDMP в WinDbg

Порядок действий для первичной диагностики в WinDbg:

1. Установите Windows SDK с компонентом Debugging Tools for Windows или WinDbg Preview из Microsoft Store.
2. Запустите WinDbg и откройте дамп: File → Open Dump File, укажите путь к .mdmp.
3. Настройте путь к символам Microsoft командой в окне команд: .symfix — отладчик подтянет публичные символы с серверов Microsoft.
4. Выполните команду !analyze -v и дождитесь завершения автоматического анализа.
5. Изучите блоки: EXCEPTION_CODE (код исключения), MODULE_NAME и IMAGE_NAME (модуль-виновник), STACK_TEXT (стек вызовов).

Ключевая строка результата — MODULE_NAME. Если там модуль платформы (например, core82, frntend, dbeng8) — вероятна ошибка платформы, и дамп стоит направить в 1С вместе с описанием сценария. Если там сторонняя DLL (драйвер принтера, антивируса, внешняя компонента) — причину нужно искать в этом ПО: обновить, отключить или заменить.

Команда lmvm имя_модуля покажет версию модуля-виновника, что помогает понять, установлены ли актуальные обновления платформы или драйвера.

1. 1
   Найдите файл дампа и зафиксируйте время его создания
2. 2
   Проверьте журнал событий Windows на предмет Application Error в тот же момент
3. 3
   Проверьте, воспроизводится ли падение на том же действии
4. 4
   Откройте дамп в WinDbg и выполните !analyze -v
5. 5
   Определите модуль-виновник: платформа, сторонняя DLL или драйвер
6. 6
   Обновите платформу или проблемное ПО, очистите кэш клиента
7. 7
   При повторении — направьте дамп и сценарий в техподдержку 1С

Типичные причины падений и что с ними делать

По практике большинство аварийных завершений 1С сводится к ограниченному набору причин. Повреждённый клиентский кэш метаданных лечится очисткой папки с кэшем (удаление базы из списка и повторное добавление либо очистка каталогов в %APPDATA%\1C\1cv8). Устаревшая версия платформы нередко конфликтует с новыми обновлениями Windows — обновление платформы до актуального релиза устраняет значительную часть падений.

Внешние компоненты, COM-объекты и драйверы оборудования (сканеры, ККТ, принтеры) — второй по частоте источник аварий. Если в стеке дампа виден модуль такого ПО, проверьте наличие обновлений у поставщика. Антивирусные драйверы также фигурируют в дампах нередко: временное добавление процессов 1С в исключения антивируса помогает проверить эту гипотезу.

Отдельный случай — нехватка памяти у rphost на сервере. Здесь дамп может сопровождаться ростом потребления памяти до падения. Помогает настройка ограничений кластера (максимальный объём памяти рабочих процессов, перезапуск по расписанию) и анализ тяжёлых запросов в технологическом журнале.

Когда передавать дамп в техподдержку 1С

Самостоятельный анализ разумен, когда виновник очевиден (сторонняя DLL, кэш, драйвер) и устраняется локально. Если же в стеке — модули платформы, падение воспроизводится стабильно и обновление платформы не помогает, дамп следует направить в службу поддержки 1С через портал или партнёра.

К обращению приложите: сам MDMP-файл, точную версию платформы и конфигурации, пошаговое описание действий, приводящих к падению, и фрагмент технологического журнала за момент сбоя. Чем точнее сценарий воспроизведения, тем быстрее локализуют дефект.

Очистка и хранение дампов

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

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

Частые вопросы

Можно ли открыть MDMP обычным блокнотом или просмотрщиком?

Технически файл откроется, но содержимое будет бинарным «мусором» с отдельными читаемыми строками имён модулей. Полезной диагностической информации такой способ не даст — нужен отладчик, который интерпретирует структуру дампа.

Опасно ли удалять MDMP-файлы?

Нет. Дампы — это диагностические снимки, а не рабочие данные. Их удаление не влияет на базу 1С и настройки. Удаляйте после разбора инцидента или передачи файла в поддержку.

Почему дампы не создаются, хотя 1С падает?

Чаще всего не настроен logcfg.xml, указанный каталог не существует или у процесса нет прав на запись в него. Для сервера проверьте права учётной записи службы агента. Также часть падений перехватывает Windows Error Reporting — смотрите папку ProgramData\Microsoft\Windows\WER.

Чем отличается MDMP от полного дампа памяти?

Minidump содержит только стеки, список модулей и минимум памяти — этого хватает для определения модуля-виновника. Полный дамп копирует всю память процесса, занимает гигабайты и нужен лишь для глубокой диагностики по запросу разработчиков.

В дампе виновата DLL антивируса. Что делать?

Добавьте процессы 1С (1cv8.exe, rphost.exe, rmngr.exe) и каталоги платформы в исключения антивируса и проверьте, прекратились ли падения. Если да — обновите антивирус или сообщите о проблеме его разработчику.

Можно ли понять причину падения вообще без открытия дампа?

Частично. Журнал событий Windows (источник Application Error) показывает имя упавшего модуля и код исключения. Этого достаточно, чтобы понять, виновата платформа или стороннее ПО, но стек вызовов и контекст ошибки доступны только при анализе дампа.