Критическая ошибка при выполнении системных алгоритмов ...

[Blind_Orog]

thor
локальных ехе 20 штук, используется 26 баз, сегодня перестроим на один ехе.
старых ехе нет потому, как до обновления был старый вид меню в ЗП, сейчас на всех машинах новый.

[edward_K]

внешнего вида мало. Например в патчах советовали убрать GalStub.dll(он должен быть в подпапке), vip.exe(в сапорт) из Exe. Да о отчеты о рабочей станции не мешает сравнить.

[Blind_Orog]

GalStub.dll и vip.exe убрали.
настроили всех на один exe, проблема осталась...

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

[KATZ]

Может, с другой стороны зайти? Тут прозвучала масса советов, но никто не пояснил, что конкретно означает

Критическая ошибка при выполнении системных алгоритмов загрузки!

и в ответ на какое событие "Галактика" так реагирует. Без понимания сути все советы похожи на тыканье вслепую, а некоторые (типа убрать VIP.EXE из "Галактики" в "Support") даже улыбку вызывают.
Как я понимаю, разработчиков в этой теме Sniper представляет. Давайте дружно попросим его разъяснить, что происходит. Будет ясен внутренний механизм ошибки - станет понятно, как с ней бороться.

P. S. Мы пока с такой ошибкой не сталкивались (поворачивает голову влево и 33 раза сплевывает через плечо), но хотелось бы встретить ее во всеоружии.

[edward_K]

если эта таже ошибка, что возникала на 15-17 атлантисе, то она связана с изменением механизма защиты -почему и советуют проверить все ли нормально с exe и избавится от мусора там - дабы иметь возможность врубить проверку при запуске - возможно какая то dll не обновилась. В ТП поинтересутесь содержанием пира, что я писал раньше. Закономерность можно было бы отловить по журналу событий или по обычномк журналу - всего то нужно засечь время первого обращения, и еще можно посмотреть логи сервера - что-то там писалось в этот момент вроде.

[Blind_Orog]

edward_K
ЕХЕ обновили до патчей 14.10.2009 (уже 3 попытка по счету).
перестроили всех на 1 ехе.
перенастроили всех на 1 ключ ТП, который поставили на другую машину (думали проблема с лицензией ключа или dll).
отключали (и даже сносили) антивирусник.
ничего не помогло...

еще можно посмотреть логи сервера - что-то там писалось в этот момент вроде

енто где конкретно?

[edward_K]

еще и на разных ключах были.
А вообще сапорт то есть? вы писали, что им не пользуетесь.
Мой комп - правая кнопка - управление компом - журналы событий - что админы об этом не знают? Ну на первасиве я бы еще снес x$resource.adf(если нет настроенных рабочих мест или еще чего то - ну хотя бы для теста), на остальных системах советуют его из журнализации нафиг. Почикать журнал, dsk, tmp*.tmp (это может влиять на быстродействие сервера).
В марте у одного клиента в момент возникновения ошибки было "На сервере много сообщений, что HwServ не смог удалить файлы". После этого руками чистили каталог обмена, перегружали сервак (ключ на том же серваке что и база(оракл) и exe), все работало какое то время(неделю, другую), потом снова начиналась бодяга. Замечено было еще что такое могло начаться при принудительном отрубании пользователей от системы(вроде средствами оракла - не помню ужо как они это делали). В мае поставили патчи и вроде такого давно нет.
Но новые патчи они пока не ставили. Ошибка прояввляетя не у всех - как то очень выборочно. Еще что-то подобное у них же было сразу после конвертации, но уже не помню как лечили- вроде chkora прогоняли и права перерасчитывали. А то было 3 минуты ничего не делаешь - потом ошибка(вроде аналогичная - давно было). Ну и слегка cfg подправлял - частоту опроса ключа уменьшал и что-то еще.
Ищите все логи - мож что интересное найдете. А ТП что говорит? (я то не ТП ). Все таки - поймайте событие после которого все началось.

[Blind_Orog]

Логи отправили в ТП, посмотрим что скажут.

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

Почикать журнал, dsk, tmp*.tmp (это может влиять на быстродействие сервера).

dsk, tmp (да и вообще все временное) чистили, журнал не используется.

[Seybukan]

Без понимания сути все советы похожи на тыканье вслепую, а некоторые (типа убрать VIP.EXE из "Галактики" в "Support") даже улыбку вызывают.

К теме о том на каком уровне ошибка?
Я рассчитывал загрузку ЖР по 103.3.
Алгоритм 103 является системным!
Спрашивается в нем ошибка или в системе Атлантис или еще в какой-то системе.
Ошибка возникла один раз, но у меня дебаговый Mn_Plan в нем собстевнно и лежит алгоритм.

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

[Blind_Orog]

2all
Причина возникновения ошибки найдена!
Нельзя подключать БД локально и по сети одновременно!!!

Для понимания опишу конфигурацию, и так...

Имеется БД на PSQL, доступная локально и по сети.
Имеем 2 galnet.cfg
1. DataBase.DataBaseName=D:\GAL810\Data\
2. DataBase.DataBaseName=\\buh\GAL810\Data\

Если 1 пользователь находиться в БД один, то все нормально. Как только подключается 2 пользователь у 1 начинает валится ошибка.
Если оба файла galnet.cfg привести к виду
DataBase.DataBaseName=\\buh\GAL810\Data\
все работает нормально.

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

[empyros]

Не может быть!
Это в ТП такое сказали? И это помогло???

[KATZ]

Причина возникновения ошибки найдена!

Не может быть!

Что-то мне тоже сомнительно. Путь к БД по-всякому писать приходилось, и через сетевой диск, и через UNC, а когда на самом сервере иной раз "Галактику" или "Support" запускаешь - БД получается на локальном диске. И все эти варианты, а также их сочетания, нормально работали. Может, поторопились вы с диагнозом?

[Blind_Orog]

empyros

Это в ТП такое сказали?

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

KATZ

Что-то мне тоже сомнительно. Путь к БД по-всякому писать приходилось, и через сетевой диск, и через UNC, а когда на самом сервере иной раз "Галактику" или "Support" запускаешь - БД получается на локальном диске. И все эти варианты, а также их сочетания, нормально работали.

В том то и прикол, что до обновления все так и работало!!!
Сейчас работает только по сети.

Может, поторопились вы с диагнозом?

Я 4 дня потратил на то, чтобы решить проблему! Перепробовали все, даже отключали абсолютно все доработки. Отчеты о системе корректы, но проблема оставалась, пока не перестроили пути на БД.

[Friendlyman]

Столкнулись с подобной проблемой.
Ситуация: обучение пользователей, 10 локальных БД Pervasive, один на всех ключ, одна на всех лицензия. Ошибка один-в-один как у топикстартера. Проблема оказалась в том, что все локальные БД названы одинаково и располагаются по одинаковому пути, возможно и пользователи одинаково назывались. Ключ или сервер ключа офигевают от одноимённости и не способны корректно работать, даже при двух пользователях. В описании проблемы взял по максимуму (одинаковые пути, одинаковые пользователи). Возможно для возникновения проблемы достаточно и того чтобы последний сегмент пути DATA назывался одинаково.