MDMP-файл в 1С: что это такое и что с ним делать

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

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

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

Что такое MDMP-файл и зачем он нужен

MDMP (minidump) — это файл в формате минидампа Windows, содержащий часть оперативной памяти процесса на момент аварийного завершения. В нём сохраняются стеки вызовов, значения регистров, список загруженных модулей и другая служебная информация. Платформа 1С формирует такой файл, когда клиентское приложение (толстый, тонкий клиент или веб-компонент) завершается с критической ошибкой, которую невозможно обработать штатно.

Практическое назначение дампа — посмертная диагностика. Разработчики платформы или специалисты поддержки могут загрузить MDMP-файл в отладчик (например, WinDbg) и увидеть, на какой инструкции произошёл сбой, какие библиотеки участвовали и не связана ли ошибка с конкретной версией платформы, драйвером или сторонним ПО.

Где 1С сохраняет MDMP-файлы

Расположение дампов зависит от настроек платформы и операционной системы. По умолчанию платформа 1С складывает аварийные дампы в каталог, указанный в конфигурационном файле, либо в стандартные папки профиля пользователя. Типичные места, где стоит искать MDMP-файлы:

• каталог %APPDATA%\1C\1cv8\dumps или аналогичный в профиле пользователя;
• папка %LOCALAPPDATA%\1C\1cv8 и её подкаталоги;
• каталог, заданный параметром DumpLocation в файле conf.cfg или nethasp.ini-подобных настройках платформы;
• системная папка временных файлов %TEMP% — при некоторых сценариях сбоя;
• на сервере 1С — каталог служебных файлов кластера, если падал рабочий процесс rphost.

Быстрее всего найти дампы поиском по диску: откройте проводник и выполните поиск по маске *.mdmp на системном диске и в профиле пользователя. Если файлов много, отсортируйте результат по дате — свежие дампы соответствуют последним сбоям.

1. 1
   Откройте проводник и перейдите на системный диск
2. 2
   В строке поиска введите маску *.mdmp и дождитесь завершения поиска
3. 3
   Проверьте отдельно каталоги %APPDATA%\1C и %LOCALAPPDATA%\1C
4. 4
   Отсортируйте найденные файлы по дате изменения
5. 5
   Сопоставьте даты файлов с моментами аварийных завершений 1С

Можно ли удалить MDMP-файл

Да, MDMP-файлы можно удалять без вреда для работы 1С и операционной системы. Это не системные компоненты, а диагностические артефакты: платформа не обращается к ним при обычной работе. Удаление дампа не влияет на базы данных, настройки пользователей и лицензии.

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

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

Почему появляются дампы: типичные причины сбоев

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

• нестабильная или несовместимая версия платформы — помогает обновление на актуальный релиз;
• некорректная работа внешних компонентов, драйверов торгового оборудования, антивирусов;
• повреждение кэша метаданных — лечится очисткой кэша или переподключением базы;
• проблемы с оперативной памятью или нехватка ресурсов на сервере;
• повреждение файлов информационной базы (для файлового режима);
• конфликты с обновлениями Windows или сторонними библиотеками.

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

Как использовать дамп для диагностики

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

Открыв дамп в WinDbg (инструмент входит в состав Windows SDK) командой «Open Dump File», вы увидите код исключения и имя модуля, в котором произошёл сбой. Если в верхних строках стека фигурирует сторонняя DLL — например, драйвер сканера, антивирусный фильтр или внешняя компонента — это прямое указание на виновника. Если же в стеке только модули платформы (1cv8.exe, rphost и связанные библиотеки), дамп стоит направить в поддержку вендора.

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

REM Поиск всех дампов 1С на диске C: из командной строки
dir C:\*.mdmp /s /b

Как уменьшить количество аварийных завершений

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

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

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

Контроль результата и границы самостоятельной работы

Признак того, что проблема решена: после принятых мер (очистка кэша, обновление платформы, отключение конфликтующего ПО) новые MDMP-файлы перестали появляться при тех же действиях, которые раньше вызывали сбой. Проверяйте каталог дампов несколько дней подряд — единичное «тихое» наблюдение ещё не доказывает устойчивость.

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

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