Подскажите, кто знает, что делать - 1С 8.0 выдает ошибку "Ошибка приложения 1cv8.exe, версия 8.0.18.2, модуль BackEnd.dll, версия 8.0.18.2, адрес 0х001685b4". Ошибка появилась после сохранения изменения в конфигурации (каждый день приходится что-то дописывать, т.е. изменение конфигурации шло постоянно в течении 3 лет. Изменение было плевое - была исправлена одна строка в модуле формы документа, т.е. реструктуризаций и т.п. не было). 1С позволяет входить в конфигуратор, производит все действия, кроме тестирования БД, запуска отладчика и запуска в пользовательском режиме. Система установлена на Win2003SP1+Terminal+SQL2000SP4+1C 8.0.18+VirtualUSBEnumerator+дампы+Aladdin LM. Пробовал использовать патченный BackEnd.dll - эффект = 0.

Книга знаний: Быстрое создание и настройка правил обмена для зависимых объектов в Конвертации Данных v8

(0) была у меня такая проблема. Только во время загрузки кладр вылетело, а потом постоянно начало сыпаться. Лечил простой перестановкой 8.x.

А вообще, если дампы - то можно всего ожидать...

Не помогает :) Я даже сервер 1С и клиента перенес на другую машину - одна фигня. Есть еще одно замечание - глюки только с одной базой, но как их лечить? База 40 Гб :)

(3) файл, SQL?

Да

Он другим быть не может :) Флайловый - только 2Гб.

Выгрузку и загрузку в другую SQL базу?

(6) Я буху под 3 гига видел - полет нормальный. С моей помощью..)

Эффект = 0, видимо проблема с базой, но как ее решать, нигде не нашел :(

(6, 8) Речь не о размере ВСЕЙ базы :)

Что имеется ввиду под названием "вся база"? У меня 40Гб - это информация  SQL о файле mdf, при этом сам mdf - 46Гб

(11) Потому что ограничение ДБФ - на размер одного файла и кол-ва записей в нем

У 1С 8.0 файловая база - 1 файл

(13) Это не ДБФ
А выгрузить дает? А поиск ничего не дал?

(14) что не дбф - это понятно, ладно разговор уходит не туда :) База видимо повреждена на уровне SQL, т.к. все операции загрузки, выгрузки как 1С так и SQL проходят нормально, просто 1С отказывается запускаться в рабочем режиме и тестироваться. И я не понял, поиск чего "ничего не дал"?

(15) Вот, вот, не ДБФ, а нечто свое :)
Ну по сабжу не помогу, поэтому и предложил фпоиск :)
Переставь 1С, выгрузить базу попробуй... снеговик загадочен :)

(16) Мдя? Ладно и на этом спасибо :)

Может кто знает что делать?

может того, вроде "гипертрейдинг" называется - поставить приложение в исключение?
или на рабочей станции аналогично ошибку выдает ?

не - в свойствах компьютера (2003 сервер) "Предотвращение выполнения данных"

(19) на любой другой машине такая же фигня :(
(20) там и так стоит "выполнение только для основных служб Windows"

Ап

Ап

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

Очень благодарен г-ну Sagitarius'у! Вышеуказанный рецепт работает на 100%!.