Идеи отладки для заблокированного цикла сообщений Windows - PullRequest
Новая
       1

Идеи отладки для заблокированного цикла сообщений Windows

4 голосов
/ 12 октября 2010

У меня давнее "зависание" приложения C # .NET 3.5, с которым я в затруднении.Есть два исполняемых файла C #.Один имеет полный пользовательский интерфейс, другой работает как приложение в трее.Они оба общаются через WCF с третьим сервисным приложением, также запущенным в трее.

Случайно поток пользовательского интерфейса основного приложения Winforms блокируется.Таинственным образом, если я выйду из приложения в трее, пользовательский интерфейс этого приложения будет разблокирован.

Всякий раз, когда я присоединяю отладчик к любому из приложений, я не узнаю ничего полезного.Поток пользовательского интерфейса заблокирован в замороженном приложении по методу Application.Run.Все остальные потоки либо спят, либо блокируются при вызове в поток пользовательского интерфейса.

Также таинственным образом другое работающее приложение, такое как Photoshop, будет вести себя странно, пока существует этот тупик.Выход из приложения в трее также сортирует это.

Все, что я могу сделать вывод, это то, что что-то не так с основным насосом сообщений на уровне Windows, но я не совсем понимаю, как я могу отлаживать дальше в этом.Я установил исходный код платформы и вижу, что заблокированное приложение застряло в цикле while в:

Application.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop

но не 'Я действительно достаточно понимаю, чтобы что-то делать с этой информацией.

У кого-нибудь есть какие-либо советы относительно того, куда смотреть дальше?Я преследовал эту случайную тупиковую ошибку в течение нескольких месяцев.

Спасибо, Ник

1 Ответ

2 голосов
/ 12 октября 2010

Я думаю, что это может быть красная сельдь, так как она в Visual Studio SDK, так что на самом деле ваша отладка зависает.

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

Вот несколько советов от меня:

1) По пути вы увидите несколько красных сельдей, так что будьте осторожны, чтобы не зацепиться за них и не спутать проявления проблемы с самой причиной.

2) Каковы сроки этого замораживания? Сколько времени это занимает? Время ожидания соединения TCP обычно составляет 23 секунды, в то время как время ожидания соединения с базой данных составляет 30 секунд, а команда - 120 секунд (может отличаться в зависимости от настроек), поэтому время, которое требуется, является большой подсказкой. Если он не разрешается сам по себе, и вам необходимо закрыть одно приложение, чтобы избавиться от него, это почти наверняка тупик потока или базы данных.

3) Используйте sysinternal Process Explorer и Process Monitor, чтобы увидеть, что они делают и в какой момент они останавливаются. Последнее священство может дать вам подсказку не всегда.

4) Я знаю, что это займет какое-то время, но начните писать трассировку в своем коде, чтобы найти точное местоположение проблемы, и с тех пор, как правило, поиск проблемы занимает несколько часов.

5) Если у вас есть дополнительная информация, задайте другой вопрос и дайте мне знать.

...