1С backbas DLL

Всем спасибо, кто откликнулся, сообщаю решение проблемы:
1) Причина: 1С основной причиной считает кривую работу HASP ключа или драйвера защиты или менеджера лицензий или работу сетевого оборудования, что вызывает временную потерю 1С 8.0 ключа защиты. Это все конечно так, НО! Похожую проблему может вызывать некорректные связки в SQL базе в таблицах config, configSave и systemobject, вызванные, к примеру, обрушением базы в момент сохранения конфы (реиндексации, рестурктуризации базы). При перезагрузке SQL он подхватывает частично верные и неверные таблицы (как это происходит наверное скажут спецы по SQL) и база продолжает нормально работать, но при попытке сохранить изменения начинает сказываться расхождение — и 1С «вылетает» с такой же ошибкой в модуле BackEnd.dll.
2) Лечение: Вся проблема в том, что решить ее средствами 1С невозможно — она отваливается при обращении к этим таблицам, ссредтва SQL тоже «не видят» проблем, т.к. SQL «по барабану», что изменения в базу не внедрены, а config уже новый. На форумах спец по SQL пишут, что повреждения systemobject — этпо полный … абзац — и НИКАК не лечится. Все верно! НО! Если есть резервные копии, то все значительно легче. Бэкапы могут быть 2 видов: выгруженные средствами 1С и бэкапы SQL. Разница — принципальная, т.к. при разворачинаии архива 1С, создается новая база с совершенно другими ID таблиц и systemobject-ом, что привод к полному краху идеи подмены таблиц. Проблема еще в том, что systemobject — это системная таблица и экспортровать ее очень тяжело. Поэтому дано обмануть и 1С и SQL. Делается это так:
а) разворачиваем во 2-ю базу бэкап (любой 1С или SQL), средствами SQL Export делаем замену config, configsave на аналогичные из копии.
б) заходим в конфигуратор (обычно он пускает, т.к. в этот момен 1С не проверяет соответствие таблиц в SQL) и делаем «загрузить конфигурацию из файла» (при том ндо сохранить конфу из нормальной копии в файл). 1С заглатывает удочку, т.к. в момент загрузки у 1С «нормальная» конфа в таблице config, а при замене конфигурации SQL перетраивает systemobject под новую конфу, но текущим таблицам. В результате мы имеем нормальный systemobject и нормальную конфигурацию. Все! Можно работать!
ЗЫ: Если есть нормальный архив, то все выше описанное никому не нужно, но есть один неприятный момент. Если после вылета 1С (см п.1) база продолжила нормально работать, то это НЕ ЗНАЧИТ что там нет ошибок, и в ваших архивах SQl и 1С эти ошибки будут сидеть и ждать своего часа, пока вы не решите сохранить конфу или протестироваться.

В декабре 2017 года фирма 1С выпустила новые платформы 8.3.10.2699 и 8.3.11.2899 и изменила механизмы проверки легальности программы. После обновления платформы на эти версии стала появляться ошибка «нарушение целостности системы».

После обновления платформы ошибка может появиться, при запуске в пользовательском режиме и говорить о том, что в системе установлена «взломанная» версия предыдущей платформы (изменены файлы backbas.dll, frntend.dll, mngcln.dll) или находятся следы эмуляторов USB-ключей. В случае изменения файлов библиотек *.dll достаточно удалить старую платформу или просто переустановить её, а в случае остатка следов от эмуляторов USB-ключей придётся потрудиться, чтобы восстановить легальное использование программы 1С.

Если Вы вставите USB-ключ или установите программные лицензии, база всё равно не запустится, пока не удалите все следы использования нелегального ПО 1С, т.к. при установке эмулятора происходит создание нового устройства и добавление записей в реестр Windows.

Рассмотрим вариант удаления эмуляторов из системы.

1. Открываем службы (Панель управления -> Администрирование -> Службы) и останавливаем: HASP Loader, Sentinel LDK License Manager, Агент сервера 1С:Предприятие.

2. Открываем Управление компьютером, вкладку Диспетчер устройств (Панель управления -> Администрирование -> Управление компьютером -> вкладка Диспетчер устройств -> раскрывающийся список Системные устройства) и удаляем устройство Virtual Usb Bus Enumerator.

3. Открываем реестр, нажав сочетание клавиш Win+R и написав команду regedit. Понадобятся права администратора.

Удаляем следующие ветки реестра:

Если был использован эмулятор — haspflt

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\haspflt¬\

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Emulato¬r

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Emu

Если был использован эмулятор vusbbus

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\NEWHASP

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet001\NEWHASP

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet002\NEWHASP

Возможно еще понадобиться удалить следующие ветки реестра

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vusbbus

После удаления данных из реестра, перезагрузите компьютер.

В случае, если вы боитесь удалять эти данные из реестра, то можно сделать бэкап указанных веток реестра, нажав правой кнопкой мыши на нужную ветку, и выбрав пункт меню «Экспортировать».

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

4. Проверьте и удалите из системы файлы vusbbus или haspflt.

5. После этого, желательно переустановить новую платформу, установив в конце драйверы защиты, чтобы перезаписать все файлы драйвера аппаратной защиты.

Eсли данная инструкция вам не помогла, то можно переустановить систему, на которую поставить чистую платформу. Данный вариант является достаточно трудоемким, поэтому рекомендую пользоваться им в самом крайнем случае, тем более, что в моей практике данный метод не приходилось использовать, все следы эмуляторов прекрасно удалялись.

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