У нас есть заказчик, который предоставил нам сервер Windows 2012 Hyper-V с гостевой ОС Windows 2012 Multipoint, на которой мы запускаем наши программные продукты на базе .NET (v3.5).
К сожалению, есть ряд машин, на которых наши службы Windows не запускаются. Каждый из них пишет в журнал прежде всего, например:
<DllImport("Kernel32.dll", _
SetLastError:=True, _
CharSet:=CharSet.Unicode, _
entrypoint:="OutputDebugString", _
CallingConvention:=CallingConvention.StdCall)> _
Public Shared Sub OutputDebugString(ByVal str As String)
End Sub
Protected Overrides Sub OnStart(ByVal args() As String)
OutputDebugString("Service is starting...")
m_worker = New Thread(AddressOf serviceThread)
m_worker.Start()
End Sub
'...
Проблема в том, что эта отладочная строка никогда не попадает в Dbgview, и при этом программа не использует какой-либо ЦП (он всегда находится на 0%, и служба в конечном итоге истекает по таймауту.
У нас есть переключатель, который мы можем добавить к службе, чтобы иметь возможность запускать ее как приложение WinForms для тестирования таких вещей, когда я пытаюсь запустить его с этим переключателем, программе требуется около 2 минут, чтобы добраться до первой строки и вывести эта строка отладки, поэтому неудивительно, что служба не запустилась !!
Я включил Fusion, и он отлично генерирует журналы слияния, и, похоже, никаких ошибок нет, но я не понимаю, почему этим .NET-приложениям требуется так много времени, чтобы добраться до нашей базы кода?
У нас есть много других клиентов (хотя ни один из них не использует Windows 2012), и это происходит только на нескольких машинах. Число зависимых сборок не превышает дюжины, а все приложение занимает менее 4 МБ.
Может ли кто-нибудь подсказать, как исследовать это дальше ..?
Средство просмотра событий кажется пустым, за исключением «Служба не ответила на запрос запуска или управления своевременно.» ..?
Гостевая спецификация - 4 ЦП и 4 ГБ ОЗУ, на жестком диске достаточно места.
ОБНОВИТЬ: Как ни странно, проблема, кажется, исчезает, когда к машине подключено интернет-соединение ?? Теперь нашему программному обеспечению это не требуется (поскольку мы предполагаем, что оно работает на сайте без доступа), но, возможно, необходимо выполнить некоторые проверки лицензирования или групповую политику, которая полагается на сервер, которого нет в нашей сети. ? (Они действительно дали нам клон машины из своей лаборатории). Любые идеи?
Обычно это вызвано попыткой .Net Framework проверить подписи на всех загружаемых вами сборках. Microsoft имеет несколько КБ и блог сообщения по этой теме, и краткий ответ заключается в том, что вы можете отключить его в machine.config или в приложении config файл:
<configuration>
<runtime>
<generatePublisherEvidence enabled="false"/>
</runtime>
</configuration>
Длинный ответ красиво объяснил Шонфа:
Когда среда CLR загружает сборку с подписью Authenticode, она всегда пытается проверить эту подпись. В этом отличие от загрузчика Windows, который проверяет подпись файла только в определенных случаях, например, когда файл является элементом управления ActiveX. Эта проверка может занять довольно много времени, поскольку может потребоваться несколько попыток подключения к сети для загрузки обновленных списков отзыва сертификатов, а также для обеспечения наличия полной цепочки действующих сертификатов на пути к доверенному корню. Итак, когда подпись Authenticode применяется к сборке, нередко можно увидеть задержку в несколько секунд во время загрузки этой сборки.
Если вы находитесь в сети с ограниченным доступом, каждый вызов точки распространения CRL будет иметь тайм-аут, потенциально увеличивая задержку более 2 минут.
Что касается отладки, вы обычно можете устранить такого рода зависание, взломав код в отладчике и просмотрев стек вызовов. Что-то простое, как Обозреватель процессов должно быть возможность загружать символы и покажите, что вы ждете CRL.