Регулярное падение AOS-в в AX3.0

[snirk]

Доброго времени суток!

AX3.0 SP2 без Kernel Rollup
СУБД - MS SQL Server2000 SP4
2 AOS в кластере, один из них крутится на той же машине, где лежит приложение, другой - на отдельном сервере.
Везде MS Windows Server 2003

Суть проблемы:
Достаточно давно (несколько лет) такая конфигурация нормально, стабильно работала, но вот вот пару месяцев назад начались регулярные, практически ежедневные падания AOS-ов.

Внешние проявления: сначала отваливается один AOS (в разном порядке), затем другой. Отваливается, значит не дает пользователям входить в Axapta пишет что-то вроде "...Kernel mismatch...". Это происходит практически ежедневно в районе 7:30 - 9:00 утра. По выходным бывает и не отваливается.

Прочая информация:
На том же приложении крутятся AOS-ы для других баз данных - они не падают.
Полностью аналогичное приложение + другая БД + другие АОСЫ - не падало вообще ни разу.

Раскопки:
В системных логах после падения постоянно висят записи типа:

Event Type: Error
Event Source: Axapta Object Server
Event Category: None
Event ID: 117
Date: 11.05.2011
Time: 8:21:13
User: N/A
Computer: -----
Description:
Object Server -------: The database reported (session 131 (------)): [Navision Axapta] Unable to retrieve message for retval -1, ODBC call reason code 100,
SQLSTATE =
[њ';%WЊH]
Error message []. The SQL statement was: "SELECT A.ID,A.NAME, __тут список всех полей таблицы USERINFO____,A.COMPILERWARNINGLEVEL,A.RECID FROM USERINFO A(INDEX(I_65531ID) NOLOCK) WHERE ((ID IN (?,?,?,?,?, ___тут ну очень много вопросиков___,?,?,?,?,?) ) AND (ID=?)) OPTION(FAST 2)"

Совершенно не понятно, является ли это причиной падения AOS или следствием. Что это за ошибка, можно почитать тут Проблема с ODBC?, но почему она возникает? Если посмотреть профайл, то при нормальном входе в систему запрос выглядит так:
SELECT A.ID,A.NAME,………..A.COMPILERWARNINGLEVEL,A.RECID FROM USERINFO A(INDEX(I_65531ID) NOLOCK) WHERE (ID=?) OPTION(FAST 2)
ни о каком (ID IN (?,?,?,?,?, ___тут ну очень много вопросиков___,?,?,?,?,?) нету и речи.

Также для некоторых процессов SQL в момент (или до, или после) падения выделяются SPID с номером 65535, причем это не один и тот же процесс или пользователь, да и видно их не всегда (но может успевают завершиться).

пинговали сервер БД с сервера АОСа (который вместе с приложением) - обрыва связи в мамент падения не было.

Пробовали:
- Утреннее время, а также (иногда) отсутствие проблемы по выходным навело на мысль, что это дело рук пользователей (явно неумышленное) - внесли ip-шники всех серверов имеющих отношение к Axapta или БД в список исключений (хотя сисадмины ручались, что и так никто их не перехватывал) - помогло(!) но на пару дней (может просто выходные), потом ситуация повторилась.
- Полная перекомпиляция приложения
- Рестарт всех серверов
Не помогло. Сегодня АОСЫ упали опять.

Собственно вопрос, основной:
1. Почему падают АОСы и как сделать так, чтобы они не падали?

Дополнительный:
2. Почему при входе в систему генерируется такой запрос (с IN и много параметров)? В этом месте явно никто ничего руками не ковырял.

Почему падают АОСы и как сделать так, чтобы они не падали? Это даже не вопрос, а просто крик о помощи!!! Еще немного, и в обязанности программистов внесут ежедневный рестарт АОСов и это войдет в нормальную практику. А очень не хочется.

Заранее спасибо всем, кто откликнется.