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

Файл с расширением .mdmp — это мини-дамп памяти, который операционная система или сама платформа создаёт в момент аварийного завершения процесса. В контексте 1С такие файлы появляются, когда клиентское приложение или сервер 1С «падает» с ошибкой, и внутри дампа зафиксировано состояние потоков, стек вызовов и загруженные модули на момент сбоя.

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

Важно понимать ограничения: мини-дамп содержит сокращённый объём данных, поэтому глубокий анализ (например, значения переменных внутри кода 1С) по нему часто невозможен. Для полноценной диагностики иногда требуется полный дамп, который настраивается отдельно. Ниже разберём, где искать дампы 1С, чем их открыть и какие выводы можно сделать самостоятельно.

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

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

Платформа 1С:Предприятие формирует дампы при аварийном завершении тонкого клиента, толстого клиента, веб-клиента на стороне сервера или рабочего процесса rphost. Типичные причины падений: ошибки в самой платформе, конфликт с внешними компонентами и драйверами, нехватка памяти, повреждённый кэш метаданных, сбои оборудования.

Расположение дампов зависит от настроек. По умолчанию платформа может складывать их в каталог временных файлов пользователя или в каталог, заданный параметром конфигурации. Также Windows может создавать дампы через механизм Windows Error Reporting в папке ProgramData. Если дампов нет вообще — проверьте, не отключено ли их создание в настройках системы и платформы.

Где искать дампы и как включить их создание

Прежде чем открывать файл, его нужно найти. Проверьте типовые места: каталог временных файлов пользователя (путь можно увидеть через переменные окружения TEMP/TMP), системный каталог Windows Error Reporting и каталоги, указанные в настройках агента сервера 1С. Файлы обычно имеют вид «имя_процесса_дата_время.mdmp».

Для управления дампами в Windows используется ветка реестра LocalDumps, где задаются папка сохранения (DumpFolder), тип дампа (DumpType) и максимальное количество файлов. Это системная настройка, поэтому изменения в реестре делайте аккуратно и только понимая, что меняете.

Если падение воспроизводится, удобно заранее подключить утилиту ProcDump из набора Sysinternals: она следит за процессом (например, 1cv8.exe или rphost.exe) и автоматически записывает дамп в момент исключения. Это надёжнее, чем надеяться на штатный механизм.

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

Команда выше указывает ProcDump ждать необработанное исключение (-e) процесса 1cv8.exe и сохранить полный дамп (-ma) в папку C:\Dumps. Для мини-дампа флаг -ma можно опустить.

Открытие MDMP в WinDbg: базовый анализ

WinDbg — основной инструмент анализа дампов в Windows. Он входит в состав Windows SDK (компонент Debugging Tools for Windows). После установки откройте файл через меню File → Open Dump File или перетащите mdmp в окно программы.

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

!analyze -v
lm
kv

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

1. 1
   Установите Debugging Tools for Windows из состава Windows SDK
2. 2
   Откройте MDMP-файл через File → Open Dump File
3. 3
   Настройте путь к символам Microsoft (SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols)
4. 4
   Выполните команду !analyze -v и дождитесь результата
5. 5
   Найдите строки EXCEPTION_CODE и MODULE_NAME / IMAGE_NAME
6. 6
   Проверьте стек командой kv: какие DLL участвовали в вызовах
7. 7
   Сделайте вывод: сбой в модуле 1С, сторонней DLL или системном компоненте

Открытие MDMP в Visual Studio и других инструментах

Если на машине установлена Visual Studio, MDMP-файл можно открыть прямо в ней: File → Open → File или перетаскивание в окно IDE. Студия покажет сводку по дампу: код исключения, список модулей, потоки. Кнопка Debug with Mixed/Native позволяет запустить отладку по дампу, если доступны символы и исходники.

Для администратора без опыта отладки Visual Studio удобна тем, что сразу визуально показывает стек вызовов и список загруженных библиотек. Часто уже по имени сбойной DLL понятно направление: антивирусный драйвер, видеодрайвер, внешняя компонента или модуль платформы.

Альтернативные инструменты: DebugDiag от Microsoft (умеет автоматически анализировать дампы и строить отчёт в HTML), BlueScreenView-подобные утилиты для дампов ядра (к MDMP приложений не подходят), а также встроенный просмотр через Process Explorer для живых процессов. Для разового анализа чаще всего достаточно WinDbg или Visual Studio.

Как интерпретировать результаты анализа

Ключевые поля в выводе !analyze -v: EXCEPTION_CODE (код исключения, например c0000005 — нарушение доступа к памяти), FAULTING_MODULE или IMAGE_NAME (модуль-виновник) и стек вызовов. Код c0000005 — самый частый при падениях 1С и сам по себе лишь говорит, что программа обратилась к недопустимой области памяти.

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

Полезно сопоставить дамп с технологическим журналом 1С и журналом событий Windows (источник Application Error). Совпадение по времени и модулю подтверждает диагноз. Если падение происходит только при конкретном действии в конфигурации — например, при формировании отчёта, — зафиксируйте сценарий: это сильно упростит работу разработчикам.

Типичные ошибки и ограничения при работе с дампами

Самая частая ошибка — попытка открыть MDMP текстовым редактором или «конвертировать» его в читаемый вид. Файл бинарный, осмысленной текстовой информации в нём почти нет. Вторая ошибка — анализ дампа без символов: стек превращается в набор адресов, и выводы становятся гаданием.

Ещё одна проблема — анализ не того файла. При повторяющихся падениях в папке копятся десятки дампов; всегда сверяйте дату файла с моментом инцидента. Также помните: мини-дамп не показывает содержимое данных 1С и значения переменных прикладного кода — требовать от администратора «найти ошибку в конфигурации по дампу» некорректно.

Дампы могут содержать фрагменты оперативной памяти процесса, включая чувствительные данные (логины, фрагменты документов). Передавая файл третьим лицам, учитывайте это и ограничивайте круг получателей. Храните дампы в папке с ограниченным доступом и удаляйте после завершения диагностики.

Когда передавать дамп разработчикам или в поддержку

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

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

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

FAQ: частые вопросы про MDMP-файлы 1С