Доброго всем!
Столкнулся с проблемой, идеи кончились. Может кто сталкивался с похожим или просто предложит что-то попробовать еще.

Документооборот 2.1.11 сильно кастомизированный. Платформа 8.3.16.1063. Клиент-сервер, MS SQL. Проблема наблюдается только у одного пользователя.
При попытке открыть список входящих документов 1С зависает. Крутит колесо, и ничего не происходит. В диспетчере задач приложение с надписью "Не отвечает". При снятии задачи сеанс не отваливается, приходится отключать через консоль.
Другие списки документов (внутренние, исходящие) открываются. У других пользователей список входящих документов открывается. Через "Мои документы" можно открыть "свой" входящий документ. Если в нем через "Еще" выбрать "показать в списке" - снова зависает.
На копии базы - проблема НЕ повторяется. Если на рабочей заходить под пользователем с другой рабочей станции - проблема ЕСТЬ.
Кэш пользователю чистил полностью, перегружал. Оставляли на ночь - не помогало. Настройки пользователя в 1С очистил полностью - результат не меняется.

Если бы проблема оставалась на копии - искал бы проблему в данных, правах и т.п. В справочнике "Входящие документы" 50+ тыс. записей. Но на копии проблем нет. Куда еще можно посмотреть?
---
Если на копии базы проблемы нет, то кэш и очистка настроек обычно помогает.

У меня было такое, что время от времени определенный список у определенного пользователя переставал открываться с такими же симптомами. Лечилось чисткой настроек формы этого списка.
---
В итоге пока оставили так. Пользователю работать надо, поэкспериментировать на рабочей особо не дают, да и не очень хочется.
Причина осталась непонятной. Наибольшие подозрения на изменение настроек пользователя + права доступа - в базе много "мусора", дескрипторов доступа десятки тысяч, пересчет долгой очереди длится около двух часов. И как раз, когда все началось, этот пересчет запускался, то есть права доступа менялись. А на копии, соответственно, эти процедуры не отрабатывались.

Поскольку сброс настроек пользователя в итоге привел к возможности пользователю работать - помечаю как решение.
---
под пользователем зайти сделать замер времени. В режиме конфигуратора запустить отладку на рабочей и запустить замер времени или стек вызовов
---
1. Завести нового пользователя.
2. Копия файловая? Если да то смотреть RLS.
3. Будь мужиком, отладкой посмотри где проблемы
---
Если проблема в правах, то отладка ничего не даст. И замер производительности просто покажет, что форма долго открывается.
---
(3) На рабочем сервере не могу включить отладку. На тестовом - проблема не наблюдается.
Копия также клиент-сервер.
---
Если на копии базы проблемы нет, то кэш и очистка настроек обычно помогает.

У меня было такое, что время от времени определенный список у определенного пользователя переставал открываться с такими же симптомами. Лечилось чисткой настроек формы этого списка.
---
возможно у пользователя индивидуальная настройка списка документов. Колонку дополнительную указал, и эта колонка много ресурсов забирает.
---
Я посмотрю на копии, что там. До этого не изучал сам список. Но на рабочей никаких лишних колонок не должно быть.
Так настройки теперь выглядят на рабочей. Я правильно понимаю, что все индивидуальные отборы/колонки и прочее таким подходом убираются?
---
Очистка настроек все вернет к первоначальному виду. Вы писали, что чистили настройки.
---
технологический журнал разверните
---
О! Открылся список на рабочей! После полной чистки настроек. Я окно "бросил", пошел тему создавать. Больше часа открывался, но открыл в итоге.
Поставил фильтр на документы последнего месяца - открылся нормально, без заметных тормозов. Снял фильтр - опять встала в ступор.
Ну хотя бы локализовалась проблема и пользователя можно запустить. Дождусь когда откроет, верну фильтр и пойду проверять как на рабочей станции пользователя отработает.

Рабочий сервер приложений выпрашивает перезагрузку?
---
Рабочий сервер приложений выпрашивает перезагрузку?
Нет, не обязательно перезагружать
---
В итоге пока оставили так. Пользователю работать надо, поэкспериментировать на рабочей особо не дают, да и не очень хочется.
Причина осталась непонятной. Наибольшие подозрения на изменение настроек пользователя + права доступа - в базе много "мусора", дескрипторов доступа десятки тысяч, пересчет долгой очереди длится около двух часов. И как раз, когда все началось, этот пересчет запускался, то есть права доступа менялись. А на копии, соответственно, эти процедуры не отрабатывались.

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