Доброго времени всем и с наступающим/наступившим Новым годом.
Прошу помощи. 1с 7.70.0.27-сетевая работает в конфигурации РарусАльфа 3.09 Автозапчасти+автошины ( размер базы порядка 2.3 гига.)на Windows Server 2003sp2 64 bit терминале (работают от 6-14 пользователей).

Проблема вот в чем. Около 3-х недель назад началось падение 1с при подготовке отчетов. Падение наблюдается при любых периодах и любых отчетах. Выглядит так: на клиенте: или белый экран или просто зависание на енной строке подготовки или вывода данных.
в это время на сервере (если белый экран) память которую занимал процесс падает от десятков Мб до порядка 1 мб и полная загрузка ядра процессора;
если зависание при выборе или выводе данных то полная загрузка ядра при этом видно что процесс перестал использовать память но объем под процессом остается тот же.

До этого в течении нескольких лет проблем небыло.
что сделано мной: Проверено сервер на наличие заразы. Проверено Рейд на наличие ошибок диска. Отключен-удален антивирус. а также установлена внешняя компонента TerminalSleep. собственно теряюсь в догадках

Прошу помощи. Заранее спасибо.

на даный момент ситуация такая...1с не зависла при ТиИ ...а задумалась...есть проблема в регистры но корень ее тянется в 2005 год ... и проходит она по архивам с 2009 года...те что у меня есть доступны...по этому пока ищу еще возможные причины...
Журнал чист...кроме отключения клиентов по впн инородных событий нет....

еще раз просмотрел таблицу на которую ругается ТиИ
http://i60.fastpic.ru/big/2013/1231/c5/84994f92ac6af1fdfba844e1801253c5.jpg
как вот с этим база могла работать и индексироваться...никак в голову не влазит

Индексироваться - легко. А работать не всегда - как попадет (потребуется алгоритму) условие поиска по индексу.

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

а чем может быть дело , 1с 7.7 DBF грузится база по 2-3 минуты, жутко тормозит, но в терминале все летает.
Тестирую скорость загрузки файлов на сервер -> 30мБит загрузка сети , показывает  по диспетчеру задач.
Сеть 100мБитная.
Кидал сетевой провод прямо с компа на сервак - тоже самое, тормоз.
W2008R2 и компы с W7 XP , разные.
Все так же тормозят.

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

(41) http://kb.mista.ru/article.php?id=136

(38) Касательно вот этой ситуации...скажите свое мнение...может ли она влиять на работу...после ТиИ эта жуть остается в базе...в свое время я такое встречал в фоксовых dbf..появлялось как правило в конце таблици..обычно после того когда пропадал свет а в этот момент велась запись на диск...но  там индексация не проходила ...а сам фокс орал что повреждена таблица...лечил c помощью cdbf...собственно вопрос в чем...с тем что база 1с проходит индексацию и вот эта жуть остается в базе...возможен вариант что система берет этот код при выборке...и на нем умирает???

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

(44)
"возможен вариант что система берет этот код при выборке...и на нем умирает???"(с)

Да. Но, возможно, ОНА его не может даже "взять", т.к. этот мусор и в индексах. Сделайте реиндексацию этой таблицы, и посмотрите её средствами просмотра DBF-ов с использованием индексов. Или дайте посмотреть другим людям. ;-)

(46) а не пофиг какие символы в индексах...? допустим все ссылки прописаны правильно, но в качестве идов - строки с неалфавитными символами - будет ли это вляить?

(47)
Да. Т.к., например, порядок поступления записей при "движении" по этому индексу не соответствует операторам сравнения полей таблицы в оперативной памяти. Аналогичная проблема возникает при использовании DBF-ной базы под управлением Win7 когда в полях таблицы находятся "запредельные" символы.

а почему не соответсвует..? что-то я не втыкаю..

(49)
В индексах информации лежит в кодах "преобразованных" по специальной таблице, которая не полностью соответствует системной кодировке. Т.е. некие символы в индексах дают сравнение на больше/меньше отличное от сравнения операторами 1С-а. Ну, и совсем "весело", когда в поле таблицы влетает 0х00.

(50) Индексы бывают разные - всё зависит от типа индекса и от преобразования значения, выполняемого перед индексированием.
Для строк, 1С выполняет UpperCase(LeftChar(Value,128)), то есть в случае каши с большой вероятностью получится пустая строка, которая прекрасно индексируется, но будет нарушена уникальность (которая, насколько я помню, на низком уровне не отслеживается).
В итоге, индексация прекрасно пройдёт, только вот результат поиска по идентификатору будет местами достаточно странный.

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

Но, ТИИ каши должно проходить с ошибками, так как там проверяется и логическая целостность и допустимые символы в строках (например, символ с кодом 1 в строке не разрешён).

(51)
Всё верно. Но, маленькое дополнение.
1) ТиИ не выявит для строковых полей символы типа 0x01.
2) Пустая строка в индексе не появится, даже если в поле БД будет символ 0х00. Т.к. при использовании полей в индексном выражении используется длина поля, а не завершающий байт нулевого значения. Например, значение поля "1234"+0х00+"6789" так и будет выглядеть в индексе с нулем между 4 и 6. Но, при взятии значения поля из самого DBF-а будет значение "1234".
Т.е. полная "каша" и "странности" гарантированы... :-(

от ты побач Мыкола що навыдумляли о цы кляты москали...

(52) Символ 0x01 в некоторых строках ТИИ на этапе логической целостности видит (но в ID - точно нет).
Дальше, если строка в индекс идёт без преобразований, то символ с кодом 0x00 в середине никак не повлияет на результат индекса - просто он не будет работать в 1С (где строка заканчивается нулём).
Если же строка подвергается преобразованию какой-то функцией (например UpperCase), то всё зависит от реализации самой функции.
И, самое печальное, что функции сравнения и поиска работают по-разному в 1С, в движке dbf-драйвера и на низком уровне внутри драйвера.

В общем так:
1С.Предприятие 7.7 (версия 7.70.027)

Новая база, справочник:
    - Справочник
        - Идентификатор    "Проверка"
        - Синоним
        - Комментарий
        - Владелец
        - КоличествоУровней    "1"
        - ДлинаКода    "5"
        - ДлинаНаименования    "25"
        - СерииКодов    "ВПределахПодчинения"
        - ТипКода    "Числовой"
        - ОсновноеПредставление    "ВВидеНаименования"
        - КонтрольУникальности    "1"
        - АвтоНумерация    "2"
        - ГруппыВпереди    "1"
        - СпособРедактирования    "ВСписке"
        - ЕдинаяФормаЭлемента    "0"
        - ОсновнаяФорма    "Справочник.Проверка.ФормаСписка.ФормаСписка"
        - ОсновнаяФормаДляВыбора    "Справочник.Проверка.ФормаСписка.ФормаСписка"
        - ОбластьРаспространения    "ВсеИнформационныеБазы"
        - АвтоРегистрация    "1"
        - ДополнительныеКодыИБ
        - Реквизит
            - Идентификатор    "рстрПросто"
            - Синоним
            - Комментарий
            - Тип    "Строка"
            - Вид
            - Длина    "10"
            - Точность    "0"
            - НеОтрицательный    "0"
            - РазделятьТриады    "0"
            - Периодический    "0"
            - Сортировка    "0"
            - Отбор    "0"
            - РучноеИзменение    "1"
            - ИзменяетсяДокументами    "0"
            - Использование    "ДляЭлемента"
        - ФормаСписка
            - Идентификатор    "ФормаСписка"
            - Синоним
            - Комментарий

Обработка для записи кодов:
Процедура Выполнить()
    лспр=СоздатьОбъект("Справочник.Проверка");
    лспр.Новый();
    лспр.Наименование="Вася"+Chr(1)+"Пупкин";
    лспр.рстрПросто="Строка"+Chr(5);
    лспр.Write();
КонецПроцедуры

Выполняем ТИИ:
Файл SC12.dbf. Запись 2. Поле DESCR. Неверное содержимое текстового поля - "Вася
Пупкин              "
Файл SC12.dbf. Запись 2. Поле SP14. Неверное содержимое текстового поля - "Строка   "

Как бы система говорит, что ей не понравились символы 0x01 и 0x05 в наименовании и обычной строке (не входящей даже в индекс).

(55)
Да. Согласен. Моя оплошность.
Делал ТиИ в своей "примочке" в режиме эмуляции "родных" DBF.
http://infostart.ru/public/15211/
А в ней отключена "Проверка физической целостности".
Уже забыл про это... :-(

(56) Просто, есть подозрение, что в (0) тоже какие-то примочки стояли.
P.S. у меня в первой моей программе, где числа хранились в упакованном виде (0x01-0x7E) первое ТИИ выдало просто дофига сообщений, после чего я понял, что 1С это не VbScript и быстро и хорошо не получается.

я смотрю на дбф примерно так как описано здесь:
http://www.delphikingdom.com/asp/viewitem.asp?catalogid=624
возможно в 1с оно чуток подругому...но основной принцип...думаю сохраняется...так вот...в моем понимании это выглядит так...
есть заголовок который опысывает таблицу...  и если в каком то поле находися не тот тип даных...то система как бы не должна это индексировать их...в лучьшем случае ...орать что мол нарушена структура...судя повсему она эти записи пропускает при индексации...
каши удалось избавится после перепаковки таблиц в ТиИ.
Рузультатом стало что в отчет не попадает часть даных....скорее всего ТиИ зацепило еще какие то даные...
нужно пробовать перепровидение...
что волнует ...как это все отразится на регистре склада...

(57) Что значит примочок...если они там есть то от раруса...в остальном чистый код ...немного изменены формы ...документов ...но с этим все работало чудесно...

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

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

(58) не ссы!
1. на оригинальной базе сними кртичные остатки по складу.
2. поправь базу, перепроведи нафиг все в нормальных условиях. сделай все регламенты какие надо.
3. посмотри остатки по складу по сравнгению с п.1 - ничего разъехатьяс не должно. Если разъехалось - невязку откинь в виртуальный карман до разборок.

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

кто хочет посмотреть вот ссылка
http://euroauto.com.ua/downloads/ra442.zip

смотреть в районе 35200 записи

(64)(65)
Если смотреть эту таблицу с использованием любых индексов (кроме "служебного" IDELETED), то "мусор" располагается в начале и конце таблицы. Т.е. такое расположение "битой" информации может влиять негативно на отчеты и обновление БД в любых интервалах. А не только при обращении к информации за 2005 год, где наблюдается собственно порча DBF файла.
Вопрос, как это всё успешно работало с 2005 года...
Возможно есть еще другие "битые" таблицы. Или наблюдаемая "битость" изменилась в худшую сторону уже в настоящее время. Думаю, полезно будет глянуть на этот DBF из старой копии. Как вы говорите - "проходит она по архивам с 2009 года"(с). Их и надо посмотреть. Прикрепляйте ссылку в тему. Бум смотреть... :-)

(58)
Кстати. ;-)
1) Эти записи не исчезают при реиндексации.
2) В результате упаковки удаляется всего две записи, т.к. "битость" попала у них на признак (пометку) удаленности. А общее количество "битых" записей пара десятков. Это то, что видно глазами.

(67)
http://euroauto.com.ua/downloads/ra442_1.zip
это файл 2009 года

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

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

Сделал бы сразу это - не было бы 60 постов мозгового штурма в новогодние ночи ))))

(69)
В обоих файлах "битость" одинакова. Т.е., если это и есть ПРЯМАЯ причина "зависания" сессий с отчетами, то это должно было произойти в 2005 году. :-)
P.S.
Рекомендую посмотреть размер этой таблицы и количество записей после выгрузки/загрузки. И сравнить с исходной. Возможно, что выгрузка произошла только до "битости". Т.к. во время выгрузки тип полей и их содержание проверяется на соответствие. И, возможно, "битость" не пропускается, а алгоритм выгрузки молча ;-) завершается. Это как я ЭТО понимаю. Могу и ошибаться...

(70) сразу не получалось сделать...когда запустил ТиИ и вылезла эта фигня...и ТиИ перепаковал базу...вспомнил что не попробовал выгрузку и загрузку...

так вот каша пропала...база стала шустрее ...но при подготовке отчета снова повисла...

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

не хочется мне ось тревожить...

отчеты с рабочей и загруженой базы по остаткам плюс отчет по оборотам
за последний год сошлись

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

(72)
Дык. ;-) Зависание можно моделировать в однопользовательской среде?
Тогда высылайте мне базу с подробным описание задачи-зависания.
У меня есть возможность включить трассировку всех обращений к БД.
Думаю, проблему можно будет локализовать...

(74) Улыбнул )))
отчет виснет по разному ...иногда на выполнение запроса...а иногда на формирование табличной части ...как выглядит зависание описал вначале...

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

(76) делай как ходжик в (75) описал - получишь гарантированный ответ.

(76) какое на формирование "табличной части" - формирование самой таблицы отчета? - если виснет на этом - ну или алгоритм кривой либо проблемы вне 1С...

(75) (77) база на eurotron-овском ключе...втыкнут в лпт порт...дампа ключа нет...если отключив компоненту защиты еще можно запустить саму 1с то все функции становятся не робочими...

(78) да таблици отчета...но повторюсь...виснет на разных этапах...возможно действительно проблема не в 1с ...но в какую сторону копать ума не приложу...все что советовали пробовал..не помогло...

(0)Если " Около 3-х недель назад началось падение 1с", возьми архив месячной давности и посмотри в копии. А лучше локально. Во всяком случае можешь исключить либо 1С, либо работу терминала.

(81) собственно этим сейчас и занимаюсь

судя по всему проблема с терминалом...так что разворачиваю виртуалку

ждем вестей

(83) TEMP-директории пользователей чистили ?
И куда указывает переменная TEMP в сеансе пользователя ?
Ну и диски неплохо бы посмотреть на ошибки, а то была у меня "хорошая" машина, которая почему-то тормозила - потом пришла идея - SMART-диагностику сделать - было много ошибок поиска сектора (причём именно поиска, а чтение и запись почему-то шли на ура).

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

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

(86)
Вот тут http://forum.infostart.ru/forum9/topic96301/ (сообщения 95, 166) есть смешной тест.
Если Вы его запустите для 5-10 сессий, то это сильно нагрузит железо "особенностями" 1С.
Пропустите его на реальном сервере. Естественно, без пунктов 8, 9, 10. Т.е. проверяем только  исправность/надежность железа.

(88)
попробую ближе к 20:00 по киеву

Смарт ключа работает криво - как только обращение в ту область данных, неважно, нужна или нет - получаешь косяк. Я такое ловил даже с рабочим ключом. Ну а папуковские поделки вообще притча..

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

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

(92)
Есть варианты. ;-)
Перегрев CPU. :-(
Вы стресс тест то сделайте...

(92) если межуд 3-им и четвертым быстро перезапустить 1сину - что будет..?

(94) работает...еще два три отчета можно сделать

(93) перечитал материал по ссылке ...сейчас нет возможности запустить ваш тест в полном объеме...перед созданием темы...запускал стрес тест системы средствами евереста (проц, память, жесткий диск) тестировался  4 часа...темп процесора не поднялась выше 45градусов

(95)
1) А как меняется "загрузка" процессора и занятая память сессии 1С-а при повтором (как описано в (92) сообщении) выполнении отчетов?
2) Таки надо уйти от возможных проблем железа/ОС-а. Т.е. погонять эту базу на другом компьютере. И исключить глюки ключа. Т.е на домашнем компьютере есть же эмулятор. Ну, хоть так...

(97)
по 1 вопросу: ну как при перезапуске...сначала все ок... а на 3-4 отчете зависает. выглядит так...полностью загруженое ядро...память или остается занятой или освобождается....обращение к диску прекращается

(97)
косательно железа...
как раз вчера занялся вопросом оси и терминала...
что было сделано:
откат системы..(результат тот же)
переустановка системы .. на 2k3 sp2 32b + терминал
проблема осталась

сервер не перегрет ...нагрузка процесора еверестом..ошибок в работе не вызвала...упаковка распаковка файлов ошибок не показала...смарт ошибок не сообщяет...тестирование памяти ошибок не показало....мистика мля

после всего этого вернул систему в то состояние в котором было

(98)
Вопрос был про 1, 2, 3 ... УСПЕШНЫЕ выполнения в контексте Вашей фразы: "повторяю этот же отчет ...выборка делается медленее"(с)
(99)
Почему не делает проверку этой базы данных на ДРУГОМ компьютере?

У меня такое было когда накрылась плашка оперативки.
Заменил все и больше лаг не было!

(99) У меня такое было когда накрылась плашка оперативки.
Заменил все и больше лаг не было!
Тесты ошибок Оперативки не показывали.
Мне это здесь посоветовали и помогло, благо заначка была...

(101) (102) спасибо. завтра попробую заменить.

(100) "Вопрос был про 1, 2, 3 ... УСПЕШНЫЕ выполнения в контексте Вашей фразы: "повторяю этот же отчет ...выборка делается медленее"(с) " - не совсем понял ...что значит 1, 2, 3

"Почему не делает проверку этой базы данных на ДРУГОМ компьютере?" ...выше писал...что поставил на виртуалку...вроде база работала ...но зафиксирована перегрузка виртуальной машины...виртуалку разворачивал на домашнем ПК

(104) ну как бы другой компьютер подразумевает другое физическое устройство

(105) а чем в этом плане не подходит виртуал бокс...с развернутым на нем тем же сервером и поднятым терминалом...к которому я подключаюсь...???
На домашнем стоит вин7 ...поднимать под ней 1с ...придется менять кодовою страницу...как встанет под 7 ...вопрос...вот и выбран был виртуал бокс...

или я не прав?

(104)
"не совсем понял ...что значит 1, 2, 3"(с)
См. своё (92) сообщение.
(104)
"но зафиксирована перегрузка виртуальной машины"(с)
И этого мало для верных выводов о работоспособности реальном железе? ;-)
(106)
"а чем в этом плане не подходит виртуал бокс..."(с)
Думаю, в (105) сообщении ключевое слово "другое", а не "физическое". Как и в моём (100) сообщении. ;-)

Памяти сколько схавано при выполнении отчёта ?
Просто, возможно, что происходит фрагментация виртуальной памяти процесса, и осуществляется поиск незанятого места с выполнением перемещения блоков.
Вопрос - если сделать отчёт, потом подождать, пока память не освободят, и снова сделать отчёт ?
Кстати, когда кончается память - 1C вылетает.

(108) в зависимости от отчета ...но в среднем от 60 до 140 мб
...попробую подготовить вашим методом...
ситуацию с тем что память кончается наблюдал ...был случай..

(109) ты бы все-таки запстился ан ДРУГОМ ФИЗИЧЕСКОМ устройстве.
а то как будто глухой...

(110)
Сергей. Вроде, я понял. ;-)
В (104) написано: "виртуалку разворачивал на домашнем ПК"(с)
Т.е. использовалось ДРУГОЕ железо. И написано: "вроде база работала"(с).
И если не очень ;-) обращать внимание на: "зафиксирована перегрузка виртуальной машины"(с), то можно сделать однозначный вывод. Сервер терминалов (реальное железо) не работает, а база данных и 1С - работает. Чего и было сказано в прошлом году. :-)

(0) А ибо нефиХ нажимать, - "Сохранить как...", и выбирать при этом формат Ексель :)
1С 7.7 не умеет сохранять МХЛ формат в Екселе без подвисаний :)

(112) улыбнул))

(111) да нет...вчерашняя ситуация недает мне покоя...
...сегодня перенастроил виртуалбокс... чтоб система не падала...проблема в 1с повторилась

так что это не железо...

ребята меня терзают сомнения...поделитесь кто-может провереным распакованым дистрибутивом 7.0.27

(116) а тут-то что может быть не так....
Вот уж где проблема мало вероятна, так это в самом ядре....

(114)
Чего "перенастроил виртуалбокс" ?

вроде нашел причину завтра проверю...вроде проблема в области ключа...или лпт порта

(118) в виртуалке сменил контролер и чипсет

ждем вестей с передовой

(0)
"Около 3-х недель назад началось падение 1с при подготовке отчетов."(с)

Возможно я упустил чего в теме. Но...
Делалось ли (для исключения причины проблемы в порче базы данных) тестирование "проблемными" отчетами базы данных развернутой из копии месячной давности?

ну и что насоватовали ?

(0)
+122
Точнее, не "порча" базы, а влияние её теперешнего "состояния" на появление проблемы.

(0)
+122
А если проблема не проявится, то накатить на "старую" базу данных конфигурацию из "текущей" базы и гонять тесты дальше. ;-) Т.е. это, если уже появились подозрения из (116) сообщения.

НУ что какие новости с передовой....

видать капец

Для начала хочу поздравить всех участников с Рождеством Христовым и пожелать мира, здоровья и достатка Вам и Вашим семьям!!!

(122) об этом и писал в (80), (81)

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

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

Помню из недалекого прошлого подобное, все дело было в нехватке ОЗУ на сервере

(132) да нет с оперативкой все ок...проверено по всем пунктам (нехватка, ошибки, замена)

(129)
"об этом и писал в (80), (81)"(с)
Написали вот это: "собственно этим сейчас и занимаюсь" ?
А про результат занятий где написано? :-)
(130)
Ну, т.е. три недели назад сломался ключ. Два ключа разом!!! С одинаковым проявлением поломки. На разных компьютерах. Да?
НЕ БЫВАЕТ ТАКОГО.
Причина - в содержании базы данных, которое "конфликтует" с алгоритмами работы с ключом. Т.е. Вы пытаетесь "поймать" следствие, а не причину... :-(

(131)
P.S. к (134) сообщению.
На мой взгляд - ЧТО надо сделать:
1) Дать четкий ответ на (122) сообщение.
2) Развернуть и проверить базу данных на домашнем компьютере под управлением его реальной ОС (без VM и "сервера терминалов").
3) Сделать трассировку (краткую, режим=1) с помощью http://infostart.ru/public/16268/ и выслать мне журналы *.log вместе с файлом *.DD.

Хочу сказать всем спасибо кто принял участие в обсуждение проблемы. Проблема успешно решена. Проблема оказалась в роботе ЛПТ порта. После устранения проблемы с лпт... все работает на УРА как и раньше.Всем еще раз большое спасибо! тему можно закрывать