При работе с 1С через терминал, при изменении реквизитов ТМЦ, последняя переодически ввываливается с ошибками(память не может быть считана или записана):

* Ошибка приложения 1cv7s.exe, версия 7.70.0.21, модуль Basic.dll, версия 7.70.0.21, адрес 0x00075fed.

* Ошибка приложения 1cv7s.exe, версия 7.70.0.21, модуль mfc42.dll, версия 6.6.8063.0, адрес 0x0004cd5b.

*  ошибка приложения 1cv7s.exe, версия 7.70.0.21, модуль br32.dll, версия 7.70.0.14, адрес 0x0001987c.

Было замечено, что ошибка вылетает в том случае, когда редактируются Элементы Справочника ТМЦ (менются цены, штрихкода, названия и т.д..)
При чем может вылетеь как на 1 карточке ТМЦ, так и на 20-30 ...
Люди, которые создают накладные, делают отчеты на вылеты не жалуются.
Подскажите где копать ??? А то у нас 7 сентября переоценка товаров, и что-то не хочется каждых 2-5 минут запускать 1С заново.

Книга знаний: Автоматическое сохранение (backup) базы 1С:Предприятие средствами SQL
Книга знаний: Загрузка внешних компонент 1С: проблемы и решения

Для начала релиз платформа по-свежее  поставте.

на какой посоветуете поменять?

(3) на последний

(0) 1С лицензионная ?

(3) 27-й, вроде последний

(6) последний-последний... Только поможет вряд ли. 21-й стабильный релиз.
(0) ТиИ-то гонял?

1С с аппаратным ключем, который ввиду нестабильности был заменен ХАСП-эмулем от Соболя))) Ветку 21 выбирал как более-менее стабильную.
Тем более напомню еще раз: падает 1С при изменении товаров и их свойств (цена, штрих-код и т.д.). Если бы дело было в нестабильности релиза она бы падала при создании накладной, перепроводке, формировании отчетов (ИМХО).
Возможно проблемы из-за видео на сервере? (оно у меня интегрированное в мамку и макс.размер его 8 Мб).

(8) Не вижу связи видео на сервере и работе в терминальном режиме...

согласен, что не видится.
Но, пока на сервере стояло разрешение 1280*1024, клиенты (а у них стоят 15" моники с расширением 800*600) вообще не могли запустить 1С: она постоянно падала с ошибкой:
* Ошибка приложения 1cv7s.exe, версия 7.70.0.21, модуль frame.dll, версия 7.70.0.14, адрес 0x0001a540.

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

(10) хе... спс за инфу. Может и правда дело в видюхе

есть у кого-то предложения, что можно еще посмотреть?

(12) На (7) так и не ответил

+(13) Насчет соболя погорячился. Фиговенько он на современных процах себя ведет, а ты его на терминальный сервер. Нормальный ключ работает куда стабильнее, ставишь на серваке последние дрова с www.aladdin.ru, менеджер лицензий, в X:\Program Files\1cv77\BIN\nethasp.ini пишешь:
NH_TCPIP = Enabled    ; Use the TCP/IP protocol
NH_SERVER_ADDR = 192.168.0.1 ; где 192.168.0.1 пи-пи сервака
NH_PORT_NUMBER = 475
NH_TCPIP_METHOD = TCP
и ключ находится как шелковый (ну если не беленький конечно :))

к сожелению, я не настолько гуру в 1С, потомоу ТиИ погонять для меня загадка (ввиду отсутствия понимания что єто такое :) ).

а по поводу ключа: когда бралась 1С (это было когда программы были маленькими, а компы - большими) он стоял смирно в ЛПТ порту. После того много воды утекло, и при очередной замене железа он был отдан в центральный офим на сохранения (дабы не потерятся), так как 1C_patcher_soaron_17-21 работал намного стабильнее )))

ТИИ - тестирование и исправление , (только перед этип сохранить копию)

на самомем деле причин вылета может быть масса

а-а-а-а ... делано ... никаких проблем. Ошибок не найдено.

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

конфа типовая? если не ты делал изначально, просмотри повнимательнее кон модуля формы карточки ТМЦ И модуля списка

давайте будем думать последовательно.
на Терминальном сервере работают люди в различных приложениях. Работают без видимых проблем.
Во-вторых: при работе с накладными в 1С (перепроводка, создание налоговых ...) а также при формировании отчетности никаких проблем не видно.
Отсюда видно, что можно исключить неправильную работу Терм.срвера и самой 1С (на этом этапе).
Но когда начинают затрагивать картотеку товаров - вылетает. Возможно из-за того, что в карточке слишком много параметров? и при проведении транзакции мы не укладываемся в какое-то время? либо не умещаемся в отведенный для этого объем памяти??

конфа писанная практически с нуля. Писал толковый парень (он и до сих пор сопроваждает и поддерживает ее). Думаем вместе над этой проблеммой.

(20)+ это в случае если конфа не типовая.

Используются ВК ? может быть дело в них (совместимость)

(23) ВК ?

Внешние компоненты? Да.
Используем v7Queue для работы с очередью сообщений MSMQ (для автоматической обработки накладных скинутых с КПК по GPRS).

Поди еще и прямые запросы есть?

вроде бы нет (если я правильно понимаю понятие прямых запросов).

(27) ну это проще у толкового парня спросить :) Если в справочниках с ними поигрался, мог с блокировками не разрулить например...

например? Что имеется ввиду блокировка ?

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

(29) sql'евские
(30) Не может, если нет прямых. Если же есть, то что угодно быть может. Мне удавалось и скуль завалить, не то что одинэску (правда там объемы сумасшедшие были)...

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

база на ДБФ. Все обработки над базой делаются только посредством встроенніх механизмов в 1С (без всяких примочек).
Размер наибольшего файла из базі: DT120.DBF - 118 Мб.
Размер всей базі - 536 Мб.

(33) вроде не тяжелая...

да. Еще один момент.
База на ДБФ, а 1С ставили с поддержкой sql ))

(35) ну это-то как раз пофик...

был замечен момент подтормаживания, во время работы с картотекой. Тоесть:
как только запустил 1С все изменения проводятся шустро... через 5-20 карточек, после внесения изменения в карточку и нажатия на кнопку подтверждения изменений база "задумывается" - карточка проводится дольше обычного... и с каждым разом время все ощутимей увеличивается ... до тех пор, пока однажды 1С после нажатия на кнопку ОК просто вываливается.

(37) Похоже на утечку памяти, код надо смотреть. Где-то что-то накапливается и не освобождает. Возможно та самая ВК, и имеет смысл ее подключать не в глобальнике, а перед каждым использованием, после чего выгружать.

+(38) Может просто в глобальнике ТЗ создал и строчки в нее добавляет не удаляя. Короче без базы это уже гадание на кофейной гуще...

куда именно в код смотреть ?
Справочники.ТМЦ ?

(40) Ну ты как спросишь тоже :) У тебя там самописка с нуля, я ее в глаза не видел, может форма списка справочника, может форма элемента, может глобальник, а если пробема в ВК, то любое место где она используется...

хм ))) можно ж показать )

(42) И я прям с первого взгляда точно в яблочко )

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

чувствую, что решение где-то сверху. Аналогичная база стоит на центральном офисе ... (с небольшими отличиями). У них таких проблем нету ...

(45) Ну так сделай объединение конфигураций, все отличия-то и увидишь...

Впрочем может в центре просто сервант мощнее... Той же оперативы больше, вот и вытягивает.

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

(47) серверы брендовые и одинаковые.

(48) Значит форму элемента и надо трассировать, где-то там намудрил

будем ловить ... утро вечера мудрее ))

(50) Все что внизу модуля после процедур первым делом в ПриОткрытии() засуньте, там если с формой чего делать может завалиться.

+(51) Там фишка в том что до того как ПриОткрытии() начнет работать формы в памяти еще нет, и если к ней обращаться получается ссылка в небо. Правда не в терминальном режиме проблема есть только во внешних отчетах, в модулях работает нормально. Но если валится то именно с ошибкой "память не может быть read"

(52) Это важная инфа , я этого не знал

Ну вообще-то если имеем сообщение типа "память не может быть прочитана", то первое необходимое действие - проверка на вирус(считаем, что железо в норме). И уж потом установить релиз движка поновее и какую-нибудь типовую конфу и проверять. Если вирусов нет и типовая конфа на нормальном релизе ошибок не дает, то все претензии к "толковому парню".

вирусов нету (говорю настолько уверенно, насколько это можно сказать) :) ... железо в норме (говорю настолько уверенно, насколько это можно сказать) :) ...

типичная конфа не подходит - слишком много специфичных отчетов написано в "самописи" )))
(52) валится не только с ошибкой память не может быть read, а также с ошибкой память не может быть write.

(0) Права, количество открытых файлов, неправильные индексы, где-то закрался спецсимвол в таблицу, тупо физически нехватает памяти, блокировки, глючная видео, поставить 25 или 27 релиз, пнуть ногой умного парня что б решил вопрос, пригласить другого 1С-неГа, ...

сделал копию базы, подключился к ней ... меняю карточки .. уже штук 50 поменял - полет нормальный...
думается проблема в множественном доступе к изменяемым позициям (30)

(55)Типовая конфа только для понимания, что явялется причиной падений - конфа или движок.

как вариант еще есть одна возможная проблемма:
покольку у нас реализована система автоматической обработки накладных скинутых из КПК, то на Сервере круглосуточно висит запущенная 1С под спец пользователем. Замечен интересный момент: после полуночи система автоматической обработки заказов перестает работать. Ее нужно перезапустить (выйти этим пользователем из 1С и зайти заново).
При чем очень интересный факт наблюдается: если в этот момент еще кто-то залогинен в систему - то пускает без проблем. Если же это делать с самого утра (перезапускать спец.пользователя) то 1С попросит переиндексировать базу.
Видимо что-то в системе подвисает, что приводит к утечке ресурсов.

(60) Переведи в скуль - там такой проблемы нету. Ну или "научи" юзеров нормально выходить из 1С.

(59) ну это явно проблема в ВК..

(60) нет проблемы "система автоматической обработки заказов перестает работать"? :) Основная проблема у них не в переиндексации...

выходят пользователи нормально, корректно. Но один пользователь (система автоматической обработки входящих сообщений из MSMQ) остается залогиненым наночь. И если на протяжении дня он обрабатывает очередь сообщений нормально, то на утро, он молчит .. у него затык. Закрываешь его копию 1С, залогиниваешься повторно и:
1) если в системе уже  кто-то зареган, то 1С просто запускается, при этом автомат начинает резко обрабатывать все заказы накопившиеся у него в очереди .. в системе появляются новые накладные ...

2) если в системе никого нету, то при логине выскакивает, что работа была завершена аварийно, и необходимо переиндексировать базу...

З.Ы: Вот обсуждаю тут с вами траблу - и мне почему-то кажется, что круг подозрительных событий сужается)) Всем спасибо, кто помагает думать в верном направлении )))

(63) Ну тогда действительно ВК. Попробуй время от времени ее выгружать и подгружать снова, не закрывая сеанс.

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

Сегодня утром все работает отлично.
Что было произведено из действий:
1) на все каталоги, которые принимают участвие в процессе работы (База, папка очереди сообщений ...) были даны ПОЛНЫЕ права для всех ... (понимаю что плохо).
2) была установлена служба: "Триггеры очереди сообщений".