Периодический дамп платформы 1С:Предприятие 8.3 на Windows редко связан с «битой» конфигурацией. Чаще в журнале событий Windows, раздел «Приложение», рядом с 1cv8.exe или конфигуратором фигурирует сбойный модуль Visual C++. Администратору или разработчику не стоит крутить очистку кэша по кругу: нужно сопоставить имя DLL, путь загрузки и версию Microsoft Visual C++ Redistributable с каталогом установленной платформы.
Симптомы: когда помогает кэш, а сбой возвращается
Картина повторяется на разных конфигурациях. Клиент или конфигуратор закрывается без понятного сообщения платформы, иногда с записью об ошибке приложения в ОС. Чаще всего падает конфигуратор при работе с хранилищем: помещение изменений, сравнение, обновление из хранилища. Перезапуск процесса частоту сбоев не меняет.
Очистка кэша клиента и каталогов seance пользователя ненадолго возвращает работоспособность. Через несколько сеансов или после тяжёлой операции в конфигураторе вылет повторяется. От единичного сбоя расширения или прикладного кода это отличается тем, что падает исполняемый файл платформы, а не диалог «Ошибка выполнения» с модулем конфигурации.
Запишите, какой процесс завершился. Толстый клиент - обычно 1cv8.exe, конфигуратор - тот же exe с параметрами конфигуратора или ярлык «1C:Enterprise - Конфигуратор». Тонкий клиент - 1cv8c.exe. Разрядность процесса, 32 или 64 бита, позже подскажет, из System32 или SysWOW64 брать системную копию runtime при ручном согласовании DLL.
Сбой при commit в хранилище не доказывает поломку сервера хранилища. Воспроизведение на копии базы без хранилища и на другой машине с той же версией платформы отсекает версию «хранилище ломает конфигуратор». Если конфигуратор падает без хранилища или на пустой базе той же разрядности, смотрят среду Windows и бинарники платформы.
Переустановка платформы, смена совместимости, отключение надстроек - типовые шаги без разбора дампа и журнала ОС уже описаны открыто. Здесь другой маршрут: от модуля сбоя в Event Viewer к пакету Visual C++ и каталогу bin установленной 8.3.
Журнал «Приложение»: как найти сбойный модуль 1С
После очередного вылета откройте «Просмотр событий» (eventvwr.msc). Дальше «Журналы Windows», затем «Приложение». В меню журнала - «Фильтровать текущий журнал», уровень «Ошибка». В русской локали источник часто «Ошибка приложения», в английской - Application Error.
Контекст: Журнал «Приложение»: как найти сбойный модуль 1С
Ищите запись, где сбойное приложение - 1cv8.exe, 1cv8c.exe или путь ведёт в каталог программы 1С. Время события сверьте с моментом падения. Если записей много, добавьте фильтр по словам в описании: 1cv8, версия вроде 8.3.12 или актуального релиза 8.3.24.
Для одной аварии нужны поля тела события, не только заголовок. Обычно там есть:
- имя сбойного приложения, полный путь к exe платформы;
- имя сбойного модуля, DLL;
- полный путь к модулю на диске;
- код исключения, часто 0xc0000005 при нарушении доступа.
Путь к DLL - отправная точка. Файл внутри каталога версии платформы, например …\1cv8\8.3.xx.xxxx\bin\, значит платформа подтянула локальную копию runtime, а не только системную. Путь в System32, SysWOW64 или WinSxS ведёт к установленным пакетам redistributable и целостности системных библиотек; согласование версий при этом то же.
Ниже - сжатый чеклист полей записи «Ошибка приложения», по которым решают вопрос про Visual C++.
Поля события «Ошибка приложения» для решения о Visual C++
Если все пять полей совпадают с падением конфигуратора и именами MSVCP или VCRUNTIME, разбор конфигурации откладывают до согласования runtime.
Запись с пустым путём модуля встречается реже. Тогда смотрят соседние события с тем же временем и PID. Для этого класса сбоев в «Приложении» обычно хватает имени vcruntime, msvcp или vcruntime140 без WinDbg.
Visual C++ Redistributable: почему виноват runtime, а не конфигурация
Имена VCRUNTIME140.dll, MSVCP140.dll, CONCRT140.dll относятся к линейке Microsoft Visual C++ 2015–2022 Redistributable. Платформа 8.3 собрана с MSVC; в документации к дистрибутиву для текущих релизов 1С указана установка актуального redistributable для x86 и x64. Это один установщик на несколько лет выпуска Studio, а не отдельный пакет «только 2015» для старых сборок вроде 8.3.12.
Контекст: Visual C++ Redistributable: почему виноват runtime, а не конфигурация
Ошибка в журнале с такой DLL не говорит о повреждении метаданных и не заставляет сначала «лечить» хранилище. Конфигурация может быть не тронута, а падение всплывает на действии, которое нагружает UI или нативный код платформы: модальные окна, длинная операция, работа с файлами в каталоге платформы.
Типичные причины «не той» DLL в пути:
- в bin лежит устаревшая или частично перезаписанная копия после ручного копирования или оборванного обновления;
- на машине стоит только x64 redistributable, а конфигуратор 32-битный, или наоборот;
- несколько версий 8.3 в одном корне: ярлык смотрит в одну bin, в журнале путь к другой;
- неофициальный «сборник» runtime не совпадает по сборке с тем, что ждут бинарники 1cv8.
Windows ищет DLL по правилам загрузки: каталог exe, системные каталоги, PATH. Копии рядом с 1cv8.exe перебивают System32. Установка redistributable в систему нужна всегда. Если журнал показывает сбой в bin платформы, дополнительно выравнивают файл там с версией, которую ставит Microsoft.
Обновление redistributable и согласование DLL с каталогом платформы
Для актуальных 8.3 я начинаю с переустановки платформы нужной разрядности с официального дистрибутива 1С и установки Microsoft Visual C++ 2015–2022 Redistributable с сайта Microsoft для x86 и x64. На станции, где 32-битный конфигуратор соседствует с 64-битным сервером, оба пакета ставят до экспериментов с bin.
Контекст: Обновление redistributable и согласование DLL с каталогом платформы
Redistributable поставили - перезапустите конфигуратор и повторите сценарий, который раньше давал дамп. Если журнал снова указывает DLL в …\1cv8\…\bin\ и версия файла расходится с системной, допустима ручная замена только для этого каталога и только после фиксации исходного состояния.
Перед заменой архивируйте весь bin или минимум проблемные DLL с датой и номером версии платформы, 8.3.xx.xxxx из свойств 1cv8.exe. Запишите версию «до»: свойства файла, вкладка «Подробно», поля «Версия продукта» и «Имя продукта». Дистрибутив 1С при следующей установке может перезаписать bin; резерв нужен для отката.
Копируют не с чужого ПК, а из системного каталога той же разрядности, что упавший процесс. Для 64-битного 1cv8.exe - System32; для 32-битного процесса на 64-битной Windows - SysWOW64. Имя DLL - как в журнале. Замена в bin установленной версии платформы, от администратора, конфигуратор закрыт.
Ручная подмена не входит в официальные инструкции 1С как штатный метод. Это восстановление согласованности после диагностики, а не замена нормального обновления платформы. Без копирования из System32: уберите локальные vc* и msvcp* из bin, если их там не должно быть при чистой установке, переустановите платформу и redistributable одной разрядности и проверьте, исчез ли локальный путь из журнала.
Последовательность, когда имя DLL уже известно из «Приложения»:
Порядок: redistributable, проверка, замена в bin при локальном пути
Цепочку из блока выше проходят и снова делают операцию в конфигураторе. При удаче путь сбоя в новых событиях пропадает или указывает на системный каталог с актуальной версией продукта.
Тихая установка redistributable (/install /quiet /norestart) пригодна для массового администрирования. На рабочей станции разработчика хватает интерактивного установщика и перезапуска сеанса пользователя без перезагрузки сервера 1С.
Проверка результата и ошибки при повторении приёма
Успех - платформа стартует, конфигуратор выполняет ранее падающую операцию, в том числе помещение в хранилище. Новые «Ошибка приложения» с тем же модулем не копятся несколько рабочих дней подряд. Формулировку «навсегда на всех машинах» я не использую: апдейт Windows или платформы снова меняет состав bin.
Контекст: Проверка результата и ошибки при повторении приёма
Когда прилетает новый дистрибутив 1С, сверьте bin с резервной копией. Перезапись DLL там - повторите установку redistributable и при необходимости снова сравните версии файла в журнале и на диске.
Частые промахи:
- 32-битная DLL в 64-битный bin или наоборот - процесс не загрузит модуль или упадёт с другим кодом;
- замена одной из пары msvcp и vcruntime без второй, обе должны быть одной линейки сборки;
- пропуск х86-пакета при установленном только x64 redistributable;
- надежда, что очистка кэша заменит обновление runtime.
Метод не подходит, если в журнале другой модуль: ntdll.dll, kernelbase.dll, драйвер видеокарты, антивирусный вставной модуль. Тогда идут общей диагностикой дампа, не смешивая её со сценарием Visual C++ в bin платформы.
После замены снова откройте свойства DLL в bin и сравните с системной копией. Совпадение версии продукта Microsoft VC++ 2015–2022 Redistributable - норма; расхождение значит, что загрузчик может взять другой файл.
Один раз сохраните скрин или текст события «до» и «после» лечения. При регрессии после апдейта платформы сравнение займёт минуты и не смешает новую причину со старой.
Если картина другая: куда смотреть дальше без смены темы
Вместо Application Error видны только события.NET Runtime или Dr.Watson - расширьте поиск по 1cv8 в «Приложении» за больший интервал и загляните в «Система» на сбои служб и коды WER. LocalDumps для 1cv8.exe сохранит минидамп в заданный каталог, когда в текстовом журнале мало деталей.
Запуск с параметрами из ярлыка, /Out и /DisableStartupMessages, помогает отделить падение до входа в базу. Каталоги логов сеанса и технологического журнала на сервере приложений здесь вторичны: они для rphost и SQL, а не для локального падения конфигуратора с vcruntime в пути модуля.
Нет строки с DLL, но процесс пропадает - проверьте карантин антивируса и блокировку exe и dll в каталоге 1cv8. Тема статьи не меняется, отсекаются случаи без Visual C++ в записи.
Сбойный модуль снова MSVCP или VCRUNTIME, путь только System32, переустановка redistributable не помогла - проверьте целостность образа Windows (DISM и SFC), затем чистую переустановку платформы той разрядности, которую реально запускает ярлык конфигуратора.
«Приложение» пусто сразу после падения - расширьте фильтр до семи дней и снимите фильтр по источнику. Иногда событие приходит от Windows Error Reporting с тем же путём к 1cv8.exe, но другим текстом тела.
Команды для копирования
Команды для локальной диагностики на Windows. Путь к версии платформы возьмите из свойств ярлыка конфигуратора.
eventvwr.msc
powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Application'; Level=2; StartTime=(Get-Date).AddDays(-1)} | Where-Object { $_.Message -match '1cv8' } | Select-Object TimeCreated, Id, Message | Format-List"
powershell -NoProfile -Command "$p='C:\Program Files\1cv8\8.3.24.1700\bin\VCRUNTIME140.dll'; if (Test-Path $p) { (Get-Item $p).VersionInfo | Select-Object FileVersion, ProductVersion, FileName }"
powershell -NoProfile -Command "Get-Item 'C:\Windows\System32\vcruntime140.dll','C:\Windows\SysWOW64\vcruntime140.dll' -ErrorAction SilentlyContinue | ForEach-Object { $_.VersionInfo.FileName; $_.VersionInfo.ProductVersion }"
vc_redist.x64.exe /install /quiet /norestart
vc_redist.x86.exe /install /quiet /norestart
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
Номер каталога 8.3.xx.xxxx в примере свойств DLL подставьте из своей установки. Имена vc_redist*.exe - файлы установщика redistributable с сайта Microsoft.
Вступайте в нашу телеграмм-группу Инфостарт