О, сколько нам открытий чудных готовит COM STA-дедлок

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

На просторах мне не удалось обнаружить каких-либо упоминаний об этой проблеме, вскользь лишь исследователь Joe Duffy писал об этом в своем блоге. Еще косвенно было упоминание вот на этой google-борде. Отсутствие упоминаний об этом явлении должно говорить о околонулевой ценности исследования, но статья сама себя не напишет.

Речь пойдет об очень необычной причине дедлока GUI-потока в оконных приложениях .NET – WinForms и WPF. Когда такое приложение виснет намертво, разработчик ищет причину там, где привык: в собственных локах, в гонке между своими потоками, в неудачном lock или забытом .Wait(). Он перетряхивает свой код — и нередко не находит ничего криминального. Потому что причина лежит не этажом ниже, чем он смотрит, и даже не в подвале: в механизме, который он не писал, не видит и с которым, как ему кажется, вообще не работает.

Если вы работаете с WinForms/WPF, то вы наверняка знаете, что весь GUI-стек построен на однопоточной модели COM —  Single-threaded apartments: буфер обмена, drag-drop, общие диалоги, shell-интеграция, OLE — всё это STA-компоненты.

У WinForms сгенерированная точка входа Main имеет явный атрибут [STAThread] (видно прямо в шаблоне), у WPF точка входа генерируется автоматически и тоже имеет атрибут [STAThread].

Так вот, именно эта модель, точнее, тот самый однопоточный апартамент (STA) с обработкой оконных сообщений, на котором незаметно для всех стоит GUI-поток любого WinForms- и WPF-приложения. Дедлок, выглядящий как баг async/await, на деле — тридцатилетняя машина COM, заглохшая под капотом.

Что скрывает COM за реализацией однопоточной модели STA? Собака, как оказалась, порылась весьма в интересном месте.

Абсолютно любой вызов CoInitializeEx() влечет за собой создание невидимого окна с классом «OleMainThreadWndClass». Казалось бы, зачем COM создавать окна и тем более работать с ними? Исторически дело обстояло так. Сначала появилась технология OLE 1.0 (начало 90-х) — компаундные документы, и его механизм межпроцессного взаимодействия IPC был буквально построен на DDE – Dynamic Data Exchange, то есть на оконных сообщениях (WM_DDE_*), что позволяло одной программе запрашивать данные у другой. Потом под OLE 2.0 в 1993 году Microsoft переписала всё на новый объектный слой — COM, заменив DDE нормальным (интересно, в каком месте он нормальный – прим. моё) маршалингом. И для обратной совместимости с OLE-компонентами оставили в COM оставили работу с окнами. И да, забегая вперед скажу, что где-то очень глубоко в недрах COM сидит обработка DDE-сообщений из начала 90-х.

Но обо всем по порядку.

Вызов CoInitializeEx() активирует цепочку вызовов API ThreadFirstInitialize() -> RegisterOleWndClass(), которая, как я писал, создает скрытое окно с классом «OleMainThreadWndClass». Внутри OleMainThreadWndProc нашлось неожиданно мало. Я ожидал увидеть диспетчер вызовов. Но его там не оказалось — сама процедура есть, а вот диспетчеризации в ней нет: внутри есть обработка только трех типов сообщений — на WM_CLOSE и WM_DESTROY процедура лишь пишет трассировку и возвращает ноль — окно даже не сносится, всё сводится к логированию и защите времени жизни. На приватном WM_USER+5 она через GetSingleThreadedHost отдаёт указатель на host-объект апартамента. Остальное уходит в DefWindowProcW. И все. Тупик.

Ладно, пойдем с другой стороны. В Ghydra задизасмил вызов того, что STA-поток реально вызывает, когда находится в режиме ожидания: функции CoWaitForMultipleHandles. И все сложилось: CoWaitForMultipleHandles() дергает ClassicSTAThreadWaitForHandles(), а та в свою очередь создает «клиентский» цикл CCliModalLoop::BlockFn(), где видны вызовы:

— InitChannelIfNecessary — API поднимает RPC-канал: входящий вызов едет по LPC, а не «сообщением в окно»;

— API MsgWaitForMultipleObjectsEx — спим до срабатывания хэндла или прихода сообщения в очередь (!);

 — PeekRPCAndDDEMessage выгребает из очереди именно RPC- и DDE- сообщения.

Итого имеем: вызов приходит по LPC, но его доставка вплетена в очередь сообщений, и модальный цикл достаёт её, пока поток ждёт.

Я думал это дно, но тут снизу постучали.

Вызов PeekRPCAndDDEMessage через обертку CCliModalLoop::MyPeekMessage дергает PeekMessageW (PM_REMOVE) + DispatchMessageW, ровно те же два вызова, как в любом учебнике while (GetMessage()) DispatchMessage() любого GUI.

И где здесь засада, спросишь ты?

Этот цикл PeekMessage/DispatchMessage — ты привык считать «своим», родным: он организует обработку кликов, перерисовок, ввода. И это тот же цикл, которым COM доставляет входящие вызовы, а async — свои продолжения.

Одна очередь, один поток, одна пара вызовов на всех. И — две ловушки, обе из того, что цикл обработки сообщений общая.

Заблокируешь его вызовами .Result, .Wait(), lock, тяжёлым расчётом — и ты не просто «подвесил UI на секунду», ты остановил единственный механизм, которым к тебе придёт тот самый результат, которого ты ждёшь, ждёшь ответа по каналу, который сам же и заглушил.

Запустишь цикл обработки сообщений не там, где надо — Application.DoEvents(), модальный диалог, MessageBox, да хоть обычный await — и цикл посреди твоего кода вытащит из очереди следующее сообщение и продиспетчерит его. Твой обработчик войдёт повторно, пока первый ещё на стеке: клик поверх клика, таймер поверх обработчика, COM-callback поверх метода. И пошло, поехало…

Те же два вызова, которым учат на первом уроке по Win32, под капотом оказываются транспортом и COM, и async, там где-то окаменелом 30-летнем наследстве от OLE — в простой обработке оконных сообщений, которая на первый взгляд выглядит безобидной.

Что это значит на практике?

Вам не нужно «работать с COM», чтобы влететь в COM STA-дедлок. Если вы в UI-потоке .NET — вы уже на COM STA. А STA-поток обязан непрерывно обрабатывать очередь сообщений; стоит ему заблокироваться — обработка прекращается, и входящий вызов не доставляется.

Что делать?

Не парковать UI-поток на асинхронной операции или тяжелых вычислениях. Его единственная работа, которая не должна прерываться, крутить цикл сообщений. А как это сделать, решать уже вам.