Запуск Process Monitor заставляет приложение работать

Question

Это длинный пример, но, возможно, кто-то со знанием внутренней работы Process Monitor Sysinternal может иметь идею.

Недавно у нас была очень мутная проблема на работе. У нас есть программное обеспечение (назовите его SW1), которое создает сокет-соединение на определенном порту с другим программным обеспечением (назовите его SW2) и получает некоторые данные от этого программного обеспечения. Затем он создает другое сокет-соединение с другим принадлежащим ему процессом и отправляет ему некоторые данные, после чего цикл перезапускается, и он начинает получать дополнительные данные от SW2.

Это очень расплывчатое описание, и я не имею ничего общего ни с одним из этих приложений, однако, как владелец рабочих станций, я активно участвовал в поддержке. Вся эта система работала без каких-либо помех на одной конкретной рабочей станции, однако отказалась работать на четырех других идентичных рабочих станциях. Симптомом была внезапная остановка пакетов, отправляемых между двумя собственными процессами SW1, за которыми естественно последовал тайм-аут SW2.

Теперь немного странно: после нескольких недель отладки с соответствующими командами и запуска Wireshark, я решил запустить Process Monitor, возможно, что-то появится. Как ни странно, сокетные соединения остались установленными и все работало! Думая, что это было совпадением, мы попытались запустить монитор процессов на остальных трех, и все они начали работать. Кроме того, похоже, что перезагрузка все еще поддерживает работу приложений.

Конечно, остается вопрос: какое влияние Process Monitor может оказать на эти приложения? Из-за природы решения я не могу проанализировать захват procmon, так как кажется, что он решает проблему ...

Спасибо!

Answer 1

Это звучит как состояние гонки или тупик.

Т.е.: SW1 и SW2 должны иметь протокол связи с запросами и подтверждениями. Если этот протокол не разработан должным образом, может возникнуть состояние гонки, при котором пакеты не отправляются в правильном порядке. SW1 получает стек в ожидании пакета от SW2, но который SW2 уже отправил в прошлом (и SW1 пропустил его), и SW2 не собирается отправлять его снова, переходя в состояние блокировки на SW1.

В этом случае сбой зависит от скорости выполнения SW1 и SW2 и, более того, от нагрузки на серверы. Допустим, если оба процесса выполняются медленно, более сложно, чтобы SW1 пропустил пакет из SW2, который создает состояние блокировки. Запуск системного монитора немного замедляет работу всей системы, что может быть достаточно для этой работы.

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