Не так давно в одной конторе пришлось наблюдать любопытную ситуацию. Иногда в течение дня база оказывалась заблокированной на несколько минут. В моем случае я видел, что в течение 10 минут никто не мог создавать и проводить документы. При этом сервер был загружен процентов на 30. Т.е. очень не похоже на ситуацию, что множество конкурирующих пользователей полностью съедают процессор и не дают процессу, проводящему документ, нормально отработать. При этом конфигурация была переделана, чтобы ожидание на блокировоках не занимало время процессора.
Изучение логов не выявило никаких длительно проводящихся документов. Вернее, документы с достаточно большим временем проведения таки были (например, документы, проводящиеся задним числом), но они никак не могли проводится десять минут. Внимательное изучение логов в процессе проверки нескольких возможных гипотез выявило аномального пользователя. У этого пользователя за день обнаружилось две записи о входе в систему и ни одной записи о выходе. Время последнего его действия после первого входа как приходилось на время начала массовых проблем с проведением. Время его второго входа оказалось лишь на две минуты позже момента, когда проблемы с проведением прекратились. Совершенно логично предположить, что у данного пользователя вылетела программа. И причем в момент проведения документа. При этом пока пользователь не вошел повторно, у всех были проблемы с проведением.
Эти данные практически полностью выявили проблему. Осталось подтвердить все экспериментально. Была создана простейшая пустая конфигурация с одним видом документов. В глобальный модуль добавлена загрузка внешней компоненты, в которую был внесен код, вызывающий падение 1С. В базу данных был произведен вход двумя пользователями одновременно. В сеансе первого пользователя в модуле проведения был вызван код, приведший к падению 1С. При этом отобразился стандартный диалог операционной системы об ошибке в приложении. Так вот, ПОКА ЭТОТ ДИАЛОГ НЕ БЫЛ ЗАКРЫТ, второй пользователь не мог проводить документы. Как только диалог был закрыт, возможность проведения документов появилась. Т.е. наблюдается полная аналогия с модальными диалогами в модуле проведения документа.
Теперь остается только выявить виновника вылетов. Скорее всего, это 1С++, т.к. вылеты наблюдаются с ошибкой в модуле basic.dll. Возможно, более новая версия будет более стабильна. Иначе останется только делать частный билд и выкидывать из нее весь грязный код, связанный с патчами, хаками и хуками.
Вообще, если виновника вылетов найти не удается, всегда есть возможность временного решения проблемы блокировок. Например, можно включить автоматическое создание дампов приложения и отправку отчета в Microsoft. Выдачу диалогов об ошибке можно в таком случае отключить через “gpedit.msc” – «Административные шаблоны» – «Система» – «Отчет об ошибках». Правда, вряд ли Microsoft обрадуют десятки дампов в день о вылетах одного приложения. А уж если все одинэсники на территории бывшего СССР такой режим включат... Microsoft'у придется закрываться, это точно.
Еще есть возможность полностью исключить выдачу каких-либо соощений о крашах. Рецепт найден здесь: 
http://stackoverflow.com/questions/396369/how-do-i-disable-the-debug-close-application-dialog-on-windows-vista. Он заключается в том, что мы создаем совершенно тривиальную внешнюю компоненту, в которой выполняем следующий код:
В этом случае при вылете 1С не происходит вообще ничего. Программа молча закрывается (как при обычном stack overflow) и все блокировки базы отваливаются. Но и, к сожалению, никаких записей в журнал событий тоже не делается. Так что способ этот на любителя. Только если совсем припекло.
Еще вспоминается программа drwatson32, которая была в старых версия Windows и аналогично делала краш-дампы упавшего приложения, но, вроде бы, без отправки в Microsoft. Возможно, стоит покопать в этом направлении... Тогда, может от диалогов получится избавиться и записи в логе будут создаваться.
Ссылок на эту страницу нет
http://www.1cpp.ru/forum/YaBB.pl?num=1258550147/0