Дамп памяти 1С после аварийного завершения: откуда берётся .mdmp и что из него можно вытащить

Файл с расширением .mdmp в 1С — это дамп памяти процесса, который платформа записывает в момент аварийного завершения: клиента 1cv8c.exe, толстого клиента 1cv8.exe или рабочего процесса сервера rphost.exe. Открыть его можно бесплатным отладчиком WinDbg от Microsoft. Самое полезное, что даёт анализ дампа без доступа к отладочным символам 1С, — имя модуля, в котором случился сбой: DLL самой платформы, внешней компоненты, антивируса, драйвера принтера или видеокарты.

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

Что лежит внутри дампа памяти 1С

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

В дампе записано:

• 🧵 Потоки процесса и стек вызовов каждого из них — какая функция вызывала какую в момент сбоя.
• 📦 Список загруженных модулей — все DLL с версиями и адресами: модули платформы, системные библиотеки, внедрённые сторонние библиотеки.
• ⚡ Запись об исключении — код ошибки (например, 0xC0000005 — нарушение доступа к памяти) и адрес, где оно произошло.
• 💾 Содержимое памяти — в минимальном варианте только небольшие фрагменты, в полном — вся память процесса.

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

Как называется файл

Имя дампа собирается из имени процесса, номера версии платформы и служебного суффикса. По нему сразу видно, что упало: 1cv8c — тонкий клиент, 1cv8 — толстый клиент или Конфигуратор, rphost — рабочий процесс сервера, rmngr — менеджер кластера, ragent — агент сервера. Номер версии в имени помогает понять, на какой сборке платформы случился сбой, если на компьютере их установлено несколько.

Почему платформа 1С создаёт MDMP-файлы

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

Частые источники аварийного завершения:

• 🧩 Внешние компоненты. Драйверы торгового оборудования, библиотеки обмена с банками, компоненты для работы с маркировкой. Ошибка в такой DLL роняет весь процесс 1С.
• 🛡️ Антивирусы и средства защиты, которые внедряют свои библиотеки в каждый процесс. В списке модулей дампа они видны сразу.
• 🖨️ Драйверы принтеров — классика падений при печати и предварительном просмотре.
• 🖥️ Видеодрайверы — падения при открытии форм, диаграмм, при прокрутке больших отчётов.
• 📈 Нехватка памяти. Особенно у 32-разрядного клиента, которому доступно не больше 4 ГБ, и у rphost при тяжёлом запросе или выгрузке.
• 🔁 Бесконечная рекурсия в коде конфигурации — переполнение стека (0xC00000FD).
• 🐞 Ошибки самой платформы в конкретной сборке. Такие дампы обычно повторяются на одних и тех же действиях и исчезают после смены версии.
• 🔌 Сторонние COM-объекты и надстройки, вызываемые из кода через Новый COMОбъект.

Где искать дампы клиента и сервера

Клиентские дампы платформа складывает в профиль пользователя, в каталог 1C\1cv8\dumps. Проверьте оба расположения:

%LOCALAPPDATA%\1C\1cv8\dumps
%APPDATA%\1C\1cv8\dumps

Вставьте строку в адресную строку Проводника — переменная развернётся в путь текущего пользователя. На терминальном сервере у каждого пользователя свой каталог.

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

Быстрый поиск по всему диску из PowerShell:

Get-ChildItem -Path C:\ -Filter *.mdmp -Recurse -ErrorAction SilentlyContinue |
  Sort-Object LastWriteTime -Descending |
  Select-Object FullName, Length, LastWriteTime -First 20

Дату создания файла сверьте со временем сбоя у пользователя — так вы отбросите старые дампы и возьмёте нужный.

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

Важное ограничение: отладочные символы (PDB-файлы) платформы 1С в открытом доступе не публикуются. Поэтому в WinDbg функции внутри модулей 1С вы увидите как смещения вида core83+0x1a2b3c, а не как имена. Для системных DLL Microsoft символы скачаются автоматически. На практике этого достаточно, чтобы решить главный вопрос — виновата платформа или посторонний модуль.

WinDbg ставится из Microsoft Store (приложение WinDbg) или из Windows SDK в составе Debugging Tools for Windows. Обе версии открывают .mdmp одинаково.

Пошаговый разбор дампа 1С в WinDbg

Работайте с копией файла, а не с оригиналом в каталоге dumps.

Шаг 1. Откройте дамп

Запустите WinDbg, выберите открытие файла дампа (File → Open dump file в новой версии) и укажите .mdmp. Дождитесь, пока в командной строке отладчика появится приглашение для ввода.

Шаг 2. Подключите символы Microsoft

.symfix
.reload

.symfix задаёт сервер символов Microsoft, .reload перечитывает модули. Без этого стеки системных библиотек будут нечитаемыми.

Шаг 3. Запустите автоматический анализ

!analyze -v

Команда выводит код исключения, модуль-виновник и стек упавшего потока. Смотрите на строки:

• EXCEPTION_CODE — что произошло. c0000005 — нарушение доступа, c00000fd — переполнение стека, e06d7363 — необработанное исключение C++.
• MODULE_NAME и IMAGE_NAME — в каком модуле.
• STACK_TEXT — цепочка вызовов. Читается снизу вверх: внизу начало, вверху точка падения.

Шаг 4. Посмотрите стек и модули вручную

kb
lmv m имя_модуля
~*k

kb показывает стек текущего потока, lmv m — подробности о модуле: путь к файлу, версию, производителя. ~*k выводит стеки всех потоков — полезно, если сбой случился не в том потоке, на который указал анализ.

Шаг 5. Сделайте вывод

Посмотрите, какие модули стоят в верхних строках стека:

Как включить сбор дампов в 1С через logcfg.xml

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

C:\Program Files\1cv8\conf\logcfg.xml

Настройка в общем каталоге conf действует на все установленные версии платформы на этом компьютере. Если файла нет — создайте его. Минимальное содержимое только для дампов:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <dump create="true" location="D:\1C_dumps" type="3" prntscrn="false"/>
</config>

Что означают атрибуты:

• create="true" — включает создание дампов.
• location — каталог, куда их писать. Создайте его заранее и дайте права на запись пользователю, от имени которого работает служба сервера 1С.
• type — объём сохраняемых данных. 0 — минимальный дамп, 3 — расширенный с содержимым памяти; чаще всего поддержка просит именно его.
• prntscrn — сохранять ли снимок экрана. Для сервера смысла нет, держите false.

Платформа перечитывает logcfg.xml сама, примерно раз в минуту, перезапускать службу не нужно. Если файл уже существует и в нём настроен технологический журнал, добавьте элемент <dump> внутрь существующего <config>, ничего не удаляя.

На Linux дампы рабочих процессов создаются как системные core-файлы. Их размер ограничивается настройкой ulimit -c для пользователя службы, а место записи — системным параметром ядра kernel.core_pattern. Анализируют их отладчиком gdb.

Дамп зависшего процесса

Если 1С не падает, а «висит», дамп сам не появится. Снимите его вручную в момент зависания:

procdump -ma <PID процесса>

Ключ -ma сохраняет полную память. PID берите в Диспетчере задач на вкладке «Подробности». Для клиента можно проще: правая кнопка по процессу 1cv8c.exe → «Создать файл дампа». Два-три снимка с интервалом в 30–60 секунд покажут, в каком месте процесс стоит.

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

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

• 🔁 сбой повторяется на одном и том же действии, а сторонних модулей в стеке нет;
• 🆕 падения начались сразу после перехода на новую сборку платформы и пропадают на старой;
• 🧠 rphost падает при выполнении конкретного запроса или регламентного задания, а память сервера не исчерпана;
• 🧩 падение в собственной внешней компоненте — тогда адресат её разработчик, а не 1С.

Что приложить к обращению, чтобы его не вернули с вопросами:

1. Сам дамп (минимальный для первого знакомства, полный — если попросят).
2. Точный номер версии платформы и разрядность: 32 или 64 бита.
3. Название и релиз конфигурации.
4. Версию ОС и тип базы: файловая или клиент-серверная, СУБД.
5. Порядок действий, после которого происходит сбой, и как часто он повторяется.
6. Фрагмент технологического журнала за минуты до падения, если он ведётся.

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