Утром погрузчик решил, что смена обойдётся без него
Восемь утра. Кладовщик нажимает кнопку запуска, погрузчик дёргается, кашляет и глохнет, хотя первая машина уже ждёт у ворот. Механик ещё не дошёл до цеха, зато водитель успел вынести вердикт: «Аккумулятор. У меня вчера так же было».
На приборной панели лежит запись бортового самописца. Она сохранила обороты, температуру и последние команды перед остановкой. Самописец полезен, но причину сам по себе не называет. Одинаковая остановка возможна из-за питания, двигателя, датчика, управления или ошибки самого водителя.
С 1С происходит похожая история. Программа начинает запуск, процесс завершается аварийно, система сохраняет дамп. Файл .dmp содержит сведения о состоянии завершившегося процесса. Специалист использует его вместе с журналами, точным временем сбоя, версией платформы и условиями запуска.
Сам факт появления дампа подтверждает аварийное завершение. Он не доказывает повреждение базы, конфликт видеодрайвера или поломку платформы. Эти причины остаются версиями до проверки.
Дамп подтверждает аварийное завершение и сохраняет улику. Причину называют после сверки с журналами и средой запуска.
Как должен проходить обычный запуск
Вернёмся на склад. Перед началом смены водитель занимает своё место, техника получает питание, система управления проходит самопроверку, двигатель запускается, а диспетчер выдаёт рабочее задание. Сбой на любом шаге выглядит одинаково для очереди у ворот: погрузчик не приехал.
У запуска 1С тоже есть последовательность. Операционная система запускает приложение. Платформа загружает свои компоненты. Клиент получает параметры информационной базы и пытается к ней обратиться. После этого загружается конфигурация и открывается рабочее окно. Конкретная последовательность зависит от варианта работы, версии и настроек.
Поэтому фраза «1С падает при запуске» описывает место наблюдения, но оставляет открытым место причины.
Две синхронные дорожки
| № | Склад и погрузчик | 1С и компьютер | Какой след остаётся |
|---|---|---|---|
| 1 | Водитель поворачивает ключ | Пользователь запускает 1С | время запуска, имя приложения, действия пользователя |
| 2 | Бортовая система начинает самопроверку | Операционная система создаёт процесс | события операционной системы, сведения о процессе |
| 3 | Погрузчик готовит двигатель и управление | Платформа загружает компоненты | версия и разрядность платформы, журнал ошибок |
| 4 | Диспетчер передаёт адрес рабочей зоны | Клиент получает параметры информационной базы | список баз, строка подключения, режим работы |
| 5 | Погрузчик едет к нужному складу | Клиент обращается к файловой базе или серверу | технологический журнал, сетевые и серверные события |
| 6 | Машина выходит на рабочий маршрут | Загружается конфигурация и начинается сеанс | окно приложения либо точка аварийного завершения |
| 7 | Самописец сохраняет последние показатели после аварии | Формируется дамп завершившегося процесса | файл .dmp, время, имя процесса, сопутствующие журналы |
Схема процесса
ПОГРУЗЧИК: ключ → самопроверка → двигатель → задание → маршрут → работа
└──────── авария ────────→ запись самописца
1С: запуск → процесс → платформа → адрес базы → соединение → сеанс
└──────── авария ────────→ dump и журналы
Красная точка на будущей схеме должна двигаться. Её положение устанавливают по следам конкретного запуска. Из одного сообщения на экране точное положение часто не видно.
Почему дамп считается уликой
Официальная документация 1С описывает технологический журнал как средство анализа технологических проблем и аварийных завершений. По умолчанию платформа может сохранять минимальные дампы при аварийном завершении. Полный дамп способен содержать память процесса.
Это даёт два практических вывода.
Первый: файл нужно сохранить вместе со временем и контекстом. После обновления, переустановки или серии новых запусков исходная картина изменится.
Второй: дамп передают как технический материал ограниченному кругу специалистов. Память процесса может содержать рабочую информацию. Такой файл не размещают в открытом доступе и не отправляют на случайный форум.
Что видит бизнес
Для бизнеса авария выглядит проще технической картины:
- сотрудник не может начать работу;
- очередь документов и клиентов растёт;
- соседний компьютер может продолжать работать либо повторять тот же сбой;
- руководитель не знает, затронута одна рабочая станция, одна база или весь контур;
- каждая хаотичная попытка ремонта меняет исходные условия.
Самая полезная управленческая развилка звучит так: «У кого ещё и с какой базой происходит то же самое?» Ответ резко сужает участок поиска.
Что проверяет специалист
Специалист начинает с границ сбоя.
- На одном компьютере падают все базы или только одна?
- Та же база открывается с другого рабочего места?
- Сбой возникает под одним пользователем Windows или под разными?
- Падает тонкий клиент, толстый клиент или оба варианта?
- Какая версия и разрядность платформы запускается фактически?
- Что изменилось перед первым случаем: платформа, драйвер, защита, расширение, операционная система, оборудование?
- Какое приложение и какой модуль видны в дампе и сопутствующих журналах?
Каждый ответ меняет следующую проверку. Если все базы падают только на одном компьютере, внимание смещается к рабочей станции и клиентской установке. Если одна база падает у всех, специалист проверяет её контур и момент подключения. Если аварийно завершается серверный процесс, клиентская переустановка может не затронуть причину.
Дерево решений
1С аварийно завершилась и создала dump
│
├─ Это произошло только один раз?
│ ├─ Да → сохранить улику и наблюдать; причина пока неизвестна
│ └─ Нет → зафиксировать повторяемый сценарий
│
├─ Сбой только на одном компьютере?
│ ├─ Да → проверить, падают ли там другие базы и другой клиент
│ └─ Нет → проверить общую базу, серверную часть и общее изменение
│
├─ Другие базы на этом компьютере запускаются?
│ ├─ Да → сравнить параметры проблемной базы и момент подключения
│ └─ Нет → исследовать клиентскую платформу, профиль, ОС и компоненты
│
└─ Собраны dump, точное время, версия и журналы?
├─ Да → анализировать конкретное аварийное завершение
└─ Нет → сначала сохранить доказательства, затем менять среду
Дерево не выдаёт готовую причину. Оно отделяет локальную аварию от общей и сохраняет материал для технического разбора.
Что можно собрать безопасно
- фотографию или скриншот сообщения целиком;
- точное местное время сбоя;
- имя базы из списка запуска и ожидаемый режим работы;
- сведения «О программе», если их удаётся открыть в другом сеансе;
- версию и разрядность фактически запускаемого клиента;
- ответ на вопрос, открываются ли другие базы на этом компьютере;
- ответ на вопрос, открывается ли эта база с другого компьютера;
- файл дампа и относящиеся к этому времени журналы;
- список изменений перед первым случаем со слов ответственного сотрудника.
Файлы складывают в отдельный каталог только для чтения. К пакету добавляют короткую записку: кто запускал, что нажал, что увидел и когда.
Запрещённые действия до сохранения улик
- переустанавливать платформу «поверх» как первый шаг;
- удалять дампы и журналы ради освобождения места;
- очищать пользовательские каталоги и кэш без копии и зафиксированной гипотезы;
- обновлять драйверы, платформу и операционную систему одновременно;
- много раз запускать приложение в надежде, что оно «продавится»;
- публиковать дамп в открытом доступе;
- объявлять повреждённой информационную базу только по факту создания
.dmp; - возвращать всех сотрудников к работе после единственного успешного запуска, если причина и масштаб сбоя остаются неизвестными.
Изменение среды может оказаться частью диагностики. Его проводят после фиксации исходного состояния, по одному изменению за раз и с понятным способом возврата.
Как выглядит проверяемый результат
Хорошая диагностика заканчивается пакетом, который можно проверить:
- указан процесс, завершившийся аварийно;
- установлен масштаб: одно рабочее место, одна база или общий контур;
- сохранены дамп, журналы и точное время;
- воспроизведён один конкретный сценарий либо честно зафиксировано, что повтор пока не получен;
- версия причины подтверждена сравнением или управляемым изменением;
- после исправления тот же сценарий проходит несколько раз без аварии;
- есть план возврата и перечень изменений.
Фраза «переустановили, вроде запускается» такого результата не даёт. Она не объясняет причину и не помогает при повторении.
Следующий шаг
Сохраните один дамп, точное время аварии и ответы на два вопроса: открывается ли эта база с другого компьютера и открываются ли другие базы на проблемном компьютере. Этого достаточно, чтобы начать диагностику с фактов.
Источники и границы
- Технологический журнал 1С — назначение журнала и формирование дампов при аварийном завершении.
- Руководство пользователя 1С:Предприятия 8 — диалог аварийного завершения, запись дампа и сведения журнала ошибок.
Причина конкретного аварийного завершения без дампа, журналов и сведений о среде остаётся неизвестной.
Восстановим маршрут, найдём последнюю подтверждённую точку и определим безопасный следующий шаг.
Обсудить ситуацию