Добрый день!
До недавнего времени использовал платформу 8.3.12.1714, Сервер 1С х32 (Windows 2008R2), СУБД PostgreSQL 9.6(CentOS).
Для нормальной работы х32 использовал настройки из КОРП версии, а именно: Количество ИБ на процесс (1), ограничение памяти на процесс (4гб), безопасный расход памяти, остановка выключенных процессов. И все работало быстро, хорошо.
После сентябрьских изменений, когда настройка КОРП стала под запретом, апгрейдил сервер х32 на х64, т.к. х32 вообще не работал без настройки постоянно вылетал по нехватке памяти.
С апгрейдом сервера, обновил и версию платформы до 8.3.14.1944 и тут начались проблемы, просто дикие зависания, на 10-15 сек, с возможным в последствии отвисанием либо вылетанием клиента с appcrash, работать стало очень плохо.
Попытался исправить, снес СУБД, поставил новый PostgreSQL 11.5, CentOS 7. Обновил платформу до 8.3.15.1747
Теперь зависать перестало, но очень часто, рандомно вылетают клиенты с appcrash, работать стало вообще невозможно
Одновременно работает около 25 человек, могут открывать от 3 до 7 конфигураций в сеансе (ЗУП, БП, Управление аптечной сетью, на две организации), плюс постоянные обмены УТ-БП-ЗУП, загрузка/выгрузка xml.
Все вышеперечисленные проблемы появляются только под нагрузкой, когда работают все
Вопросы:
1) стало ли причиной сбоя, невозможность применить настройки сервера 1С от КОРП версии?
2) В чем еще может быть причина такого поведения системы?
Ощибки из журнала Windows:
Имя сбойного приложения: 1cv8c.exe, версия: 8.3.15.1747, отметка времени: 0x5db22593
Имя сбойного модуля: ntdll.dll, версия: 6.1.7601.24354, отметка времени 0x5c3562bf
Код исключения: 0xc0000005
Смещение ошибки: 0x00034723
Идентификатор сбойного процесса: 0x5c50
Время запуска сбойного приложения: 0x01d5986338df08b7
Путь сбойного приложения: C:\Program Files (x86)\1cv8\8.3.15.1747\bin\1cv8c.exe
Путь сбойного модуля: C:\Windows\SysWOW64\ntdll.dll
Код отчета: 8ae08771-0456-11ea-99f2-00155d580500
— Provider
Application Error
— EventID 1000
0
Level 2
Task 100
Keywords 0x80000000000000
— TimeCreated
2019-11-11T07:40:34.000000000Z
EventRecordID 286602
Channel Application

Добрый день! Уважаемые читайте и гости популярного IT блога Pyatilistnik.org. В прошлый раз мы с вами изучили вопрос, где в вашей системе располагаются ваши сертификаты пользователя и компьютера. Двигаемся далее и на повестке для у меня возникла проблема, которую я буду решать и вести в данной статье лог действий помогающих достижению цели. Сегодня я разберу ошибку при работе программы 1С предприятие, а именно она вылетает с событием «Программа 1cv8c.exe версии 8.3.14.1630 прекратила взаимодействие с Windows и была закрыта.» или «Имя сбойного приложения: 1cv8c.exe, версия: 8.3.14.1630, метка времени: 0x5c6e4c97». Надеюсь, что вместе с вами мы решим данную проблему.

Описание проблемы

Есть RDS ферма в режиме HA, построенная на базе серверов Windows Server 2012 R2. В совершенно разное время появляются жалобы, что пользователь не может корректно выйти из системы(/na-terminalnom-servere-visit-vyhod-iz-sistemy/), ряд мер я описывал по данному вопросу, но они к сожалению срабатывают не всегда. В такой ситуации пока алгоритм был такой, пользователям отправлялось уведомление на терминальный стол, после чего шла перезагрузка. Просматривая логи событий, во всех случаях присутствовали одни и те же ошибки, и все они указывали на какой-то косяк со стороны 1С 8.3.14.1630. Вот вам примеры текущих ошибок:

События с кодом ID 1000 журнал Application Error: Имя сбойного приложения: 1cv8c.exe, версия: 8.3.14.1630, метка времени: 0x5c6e4c97
Имя сбойного модуля: wbase83.dll, версия: 8.3.14.1630, метка времени: 0x5c6e4bb7
Код исключения: 0xc0000005
Смещение ошибки: 0x00006895
Идентификатор сбойного процесса: 0x266c
Время запуска сбойного приложения: 0x01d547768b10a80e
Путь сбойного приложения: C:\Program Files (x86)\1cv8\8.3.14.1630\bin\1cv8c.exe
Путь сбойного модуля: C:\Program Files (x86)\1cv8\8.3.14.1630\bin\wbase83.dll
Идентификатор отчета: 3c6e27af-b37a-11e9-815f-0050568dcf1e
Полное имя сбойного пакета:
Код приложения, связанного со сбойным пакетом:

События с кодом ID 1000 журнал Application Error: Имя сбойного приложения: EXCEL.EXE, версия: 16.0.4873.1000, метка времени: 0x5cffdabb
Имя сбойного модуля: EXCEL.EXE, версия: 16.0.4873.1000, метка времени: 0x5cffdabb
Код исключения: 0xc0000005
Смещение ошибки: 0x0002b78b
Идентификатор сбойного процесса: 0x2d80
Время запуска сбойного приложения: 0x01d546ec7c1c1a1f
Путь сбойного приложения: C:\Program Files (x86)\Microsoft Office\Office16\EXCEL.EXE
Путь сбойного модуля: C:\Program Files (x86)\Microsoft Office\Office16\EXCEL.EXE
Идентификатор отчета: bc1811e7-b2df-11e9-815f-0050568dcf1e
Полное имя сбойного пакета:

События с кодом ID 1000 журнал Application Error: Имя сбойного приложения: 1cv8.exe, версия: 8.3.14.1630, метка времени: 0x5c6e4d23
Имя сбойного модуля: rtrsrvc.dll, версия: 8.3.14.1630, метка времени: 0x5c6e4d21
Код исключения: 0xc0000005
Смещение ошибки: 0x00031042
Идентификатор сбойного процесса: 0xb37c
Время запуска сбойного приложения: 0x01d5388ac2b67852
Путь сбойного приложения: C:\Program Files (x86)\1cv8\8.3.14.1630\bin\1cv8.exe
Путь сбойного модуля: C:\Program Files (x86)\1cv8\8.3.14.1630\bin\rtrsrvc.dll
Идентификатор отчета: 87f52a22-a4da-11e9-815c-0050568dcf1e
Полное имя сбойного пакета:
Код приложения, связанного со сбойным пакетом:

События с кодом ID 1000 журнал Application Error: Имя сбойного приложения: mstsc.exe, версия: 6.3.9600.18980, метка времени: 0x5ab67164
Имя сбойного модуля: ntdll.dll, версия: 6.3.9600.19304, метка времени: 0x5c7f684f
Код исключения: 0xc0000374
Смещение ошибки: 0x00000000000f1cd0
Идентификатор сбойного процесса: 0x49f0
Время запуска сбойного приложения: 0x01d5387f8ab96e71
Путь сбойного приложения: C:\Windows\system32\mstsc.exe
Путь сбойного модуля: C:\Windows\SYSTEM32\ntdll.dll
Идентификатор отчета: d802c5d7-a472-11e9-815c-0050568dcf1e

События с кодом ID 1002 журнал Application Error: Программа 1cv8c.exe версии 8.3.14.1630 прекратила взаимодействие с Windows и была закрыта. Чтобы узнать, имеются ли дополнительные сведения о проблеме, проверьте историю проблемы в Центре поддержки в панели управления.
ИД процесса: 6394
Время запуска: 01d5476cf0acb640
Время завершения: 1
Путь приложения: C:\Program Files (x86)\1cv8\8.3.14.1630\bin\1cv8c.exe
ИД отчета: bbd779d9-b360-11e9-80e8-0050568dbadb

Видно, что из-за этой ошибки 1С так же повис проводник Windows:

События с кодом ID 1002 журнал Application Error: Программа Explorer.EXE версии 6.3.9600.18231 прекратила взаимодействие с Windows и была закрыта. Чтобы узнать, имеются ли дополнительные сведения о проблеме, проверьте историю проблемы в Центре поддержки в панели управления.

ИД процесса: b450
Время запуска: 01d54769b60320f4
Время завершения: 60000
Путь приложения: C:\Windows\Explorer.EXE
ИД отчета: 1b4bb96b-b360-11e9-80e8-0050568dbadb
Полное имя сбойного пакета:
Код приложения, связанного со сбойным пакетом:

Алгоритм поиска проблемы

Сразу скажу, что внятного ответа ни разработчики 1С ни техническая поддержка мне дали, все сказали, что у вас проблема с системой. И так, что я делал при поиске проблемы:

1. Вводил абсолютно свежий сервер с установленным Windows Server 2012 R2, эффекта не дало, ошибка все так же появилась
2. Удалил все неиспользуемые версии 1С, остались на текущий момент
3. Пробовал удалять кэш 1С, эффекта не дало
4. Переустановка самого клиента 1С, эффекта нет

Далее я решил попробовать собрать трассировку работы приложения по определенным провайдерам Winows и 1С, я такое делал уже при проблеме временного профиля на терминальных серверах. Для этих целей я использовал утилиту logman.exe.

Утилита Logman.exe

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

ссылка на описание утилиты Logman.exe на Microsoft https://docs.microsoft.com/ru-ru/windows-server/administration/windows-commands/logman

Когда вы захватываете через утилиту Logman.exe трассировку событий, то создается очень объемный лог, и если вы его не ограничите, то он забьет ваш диск за час. Для того, чтобы его слегка минимизировать мы может явным образом указать какие именно провайдеры Windows вы должны захватывать, как их определить я покажу чуть ниже. Откройте командную строку, лучше в режиме администратора, чтобы всякие UAC вам не мешали. Далее посмотрим всех доступных поставщиков, если не будет влезать на экран, то можете воспользоваться ключом | more или запустить все в PowerShell.

logman query providers

Как видим их приличное количество, но нам бы хотелось анализировать только те, что относятся к 1С. Чтобы отфильтровать, поставщиков Windows, вы можете использовать PID процесса. В диспетчере задач найдите нужный вас процесс, предположим в моем примере это ID 42424

В командной строке пишем:

logman query providers -pid 42424

На выходе вы получите уже меньшее количество поставщиков Windows, у меня это получилось вот так для 1С 8.3.14.1630. Тут нас будут интересовать исключительно GUID.

Вам необходимо в текстовый файл сохранить именно GUID значения, по одному значению в строке. Далее этот файл нам будет нужен, при мониторинге. Создайте у себя для удобства отдельную папку. в которую сохраните файл со списком GUID. у меня это будет путь C:\tmp\provaders8.txt. Далее вам нужно определиться сколько вы готовы отдать под файл лога, учтите что он заполняется молниеносно, и сохраняется в сжатом виде в формате .etl, но если вы его потом распакуете, то например 50 МБ превратятся в 750, это нужно учитывать, но есть и обратная сторона нужно больше данных для диагностики, поэтом маленьким его делать так же нет смысла. Я в своем поиске сделаю его 3 ГБ.

В командной строке создаем новую трассировку в Logman.exe:

logman create trace -n 1C8 -f bincirc -max 3000 -ow -o C:\tmp\1C8.etl -ets

• -n задает имя вашей трассировки приложения
• -max — задает максимальный размер файла
• -ow — перезаписать текущий файл если он существует
• -o — путь до файла .etl
• -ets — Отправить команды сеансам трассировки событий напрямую, без сохранения или планирования.
• f bincirc — включить цикл перезаписывания файла новыми данными

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

logman update 1C8 -pf C:\tmp\provaders8.txt -ets

• -pf — указать путь до файла с GUID

В итоге у вас начинается наполнение файла .etl

Посмотреть статус и список работающих провайдеров вы можете командой:

logman query -ets

Я вижу, что мой сеанс отслеживания событий под именем 1С8 работает. Кстати если вы откроете оснастку «Управление компьютером» и перейдете в раздел «Производительность — Группы сборщиков данных — Сеансы отслеживания событий», то вы увидите тот же список заданий. Тут проще будет потом вносить изменения, например по ключевым словам или уровнем событий, так как по умолчанию у меня стоит уровень 0, подразумевающий собирать все.

Теперь ждем сбоя, после которого вам нужно остановить ваше задание, можно из графического интерфейса

или же командой:

logman stop -n 1C8 -ets

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

Tracerpt C:\tmp\1C8.etl

Напоминаю, что у вам потребуется много места. Все начинается распаковка лога, вы будите видеть таскбар. В итоге из своих 3 ШБ, я получил файл дамп (dumpfile.xml) приложения 1С Предприятие в размере 41 ГБ и текстовый файл summary.txt

Получив такой огромный лог, я не смог его прочитать, утилита Microsoft Message Analyzer писала, что недостаточно памяти для продолжения выполнения программы. Пришлось уменьшать размер epl файла до 100 МБ и собирать меньшее количество провайдеров, исключив некоторые Microsoft и фиксировать только ошибки, уровня 2.

• Critical — 1 0x1 Этот уровень соответствует критической ошибке, которая является серьезной ошибкой, вызвавшей серьезный сбой.
• Error — 2 0x2 Этот уровень добавляет стандартные ошибки, которые указывают на проблему.
• Informational — 4 0x4 Этот уровень добавляет информационные события или сообщения, которые не являются ошибками. Эти события могут помочь отследить прогресс или состояние приложения.
• LogAlways — 0 0xffffffff Фильтрация уровней по событию не выполняется
• Verbose — 5 0x5 Этот уровень добавляет длинные события или сообщения. Это вызывает все события, которые будут зарегистрированы.
• Warning — 3 0x3 Этот уровень добавляет предупреждающие события (например, события, которые публикуются, потому что диск почти заполнен).

Так же я параллельно создал ключи реестра, которые при сбое определенного приложения будут записывать его дамп.

В итоге я получил небольшого вида файлы, которые чуть больше смогли ответить, в чем проблема связанная с появлением ошибки с ID 1000.

Откройте DebugDiag Analysis, выберите пункты:

• crashHangAnalysis
• MemoryAnalysis
• KernelCrashHangAnalysys

После чего нажимаем кнопку «Add data Files».

После чего нажмите «Start Analysis»

На выходе вы получаете веб отчет, у меня выглядело вот так:

WARNING — DebugDiag was not able to locate debug symbols for \wbase83.dll, so the information below may be incomplete.

Далее хотя бы видно, к какой базе данных было подключение, для этого есть ключ /IBName.

Далее вы увидите более детальную отладочную информацию по Thread — System ID, она может быть полезна для разработчиков 1С.

Thread 6 — System ID 118516

This thread is not fully resolved and may or may not be a problem. Further analysis of these threads may be required.

Thread 0 — System ID 118120

Thread 3 — System ID 118148

На этом моя борьба с зависание терминального сервера из-за ошибки 1С предприятия закончена, я как администратор тут уже ничего не могу поделать, надеюсь на разработчиков. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.

При старте 1с почти сразу падает. Авторизация проходит, окно базы открывается, интерфейс на месте, окна с новостями отображаются, но сразу появляется сообщение о создании дампа памяти и видим табло: » Прекращена работа программы 1cv8c».
В логах ругань на ошибку внутри core83.dll. Платформа 8.3.10.2561 32 бита.
Имя сбойного приложения: 1cv8.exe, версия: 8.3.10.2561, отметка времени: 0x5983aaf4
Имя сбойного модуля: core83.dll, версия: 8.3.10.2561, отметка времени 0x5983a625
Код исключения: 0xc0000005
Смещение ошибки: 0x00009592
Идентификатор сбойного процесса: 0x740
Время запуска сбойного приложения: 0x01d3b155a8a3f0ec
Путь сбойного приложения: C:\Program Files (x86)\1cv8\8.3.10.2561\bin\1cv8.exe
Путь сбойного модуля: C:\Program Files (x86)\1cv8\8.3.10.2561\bin\core83.dll
На машине подключено две базы: файловая и SQL. Падает только SQL. На остальных машинах с той же версией платформы и той же базой все работает. Что за четыре часа траханья с проблемой проверил и это не помогло:

• чистка кэша 1с. наконец то узнал что это такое. лучшеб и не узнавал
• переподключение базы с новым именем
• переустановка платформы на сбойной машине. платформу на сервере предприятия по понятным причинам не трогал
• почитал логи SQL сервера и сервера предприятия. порезал логи sql-базы
• залогинился на эту же машину под другим пользователем. там ошибки не проявилась. на всякий случай очистил все папки с временными файлами у «сбойного» пользователя.
• перерыл кучу форумов где люди жалуются на такие же падения. но там было всё про древнюю версию и платформы и бухгалтерии. и еще народ жаловался на такие же падения, но там ошибка «вылазила» внутри MSVCR110.dll. не мой случай.
• на соседней машине попал в базу и поотключал всю рекламу и обновления при старте базы. Это там где Администрирование-Проверка и обслуживание
• допросил аутсорсного 1с-ника про недавние обновления базы и платформы — уже месяц ничего не трогали.

В итоге на одном из форумов нашел сообщение, что «падение» платформы 8.3 иногда вызваны включенным на «полную» ускорением графики в драйверах видеокарты. Раньше это настраивалось в свойствах экарана: Свойства-Дополнительно-Диагностика где обычно был слайдер Аппаратное ускорение. На сбойной машине бортовая видеокарта Intel HD 4600 и монтор разрешением 1920х1080. В Intel-драйверах движка про Аппаратное ускорение просто нет. Поставил с сайта интела самые свежие драйвера. НЕТ. Не помогло.
Подумал, как еще можно снизить нагрузку на видеокарту? Снизил разрешение. И тут, о чудо! при разрешении 1280×720 1с начал стартовать.
Если базе дать запустится на низком разершении, а потом уже переключится в штатное для монитора 1920×1080, то база продолжает работать.
Где видео-карта и где 1с:Предприятие, казалось бы…