Ошибка приложения 1cv8c exe

Обновлено 05.08.2019

Добрый день! Уважаемые читайте и гости популярного 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. Вот вам примеры текущих ошибок:

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

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

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

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

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

Утилита Logman.exe

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

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

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

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

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

Поставщик GUID
——————————————————————————-
Microsoft-IEFRAME {5C8BB950-959E-4309-8908-67961A1205D5}
Microsoft-Windows-AsynchronousCausality {19A4C69A-28EB-4D4B-8D94-5F19055A1B5C}
Microsoft-Windows-COM-Perf {B8D6861B-D20F-4EEC-BBAE-87E0DD80602B}
Microsoft-Windows-Crypto-BCrypt {C7E089AC-BA2A-11E0-9AF7-68384824019B}
Microsoft-Windows-Crypto-RSAEnh {152FDB2B-6E9D-4B60-B317-815D5F174C4A}
Microsoft-Windows-D3D9 {783ACA0A-790E-4D7F-8451-AA850511C6B9}
Microsoft-Windows-DNS-Client {1C95126E-7EEA-49A9-A3FE-A378B03DDB4D}
Microsoft-Windows-Documents {C89B991E-3B48-49B2-80D3-AC000DFC9749}
Microsoft-Windows-Dwm-Api {292A52C4-FA27-4461-B526-54A46430BD54}
Microsoft-Windows-KnownFolders {8939299F-2315-4C5C-9B91-ABB86AA0627D}
Microsoft-Windows-LDAP-Client {099614A5-5DD7-4788-8BC9-E29F43DB28FC}
Microsoft-Windows-Networking-Correlation {83ED54F0-4D48-4E45-B16E-726FFD1FA4AF}
Microsoft-Windows-PrintService {747EF6FD-E535-4D16-B510-42C90F6873A1}
Microsoft-Windows-RPC {6AD52B32-D609-4BE9-AE07-CE8DAE937E39}
Microsoft-Windows-RPC-Events {F4AED7C7-A898-4627-B053-44A7CAA12FCD}
Microsoft-Windows-Shell-Core {30336ED4-E327-447C-9DE0-51B652C86108}
Microsoft-Windows-SQM-Events {A97524F6-064C-4C4E-B74B-1ACC87C3700D}
Microsoft-Windows-TSF-msctf {4FBA1227-F606-4E5F-B9E8-FAB9AB5740F3}
Microsoft-Windows-UIAutomationCore {820A42D8-38C4-465D-B64E-D7D56EA1D612}
Microsoft-Windows-User Profiles General {DB00DFB6-29F9-4A9C-9B3B-1F4F9E7D9770}
Microsoft-Windows-UxTheme {422088E6-CD0C-4F99-BD0B-6985FA290BDF}
Microsoft-Windows-WinRT-Error {A86F8471-C31D-4FBC-A035-665D06047B03}
Microsoft-Windows-Winsock-NameResolution {55404E71-4DB9-4DEB-A5F5-8F86E46DDE56}
ODBC.1 {F34765F6-A1BE-4B9D-1400-B8A12921F704}
{012616AB-FF6D-4503-A6F0-EFFD0523ACE6} {012616AB-FF6D-4503-A6F0-EFFD0523ACE6}
{097D1686-4038-46BE-B551-10FDA0387165} {097D1686-4038-46BE-B551-10FDA0387165}
{2955E23C-4E0B-45CA-A181-6EE442CA1FC0} {2955E23C-4E0B-45CA-A181-6EE442CA1FC0}
{4E749B6A-667D-4C72-80EF-373EE3246B08} {4E749B6A-667D-4C72-80EF-373EE3246B08}
{4FE2C5BD-3BEA-465A-85D1-AD2719CFF4AF} {4FE2C5BD-3BEA-465A-85D1-AD2719CFF4AF}
{609151DD-04F5-4DA7-974C-FC6947EAA323} {609151DD-04F5-4DA7-974C-FC6947EAA323}
{63A3ADBE-9717-410D-A0F5-E07E68823B4D} {63A3ADBE-9717-410D-A0F5-E07E68823B4D}
{65CD4C8A-0848-4583-92A0-31C0FBAF00C0} {65CD4C8A-0848-4583-92A0-31C0FBAF00C0}
{6B6C257F-5643-43E8-8E5A-C66343DBC650} {6B6C257F-5643-43E8-8E5A-C66343DBC650}
{6E65C8FC-3CFE-412A-B793-D36D2185A831} {6E65C8FC-3CFE-412A-B793-D36D2185A831}
{80DF111F-178D-44FB-AFB4-5D179DE9D4EC} {80DF111F-178D-44FB-AFB4-5D179DE9D4EC}
{A2A3A1D0-AC4C-4A8F-BCD3-DB69FBA5AFFC} {A2A3A1D0-AC4C-4A8F-BCD3-DB69FBA5AFFC}
{A323CDC2-81B0-48B2-80C8-B749A221478A} {A323CDC2-81B0-48B2-80C8-B749A221478A}
{A3A7B70D-A430-4F3E-AC8B-32DC24E12D7E} {A3A7B70D-A430-4F3E-AC8B-32DC24E12D7E}
{A74EFE00-14BE-4EF9-9DA9-1484D5473302} {A74EFE00-14BE-4EF9-9DA9-1484D5473302}
{A74EFE00-14BE-4EF9-9DA9-1484D5473305} {A74EFE00-14BE-4EF9-9DA9-1484D5473305}
{BDA92AE8-9F11-4D49-BA1D-A4C2ABCA692E} {BDA92AE8-9F11-4D49-BA1D-A4C2ABCA692E}
{C9BF4A02-D547-4D11-8242-E03A18B5BE01} {C9BF4A02-D547-4D11-8242-E03A18B5BE01}
{CEC2553A-8961-4D34-92CA-AB2ECEF646C5} {CEC2553A-8961-4D34-92CA-AB2ECEF646C5}
{D1D7D72D-00D5-4E56-8BAC-23FAC0F9ED4E} {D1D7D72D-00D5-4E56-8BAC-23FAC0F9ED4E}
{E27950EB-1768-451F-96AC-CC4E14F6D3D0} {E27950EB-1768-451F-96AC-CC4E14F6D3D0}
{E870C196-B8CE-4C83-8C4E-DD5755C6D184} {E870C196-B8CE-4C83-8C4E-DD5755C6D184}
{EB7428F5-AB1F-4322-A4CC-1F1A9B2C5E98} {EB7428F5-AB1F-4322-A4CC-1F1A9B2C5E98}

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

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

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

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

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

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

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

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

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

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

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

Напоминаю, что у вам потребуется много места. Все начинается распаковка лога, вы будите видеть таскбар. В итоге из своих 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 (https://www.microsoft.com/en-us/download/details.aspx?id=58210).

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

• crashHangAnalysis
• MemoryAnalysis
• KernelCrashHangAnalysys

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

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

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

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

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

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

   paull2006

08.02.22 — 10:51

Помогите что за ерунда. Замучался уже. Server 2008 клиент подключаются в файловом режиме по сети к базе и при закрытии месяца вот такая ерунда. Аварийное завершение.  И это происходит после обновления платформы.

Полная ошибка

Имя сбойного приложения: 1cv8c.exe, версия: 8.3.17.1851, метка времени: 0x5fb429b6

Имя сбойного модуля: ucrtbase.DLL, версия: 10.0.17134.12, метка времени: 0xbb0923b6

Код исключения: 0xc0000409

Смещение ошибки: 0x000a273b

Идентификатор сбойного процесса: 0x2328

Время запуска сбойного приложения: 0x01d81cba6b454833

Путь сбойного приложения: C:Program Files (x86)1cv88.3.17.1851bin1cv8c.exe

Путь сбойного модуля: C:Program Files (x86)1cv88.3.17.1851binucrtbase.DLL

Идентификатор отчета: 41dc51b0-88b1-11ec-85ee-94de80e57bea

Полное имя сбойного пакета:

Код приложения, связанного со сбойным пакетом:

С++ обновляю до самого нового на сервере.

   1Сергей

1 — 08.02.22 — 10:55

   mistеr

2 — 08.02.22 — 10:57

(0) Платформа точно не ломаная?

   paull2006

3 — 08.02.22 — 11:18

Нет. Стоит ключ сетевой и на 10 пользователей

   1Сергей

4 — 08.02.22 — 11:31

64 битную платформу пробовали?

   paull2006

5 — 08.02.22 — 11:33

Там server 2008 86

   1Сергей

6 — 08.02.22 — 11:41

(5) жость.

А есть возможность прописать путь через айпи?

   hhhh

7 — 08.02.22 — 11:43

(5) тогда эта папка откуда?  Program Files (x86)   ?? Значит, кто-то врет?

   paull2006

8 — 08.02.22 — 12:03

На сервере стоит 86 на клиенте 64. То есть можно на клинте 64 поставить да.

   paull2006

9 — 08.02.22 — 12:03

Что значит ?

   paull2006

10 — 08.02.22 — 12:03

А есть возможность прописать путь через айпи?

   paull2006

11 — 08.02.22 — 12:05

На сервере 86 система на клиенте 64 разрядная. Везде стоит 1с 32 разрядная. То есть на клиенте можно установить 64 1с?

   1Сергей

12 — 08.02.22 — 12:16

(11) не работал с файловыми. Но, вроде смысла в 64 битах не много

   paull2006

13 — 08.02.22 — 12:19

Так вот и не понимаю из за чего падает

   1Сергей

14 — 08.02.22 — 12:19

(13) пробовали (6)?

   paull2006

15 — 08.02.22 — 12:29

1Сергей Что именно пробовал

   1Сергей

16 — 08.02.22 — 12:31

(15) путь к базе вместо \server2008BaseName прописать \192.168.1.1BaseName

   paull2006

17 — 08.02.22 — 12:35

ок

   mistеr

18 — 08.02.22 — 13:30

   Chai Nic

19 — 08.02.22 — 13:32

Не надо работать с файловой базой по сети

   paull2006

20 — 08.02.22 — 13:36

Chai Nic Ну тут такая ситуация и всего два человека сидит на данный момент

   paull2006

21 — 08.02.22 — 13:56

Путь 192.168.*.* не помогает

   paull2006

22 — 08.02.22 — 13:56

Опять вылетает

   Ёпрст

23 — 08.02.22 — 13:57

(0)

на вот, почитай на ночь. Кому-то 64х помогает, кто-то в свойствах сетевой карты флаги выставляет. Кто-то подорожник прикладывает.

Но чаще, забивают болт

https://forum.infostart.ru/forum9/topic223586/

   Ёпрст

24 — 08.02.22 — 13:58

вот это сделай оттуда:

>>>>> в свойствах сетевой карты параметр «Разгрузка при большой отправке (IPv4)» установлен в значение «Выключен»

   mistеr

25 — 08.02.22 — 14:03

   paull2006

26 — 08.02.22 — 14:18

На сервере или на клиенте?

в свойствах сетевой карты параметр «Разгрузка при большой отправке (IPv4)» установлен в значение «Выключен»

   paull2006

27 — 08.02.22 — 15:21

   Ёпрст

28 — 08.02.22 — 15:25

(25) ну, кому-то помагает..

ХЗ, не было файловой по-сети, не с чем сравнивать

   1Сергей

29 — 08.02.22 — 15:28

может имеет смысол перейти на вэб? Файловую вроде можно опубликовать в апаче

   paull2006

30 — 08.02.22 — 15:36

в апаче пробовал ошибки часто тоже появляются. И вся это канитель после новой платформы.

   Chai Nic

31 — 08.02.22 — 15:38

(29) +1. В файловой базе надо работать через веб-сервер. Напрямую с файлом работать в файловой базе можно только если база локальная однопользовательская.

   paull2006

32 — 08.02.22 — 20:25

   ДедМорроз

33 — 08.02.22 — 20:41

   ДедМорроз

34 — 08.02.22 — 20:43

Это я к чему,если поискать по имени этой dll,то ошибка-то таже самая,но пользователи там про 1с не знают.предлагается искать обновление Си 2017.

   paull2006

35 — 08.02.22 — 20:46

ДедМорроз так самые последние ставлю и на серваке и на клиентах

   ДедМорроз

36 — 08.02.22 — 21:02

Если ты внимательно почитаешь ссылку,то заметишь,что после обновления windows что-то сломалось — значит — нужно попробовать не самую последнюю библиотеку.

   ДедМорроз

37 — 08.02.22 — 21:13

Ну или ставить версию платформы,где другая версия библиотеки,в принципе.

   paull2006

38 — 08.02.22 — 21:13

   paull2006

39 — 08.02.22 — 21:14

От 2005 до 2022. Причем на всякий старые удалил и новые поставил

   paull2006

40 — 08.02.22 — 21:18

Может вообще все удалить и только 2017 поставить которая с платформой идет?

   ДедМорроз

41 — 09.02.22 — 00:37

На самом деле,все действия — это танцы с бубнами.

Сейчас я попытаюсь объяснить причину ошибки.

У нас есть dll, в данном случае ucrlbase,как и у любой dll все данные в ней разбиты на секции,которые грузятся в память по определенным адресам,называемым базовыми адресами,но базовый адрес в адресном пространстве процесса может быть занят,тогда делается загрузка по другому адресу и используется таблица переразмещения,которая правит ссылки.

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

Когда dll отлаживают,она грузится по базовому адресу (для этого сегмента)и все работает как часы.

Потом эту dll используют во многих программах,в том числе и в 1с,и все также работает как часы.

Но,в какой-то из программ,использующих целевую dll используется еще и dll «простая 1»,которая грузится совершенно по другому адресу и никак не мешает нашей.

Потом,встречается программа или служба,использующая также dll «простая»,но кроме нее еще и dll «совсем простая», которая по какому-то стечению обстоятельств перекрыла базовый адрес dll «простая».

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

Но,в целях экономии памяти,если dll зашружена по какому-то адресу в один процесс,то в другой она будет грузиться сначала не по базовому,а уже используемому адресу,так как в этом случае,память под код dll у обоих процесмов будет общей.

В итоге,по какой-то причине у процесса,запускающегося ранее нашего,используемая dll «простая» попадает в блок адресов нашей dll. Так как этот процесс о нашей dll не знает,а в dll простая ошибки перераспределения нет,то он работает без ошибок.

А вот теперь запускается наш процесс,который сначала грузит dll «простая» и занимает адрес нашей dll,так как в другом процессе она использует этот же адрес,а потом грузит нашу dll, вызывая переразмешение,которое приводит к битой ссылке внутри нашей dll,и процесс падает со странной ошибкой.

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

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

   mistеr

42 — 09.02.22 — 09:20

   paull2006

43 — 09.02.22 — 15:07

Это конечно все хорошо но для меня заумно 🙂

   mistеr

44 — 09.02.22 — 17:46

(43) А это не для тебя. 🙂 Для тебя (18)

   ДедМорроз

45 — 09.02.22 — 21:36

(42) у dll есть параметр,определяющий использование страниц кода,они могут проецироваться в адресное пространство сразу нескольких процессов без проблем,главное,чтобы виртуальные адреса совпадали.

Иначе бы,например,user32 было бы столько,сколько процессов,а так для вмех процессов одна копия в ФИЗИЧЕСКОЙ памяти.

   Anchorite

46 — 10.02.22 — 06:50

(0) Попробуйте добавить в исключения антивируса/Защитника Windows исполняемые файлы 1с и пути к платформе. У меня пару лет назад Розница на одной точке таким же образом постоянно валилась с ошибкой, такой вот ход конём помог.

   Anchorite

47 — 10.02.22 — 06:55

(3) Ну и насчёт веб-сервера непонятно, у вас там точно такая же ошибка? То есть и толстый клиент в файловом режиме, и тонкий клиент через веб-сервер выдают в точности одно и то же? Это очень странно, если так, сложно поверить. Попробуйте в таком случае доступ через браузер, уж там-то точно такой ошибки быть не может.

При запуске базы в режиме Предприятие начала появляться ошибка «Аварийное завершение».

Полный скриншот:

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

Приложение сразу закрывается после этой ошибки. При повторном запуске не появляется.

Носит нерегулярный характер (то появляется, то нет).

Возникла на платформе: 8.3.18.1334 (по сообщениях из чатов у других было на платформе 8.3.17.1851)

Операционная система Windows 10 корпоративная LTSC 1809 и Windows Server 2012 R2 Standard

Ошибка приложения записывается в системный журнал Windows в следующем виде:

Faulting application name: 1cv8c.exe, version: 8.3.18.1334, time stamp: 0x6021c237

Faulting module name: backbas.dll, version: 8.3.18.1334, time stamp: 0x6021c6c8

Exception code: 0xc0000005

Fault offset: 0x00000000000ce7f3

Faulting process id: 0x1840

Faulting application start time: 0x01d74ba9efcea74f

Faulting application path: C:Program Files1cv88.3.18.1334bin1cv8c.exe

Faulting module path: C:Program Files1cv88.3.18.1334binbackbas.dll

Report Id: 59b36157-b79e-11eb-811c-0cc47a6431af

Faulting package full name: 

Faulting package-relative application ID: 

Или на русском:

Имя сбойного приложения: 1CV8C.exe, версия: 8.3.18.1334, метка времени: 0x6021c237

Имя сбойного модуля: backbas.dll, версия: 8.3.18.1334, метка времени: 0x6021c6c8

Код исключения: 0xc0000005

Смещение ошибки: 0x00000000000ce7f3

Идентификатор сбойного процесса: 0x2840

Время запуска сбойного приложения: 0x01d74b4aa253611e

Путь сбойного приложения: C:Program Files1cv88.3.18.1334bin1CV8C.exe

Путь сбойного модуля: C:Program Files1cv88.3.18.1334binbackbas.dll

Идентификатор отчета: b175aeec-357b-4c35-bdbc-0bfc9883a372

Полное имя сбойного пакета: 

Код приложения, связанного со сбойным пакетом: 

Легальность продуктов 100% (эмуляторов нет и никогда не было). В одном месте кластер и настроен сервер лицензирования, в другом USB ключ. В интернете все советы сводятся к «удалите эмуляторы и т.п. нелегальщину», а затем всё удалите и поставьте заново с восстановлением баз.

Совсем не хочется делать это на серверных базах, где всё настроено под сервер лицензирования и постоянно работает несколько десятков пользователей.

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

UPDATE: 18.05.2021

Ошибка появляется, если есть доступ в интернет.

Проблему подвердили коллеги со всей страны.

Ошибка присутствует в версиях платформы начиная с 8.3.16.1791, 8.3.17.1823, 8.3.18.1201.

UPDATE: есть обратная связь от разработчиков платформы. Про проблему они знают.

Код ошибки для просмотра на трекере 1С — 40049115

Ошибка исправлена в версиях платформы начиная с 8.3.17.2231 и 8.3.18.1483 (дата публикации  19.05.2021).

Решение — обновить платформу, когда выйдет исправленный релиз.

Временное решение — отключить на машине доступ в Интернет. Также коллеги пишут, что как вариант, добавить в хост (в файл hosts) строку: 127.0.0.1 baidu.cn (но это не точно).

UPDATE: 21.05.2021

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

Если Вам понравилась статья, пожалуйста, поставьте лайк, сделайте репост или оставьте комментарий. Если у Вас есть какие-либо замечания, также пишите комментарии.

Перейти к контенту

На сервере с операционной системой Windows Server 2008 R2 x64. При запуске файловой базы данных 1С Предприятие 8.3.16 пользователи начали периодически жаловаться на следующую ошибку:

Сигнатура проблемы:

 Имя события проблемы: APPCRASH

 Имя приложения: 1cv8c.exe

 Версия приложения: 8.3.16.1030

 Отметка времени приложения: 5dbcc154

 Имя модуля с ошибкой: mngui.dll

 Версия модуля с ошибкой: 8.3.16.1030

 Отметка времени модуля с ошибкой: 5dbcc2fe

 Код исключения: c0000005

 Смещение исключения: 000a337a

 Версия ОС: 6.1.7601.2.1.0.144.8

 Код языка: 1049

 Дополнительные сведения 1: 0a9e

 Дополнительные сведения 2: 0a9e372d3b4ad19135b953a78882e789

 Дополнительные сведения 3: 0a9e

 Дополнительные сведения 4: 0a9e372d3b4ad19135b953a78882e789

Ознакомьтесь с заявлением о конфиденциальности в Интернете:

 http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0419

Если заявление о конфиденциальности в Интернете недоступно, ознакомьтесь с его локальным вариантом:

 C:Windowssystem32ru-RUerofflps.txt

Для исправление ошибки на разных серверах/компьютерах помогали разные методики.

Методы по исправлению данной ошибки (начиная с самой распространенной):

  

1. Переустановка платформы 1С:Предприятие (самая распространенная)
2. Обновление платформы 1С:Предприятие на более новый релиз
3. Если ошибка выскакивает после обновления конфигурации, то возможно это из-за нарушения целостности ИБ — рекомендую выполнить проверку копии(!) базы данных приложением chdbfl.exe(C:Program Files1cv88.3.XX.XXXXbin). Если ошибка при запуске исчезнет на копии  — повторить проверку на оригинале
4. На серверной операционной системе обновить версию Visual C++
5. Чистка кэша
6. Удаление антивируса и тестирование запуска без него (просто отключать нет смысла — именно удаление)
7. Пересоздание пользователя Windows
8. Пересоздание пользователя USR1CV8 и его повторная установка (для SQL версий)
9. Тестирование и исправление (через конфигуратор)
10. Отключение аппаратного ускорения в драйвере видеокарты
11. Отключение DEP
12. Запуск платформы 64x, вместо 32-битной (при ручном обновлении)

                   

Если Вы хотите заказать услугу «Выполнение регламентных операций (чистка, свёртка, исправление ошибок) и администрирование 1С» (код 2.9). Пожалуйста, ознакомьтесь с прайс-листом и оформите заявку через контактную форму.

Copyright©, «Программист 1С в г.Минске», 23.04.2020

Перепечатка текста и фотографий разрешена при наличии прямой ссылки на источник

Описание ошибки:
Ошибка может возникать в любой момент работы с программой в режиме 1С: Предприятие с сообщением операционной системы: «Прекращена работа программы 1cv8». Имя события проблемы всегда — APPCRASH. Имя приложения — как 1cv8.exe. Версия приложения — может быть разный релиз платформы 1С 8. Имя приложения может некоторые исполняемые файлы 1С, например .dll-файлы, к примеру — image.dll.

Найденные решения:

Ошибка возникла при работе на новом сервере под управлением операционной системы Windows Server 2012 R2 Standart

​

Полное представление текста ошибки на приведенном исходном примере:

Имя события проблемы: APPCRASH
  Имя приложения: 1cv8.exe
  Версия приложения: 8.3.17.1851
  Отметка времени приложения: 5fb4253d
  Имя модуля с ошибкой: image.dll
  Версия модуля с ошибкой: 8.3.17.1851
  Отметка времени модуля с ошибкой: 5fb422f5
  Код исключения: c0000005
  Смещение исключения: 000000000000b825
  Версия ОС: 6.3.9600.2.0.0.16.7
  Код языка: 1049
  Дополнительные сведения 1: 66dd
  Дополнительные сведения 2: 66dd99c00f1511f29603dc14c27696c5
  Дополнительные сведения 3: f347
  Дополнительные сведения 4: f347e941225f8ea0eef9d5b1459a8690  

Наиболее распространенный способ обхода данного рода ошибки — установить более новый релиз платформы 1С:Предприятие. В тексте ошибки виден релиз 8.3.17. На этот момент это был не самый последний релиз платформы. Поэтому был установлен предпоследний на тот момент релиз 8.3.18. Предпоследний, а не последний по той причине, что самые последние релизы могут содержать новые критические ошибки, о которых еще не известно повсеместно. А вот более в поздних часть ошибок либо уже известна, либо устранена. Но после установки релиза платформы 8.3.18 ситуация с ошибкой не изменилась, разве что изменились сигнатуры в тексте ошибки:

Сигнатура проблемы:
  Имя события проблемы: APPCRASH
  Имя приложения: 1cv8.exe
  Версия приложения: 8.3.18.1563
  Отметка времени приложения: 60e08480
  Имя модуля с ошибкой: image.dll
  Версия модуля с ошибкой: 8.3.18.1563
  Отметка времени модуля с ошибкой: 60e081e1
  Код исключения: c0000005
  Смещение исключения: 000000000000b885
  Версия ОС: 6.3.9600.2.0.0.16.7
  Код языка: 1049
  Дополнительные сведения 1: 66dd
  Дополнительные сведения 2: 66dd99c00f1511f29603dc14c27696c5
  Дополнительные сведения 3: bc70
  Дополнительные сведения 4: bc70c79f0523f7ad7a36c38eaeff4fc6

Как видно — из ключевых параметров ошибки — изменилась версия приложения на 8.3.18.1563. «Имя модуля с ошибкой» сохранилось — image.dll. Хотя на другом рабочем месте на той же «версии модуля с ошибкой» «имя модуля с ошибкой» было другим:

Сигнатура проблемы:
  Имя события проблемы: APPCRASH
  Имя приложения: 1cv8.exe
  Версия приложения: 8.3.18.1563
  Отметка времени приложения: 60e08480
  Имя модуля с ошибкой: StackHash_311d
  Версия модуля с ошибкой: 6.3.9600.20090
  Отметка времени модуля с ошибкой: 60e9188b
  Код исключения: c0000374
  Смещение исключения: PCH_84_FROM_ntdll+0x00000000000907BA
  Версия ОС: 6.3.9600.2.0.0.16.7
  Код языка: 1049
  Дополнительные сведения 1: 311d
  Дополнительные сведения 2: 311d24e439199cca8c346bd8cdb8f531
  Дополнительные сведения 3: 6598
  Дополнительные сведения 4: 65984feff9991957ae37d4c2d807d4ee  

Оставался последний из простых доступных вариантов — был установлен последний релиз платформы из имевшихся на тот момент времени — 8.3.19. После этого действия проблема больше не возникала.

Таким образом наиболее часто ошибка может возникать на устаревших релизах платформы 1С: Предприятие 8, установленных в новых операционных системах. Обновление релиза платформы или постепенная установка более новых релизов в большинстве случаев позволяет избавиться от возникновения ошибки.

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

Часто «имя модуля с ошибкой» может быть разным, например из часто встречающихся: core83.dll, MSVCR110.dll, backend.dll и могут быть другие .dll-файлы.

Еще наиболее интересную дополнительную информацию по проблеме можно посмотреть на сайте buhexpert8.

Или возможный последний вариант, если остальное не помогает — поменять «Основной  режим запуска» для базы в списке баз.

Оцените, помогло ли Вам предоставленное описание решения ошибки?

---

© www.azhur-c.ru 2014-2020. Все права защищены. Использование текстов и изображений с данной страницы без письменного разрешения владельца запрещено. При использовании материалов с данной страницы обязательно указание ссылки на данную страницу.

15-09-2021

Журавлев А.С.
(Сайт azhur-c.ru)

Category:

• Компьютеры
• Cancel

При старте 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)1cv88.3.10.2561bin1cv8.exe
Путь сбойного модуля: C:Program Files (x86)1cv88.3.10.2561bincore83.dll

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

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

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

Подумал, как еще можно снизить нагрузку на видеокарту? Снизил разрешение. И тут, о чудо! при разрешении 1280×720 1с начал стартовать.
Если базе дать запустится на низком разершении, а потом уже переключится в штатное для монитора 1920×1080, то база продолжает работать.

Где видео-карта и где 1с:Предприятие, казалось бы…