Коллеги, столкнулись с необъяснимым вылетом баз 1С. Прошу помощи, может,  у кого случалось подобное?
  
Комплексная автоматизация 2.4.5.41, обработка «Рабочее место работника склада» - проблема воспроизводится со 100% вероятностью.
Жмем кнопку «Приемка», далее выбираем задание, жмем «выбрать», жмем «Перейти к сканированию», затем (ничего не сканируя) жмем «3. Назад», жмем «Отменить выполнение задания» - и в этот момент получаем ошибку "Не удалось снять блокировку с объекта. Объект не заблокирован".
Аналогичная ошибка выдается в момент завершения задания на размещение товара в той же обработке.
  
Ошибки начали появляться примерно неделю назад. На тот момент была платформа 8.3.11.3133. Перешли на 8.3.12.1567 – проблема осталась без изменения. Какое-то конкретное событие, после которого начались проблемы, выявить не удалось.

Воспроизводится на всех серверных базах «комплексной автоматизации 2.4.5.41» (и рабочая,  и тестовые).
В файловых тестовых базах (выгрузка-загрузка dt файла из рабочей) ошибка НЕ воспроизводится.
В развернутой с нуля (из шаблона конфигурации) демо-базе (серверной) – воспроизводится. В файловой – НЕ воспроизводится.
  
Перезаливка dt-файла в другую серверную базу не помогает.
Переподключение базы в списке баз и непосредственная очистка кеша не помогают.

Службу сервера 1с перезапускали – не помогает.

21 сентября перезагрузили сервер, на котором работает служба сервера 1с, и сервер, на котором работает sql, – после этого сразу проверили – проблема исчезла.
23 сентября проблема снова появилась.
  
Также, одновременно с появлением проблем с «комплексной автоматизацией 2.4.5.41», стала ненормально вести себя (тоже серверная) база «комплексная автоматизация 1.0». А именно: при попытке пользователя редактировать объект, если он уже заблокирован другим пользователем, обычно программа просто сообщает «…объект заблокирован…» и позволяет нормально продолжить работу. Теперь же в подобной ситуации продолжить работу невозможно, так как в окне о блокировке есть только кнопка «завершить сеанс».

Еще симптом, который наблюдается во всех серверных базах: если кто-то сидит в конфигураторе (просто открыли его и ничего не меняли) и в это время кто-то другой пытается запустить сеанс предприятия, он не сможет зайти (не всегда, но часто) - получит сообщение об ошибке вида "Активны сеансы: Иванов Иван, конфигуратор". После выхода из конфигуратора проблема исчезает и зайти дает.
  
Сервер 1с и сервер sql едины для всех баз. Сервер 64-битный, клиенты тоже.
  
Пожалуйста, помогите решить проблему. Если нужны дополнительные данные, готовы предоставить.

(0)[сервер sql едины для всех баз]
и что использовано в качестве СУБД ?

ставьте 13 платформу. Как раз зарелизили

Это больше похоже на ошибку в коде 1С.  Пытаются снять блокировку, которую не установили.

(0) на хотлайн писать не пробовали?

(0) Отладчик тебе поможет

(0) КА 2.4 - видел такую ошибку в "Рабочее место работника склада" - файловая или нет была - не вспомню. После сканирования и попытки добавить в документ позиции - вылезала ошибка про блокировку объекта.

СУБД - Microsoft SQL Server

Ставить самую свежую (и возможно сырую) платформу - имеет ли смысл? Добавит новых глюков без гарантии исправления текущей проблемы...

Не думаю, что проблема в коде. Повторюсь - при загрузке dt из рабочей (проблемной) базы в файловую глюка с блокировкой нет. И все остальные описанные странности в поведении другой базы (КА 1.0) возникли примерно одновременно с этой "блокировкой".

Это, совместно с тем, что проблема исчезла на краткий промежуток времени непосредственно после перезагрузки серверов 21 сентября,  дает причину подозревать проблему на серверах.

Наверно, можно вытащить что-то полезное из техножурнала, но детально расшифровать его не могу. Включили его на полчаса, собрали логи, среди записей есть такие:
42:51.594083-0,EXCP,0,process=rphost,OSThread=6372,Exception=dd149677-3d47-4e05-a55f-4e75b13a441f,Descr='src\RMngrCalls.cpp(584):
dd149677-3d47-4e05-a55f-4e75b13a441f: Процесс завершается. Исходящий вызов запрещен.'
42:51.594085-0,EXCP,0,process=rphost,OSThread=6372,Exception=ba8a0cd1-c2cc-4b84-a837-a0dda720ff4e,Descr='src\RHostImpl.cpp(5855):
ba8a0cd1-c2cc-4b84-a837-a0dda720ff4e: Не найдено ни одного сервера с размещенным сервисом
serviceName=ClusterLockService;'
42:51.594086-0,EXCP,0,process=rphost,OSThread=6372,Exception=dd149677-3d47-4e05-a55f-4e75b13a441f,Descr='src\RMngrCalls.cpp(737):
dd149677-3d47-4e05-a55f-4e75b13a441f: Процесс завершается. Исходящий вызов запрещен.'
42:51.594087-0,EXCP,0,process=rphost,OSThread=6372,Exception=dd149677-3d47-4e05-a55f-4e75b13a441f,Descr='src\RMngrCalls.cpp(737):
dd149677-3d47-4e05-a55f-4e75b13a441f: Процесс завершается. Исходящий вызов запрещен.'
42:51.594088-0,EXCP,0,process=rphost,OSThread=6372,Exception=96380a22-60f7-4a8b-8fca-1224e6bc518f,Descr='src\RMngrCalls.cpp(949):
96380a22-60f7-4a8b-8fca-1224e6bc518f: onFinishConnection'

Не факт, что эти строки техножурнала связаны именно с нашими гляками, просто этих Exception много.

Еще в SQL Profiler искали проблемные блокировки, в соответствии с этой инструкцией: https://its.1c.ru/db/metod8dev#content:1738:hdoc

Трассировка показала, что таковых нет.

Причем тут СУБД ебанарот! Ошибка в обработке.

(9) Расступитесь шире, гений пришел! Ебанаротовый!

Еще один симпом стал появляться: сижу в конфигураторе одной базы, а юзеров выкидывает из двух других. Им вылезает сообщение "Активные сеансы: ... конфигуратор..." и две кнопки "Завершить работу" и  "Перезапустить". При попытке перезайти - то же самое.

После выхода из конфигуратора - всех сразу пустило.

(11) А почему сидение в конфигураторе, должно выбивать пользователей?

(12) Потому что когда не умеешь пользоваться отладчиком, ищешь любую возможность за что зацепиться
(10) Все верно, спасибо

(12) Вот именно, что не должно. И не выбивало никогда раньше.
Тем более сидение в конфигураторе другой(!) базы.

Может на сервере с памятью чего случилось? В Виндовом журнале ничего нет?

(4) Написали на [email protected], пришел автоответ, что "обращение зарегистрировано и будет рассмотрено в ближайшее время"

(14) У тебя что-то с сервером не то. Почистить ему кэш, возможно rmanager отвалился или места нет.

(15) В журнале событий Windows сервера, на котором запущена служба "сервера 1С", не вижу ничего криминального.

Из последних событий (ближайших к моменту специально вызванной ошибки с блокировокой):
The "vmGuestLibrary" is successfully initialized for this Virtual Machine.
The "vmStatsProvider" is successfully initialized for this Virtual Machine. WMI namespace: "root\cimv2".


За последние сутки несколько записей есть с типом "ошибка":

раз:
Сбой служб шифрования в ходе обработки вызова OnIdentity() в объекте "Системный модуль записи".
Details:
AddLegacyDriverFiles: Unable to back up image of binary Протокол Microsoft LLDP.
System Error:
Отказано в доступе.

два:
Ошибка в процедуре открытия службы "BITS" из библиотеки "C:\Windows\System32\bitsperf.dll". Данные производительности не будут доступны для этой службы. Первые четыре байта (DWORD) в разделе данных содержат код ошибки.

три:
Сбой активации лицензий (slui.exe) со следующим кодом ошибки:
hr=0x8007232B
Аргументы командной строки:
RuleId=502ff3ba-669a-4674-bbb1-601f34a3b968;Action=AutoActivateSilent;AppId=55c92734-d682-4d71-983e-d6ec3f16059f;SkuId=8c1c5410-9f39-4805-8c9d-63a07706358f;NotificationInterval=1440;Trigger=UserLogon;SessionId=4



И есть одна запись с типом "предупреждение":
Не удалось собрать данные об использовании физической памяти NUMA. Первые четыре байта (DWORD) в разделе данных содержат код состояния.

На сервере, где работает MS SQL server, в журнале windows сообщения такие же. Тоже ничего подозрительного.

На обоих серверах процессор занят на 10-25 процентов. На сервере 1с кратковременные (до минуты) скачки до 60% бывают.

Память: на сервере 1с занято 16-35 ГБ (из 32), на сервере SQL занято 30 ГБ (из 32). Так было и месяц назад, когда не было глюков.

(18) Уууу. Так вы на виртуалке. Это все объясняет.

(18) Может их просто не замечали?

Ставить 1С на виртуалку или запускать ее от доменного пользователя вообще не рекомендуется.  

Ставить SQL сервер на виртуалку без толстенного iSCSI я бы вообще не стал.

+(20) Тебе нужно не логи гостя смотреть а хоста. И для начала отключите совместное использование памяти в настройках хоста.

(20) Что, глюки (именно ошибки) сервера 1С, вызывающие вылеты, вызваны именно виртуалкой? Вроде ни одной ошибки такого рода никогда не фиксировалось

(23) У хостов на виртуалке бывают сбои с ip/dns именем или временем. Их 1С очень и очень не любит.

(24) Есть какие-то признаки в ТЖ, помогающие определить эти сбои хостовой ОС, или - как обычно - невнятная последовательность EXCP? ))

(25) Вот это мне сильно не понятно:  
Не найдено ни одного сервера с размещенным сервисом
serviceName=ClusterLockService;'

Выловили в техножурнале кусок, явно относящийся к ошибке с блокировкой:

21:06.200023-312011,SDBL,3,process=rphost,p:processName=ka2_test2,OSThread=8200,t:clientID=36,t:applicationName=1CV8C,t:computerName=MSK1-1S2,t:connectID=9,SessionID=1,Usr=tsd_big,AppID=1CV8C,Trans=0,Func=HoldConnection,Context='Форма.Вызов : Обработка.РабочееМестоРаботникаСклада.Форма.ФормаРабочегоМеста_480х640.Модуль.ОтменитьВыполнениеЗаданияНаСервере
Обработка.РабочееМестоРаботникаСклада.Форма.ФормаРабочегоМеста_480х640.Форма : 760 : РабочееМестоРаботникаСкладаСервер.ОтменитьВыполнениеЗадания(ЭтаФорма);
    ОбщийМодуль.РабочееМестоРаботникаСкладаСервер.Модуль : 813 : ПараметрыЗадания = РабочееМестоРаботникаСкладаПрограммныйИнтерфейс.ОтменитьВыполнениеЗадания(Задание,
        ОбщийМодуль.РабочееМестоРаботникаСкладаПрограммныйИнтерфейс.Модуль : 1587 : УстановитьИсходныйСтатусСкладскогоЗадания(Задание, ТипЗадания, ПараметрыЗадания);
            ОбщийМодуль.РабочееМестоРаботникаСкладаПрограммныйИнтерфейс.Модуль : 5125 : ДокументОбъект.Записать(РежимЗаписи);'
21:06.231003-0,EXCP,3,process=rphost,p:processName=ka2_test2,OSThread=8200,t:clientID=36,t:applicationName=1CV8C,t:computerName=MSK1-1S2,t:connectID=9,SessionID=1,Usr=tsd_big,AppID=1CV8C,Exception=580392e6-ba49-4280-ac67-fcd6f2180121,Descr='src\VResourceInfoBaseImpl.cpp(1176):
580392e6-ba49-4280-ac67-fcd6f2180121: Неспецифицированная ошибка работы с ресурсом
Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:
e0506925-b3e4-4dfb-b2fd-309eb7908ae3: Ошибка снятия блокировки объекта. Объект не заблокирован'

(27) Как мы долго этого ждали. Осталось найти это в обычном журнале. CallStack обрезан,  с фоновыми заданиями это нормально.


Я ставлю на это место : УстановитьИсходныйСтатусСкладскогоЗадания(Задание, ТипЗадания, ПараметрыЗадания);

Скорее всего не проверяется создано ли вообще задание.


ЗЫ: Я бы взял тебе тестировщиком, если бы были места.

Я не понял, каков итог? Где был источник проблемы? Устранили ли его?