столкнулся с такой проблемой

Имя сбойного приложения: 1cv8.exe, версия: 8.2.14.533, отметка времени: 0x4e5bef3c
Имя сбойного модуля: basic.dll, версия: 8.2.14.533, отметка времени 0x4e5be779
Код исключения: 0xc0000005
Смещение ошибки: 0x000166e0
Идентификатор сбойного процесса: 0x1cec
Время запуска сбойного приложения: 0x01cc79d769f88c63
Путь сбойного приложения: C:\Program Files (x86)\1cv82\8.2.14.533\bin\1cv8.exe
Путь сбойного модуля: C:\Program Files (x86)\1cv82\8.2.14.533\bin\basic.dll
Код отчета: b62daeb7-e5ca-11e0-be20-002590005d15


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

1С 8.2 крутиться на 2008 64 серваке , юзеры подключены через терменал.

Динамическое обновление юзали?

При работе не через терминал а по сети тоже ошибка?
Какой антивир на серваке?И есть ли он вообще?

да, было дело ...


антивирь аваст


у меня все работают только через терменал

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

есть хоть какие то предположения? из-за чего это может быть?
вариант переустановить сервак не хотелось бы рассматривать ))

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

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


инфа довольно интересная, но у меня файловая база (

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

больше предложений нет ?

А такие простые вещи, как Тестирование и Исправление и Выгрузить/загрузить пробовали?

х

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

всем спасибо за внимание , проблема решена

Ну так поделитесь решением проблемы

от жеж, поки писав пост - не побачив, що проблему вирішено якось вже

собственно проблема оказалась в конфе, более детально описать не могу так как сам не программист 1С, а сисадмин. Ну а майкрософт как обычно с своими ошибками кого угодно в тупик поставит. из выше указаной ошибки полезной инфы ровно ноль!!!!

если не ошибаюсь проблема была с регистраторами

скажіть хоч, що ви зробили для її вирішення чи це робили не ви?

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

Похоже дело было в каком-то битом потоке объекта конфигурации - это частый сбой при динамических обновлениях. Сам бился с подобным несколько дней в УПП Тоже решилось заменой объекта в конфигурации

Отсюда вывод, динамическое обновление еще не совсем динамическое )

Сегодня столкнулся с этой же бедой. Почитал тему, полазил по ссылкам. В итоге помог вот этот скрипт с Мисты (выполнять в консоли SQL-сервера):

use ИмяАктуальнойБазы
go

truncate table [dbo].[Config]
truncate table [dbo].[ConfigSave]
truncate table [dbo].[DBSchema]
truncate table [dbo].[Params]
--truncate table [dbo].[Files]
go

insert into [dbo].[Config] select * from [СтараяБазаИзБекапаНаЭтомЖеСервере].[dbo].[Config]
insert into [dbo].[DBSchema] select * from [СтараяБазаИзБекапаНаЭтомЖеСервере].[dbo].[DBSchema]
insert into [dbo].[Params] select * from [СтараяБазаИзБекапаНаЭтомЖеСервере].[dbo].[Params]
go

В чем вообще проблема: после каких-то динамических обновлений конфигурация оказывается запорчена. Это выражается разными симптомами - не проходит применение изменений из Конфигуратора, юзеры вылетают в винду с ошибкой basic.dll, тестирование и исправление просто закрывается и т.п.

Что нужно для исправления: заменить конфигурацию на исправную из бэкапа. Если бэкапы регулярно не делались - Вам сильно не повезло.
В чем подвох: Конфигуратор это сделать не может. Даже при попытке Загрузить конфигурацию (а не Сравнить/Объединить) Конфигуратор падает на этапе принятия изменений.
Выход: заставить SQL-сервер сделать всю работу.

Конфигурация хранится в таблице Config, ConfigSave = непримененные изменения. Мы просто затираем нашу испорченную конфигурацию и потом вставляем поверх нее рабочую из бэкапа. Данные при этом не страдают. Всего-то и нужно развернуть бекап на том же сервере, но в другую базу, и выполнить скрипт, поменяв имена баз на свои.

Еще по теме: вот необходимо зарегистрироваться для просмотра ссылки все о том же. Там еще и комменты почитать стоит - в них есть пример такого же "лечения" для базы на PostgreSQL. Вдруг кому поможет.

Дополнение по теме: думаю, что нашел, при каких условиях этот глюк происходит.

Требуется: сетевая версия 1С 8.2 (с другими не проверял), 2 и более компьютеров (назовем их А и Б), с которых делаются динамические обновления.

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

Что происходит: на машине Б в этот момент находится "неправильная" копия метаданных (в кэше метаданных), так как окно Предприятия не закрывалось и заново метаданные с сервера он не получил. Открываем Конфигуратор, и он (очень похоже на то) использует эту же самую, уже устаревшую, локальную копию! Делаем изменения. При применении изменений из такого Конфигуратора, похоже, и происходит "порча" базы.

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

Какая именно ЭТА ошибка?

Та ошибка, о которой вся тема, в которую я написал. Всегда Ваш, К.О.

Скрипт выше помог, спасибо автору

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