Как определить причину сбоя IIS на 64-разрядном сервере - PullRequest
Новая
       29

Как определить причину сбоя IIS на 64-разрядном сервере

7 голосов
/ 02 июня 2009

У меня есть веб-приложение .net 2.0, работающее на Windows Server 2003 Standard x64 с использованием IIS 6.

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

Журнал событий показывает следующее всякий раз, когда происходит сбой без дополнительной информации в блоке данных:

Неисправное приложение w3wp.exe, версия 6.0.3790.3959, штамп 45d691cc, неисправный модуль kernel32.dll, версия 5.2.3790.4062, штамп 462643а7, отладка? 0, адрес ошибки 0x0000000000027d8d.

Он работает на сервере x64, поэтому я не могу использовать ни один из стандартных средств диагностики отладки, поскольку, несмотря на наличие 64-разрядной версии, он подключается только к IIS, работающему в 32-разрядном режиме.

Я попытался использовать средства отладки для Windows (x64), смог подключиться к процессу w3wp и ждал другого сбоя. Однако это настолько замедлило работу сервера, что его стало невозможно использовать, поэтому мне пришлось его остановить.

Какие еще методы можно использовать для определения причины сбоя IIS?

Ответы [ 3 ]

5 голосов
/ 02 июня 2009

Прочтите о ASP.NET 2.0 Ситуационное исследование аварии: необработанные исключения .

Стратегия # 1 - регистрация исключения
Первый путь, и это путь, которым я вероятно, рекомендую, это создать UnhandledExceptionHandler для входа исключение вместе со своим стеком след в журнале событий, как показано в Эта статья http://support.microsoft.com/?id=911816 Вы добавляете такой обработчик в web.config: 

<system.web>
  <httpModules>
    <add type="WebMonitor.UnhandledExceptionModule, <strong name>"
       name="UnhandledExceptionModule"/>
  </httpModules>
      …
</system.web>

И он перехватывает обработчик событий до Событие UnhandledException из текущий домен приложения. Вы не на самом деле нужно строго назвать это и добавьте его в GAC, однако, если вы планируете это в нескольких приложениях, вы должны чтобы избежать для загрузки DLL многократно. Теперь в следующий раз Вы получаете один из этих необработанных исключения, процесс все равно будет выход (если вы не измените необработанное политика исключений), но у вас очень хороший шанс исправить проблему.

3 голосов
/ 04 января 2010

Microsoft Инструмент диагностики отладки (DebugDiag) сделает свое дело. Это обеспечит дамп памяти IIS и анализ.

3 голосов
/ 02 июня 2009

Вы можете настроить счетчики производительности для наблюдения за такими показателями, как процессор, память и .NET. Есть много деталей, но эта статья TechNet может помочь:

Сам ASP.NET имеет целое пространство имен для мониторинга работоспособности приложения. Вы можете создавать свои собственные события или, чаще всего, настраивать свое приложение для событий по умолчанию. Эта статья MSDN имеет больше:

Если проблема заключается в коде приложения, таком как необработанное исключение (хотя, если бы это была ваша проблема, я бы ожидал увидеть больше подробностей в журнале событий Windows), вы можете использовать инструменты для их отслеживания и составления отчетов. ELMAH - отличный инструмент, который я использовал в прошлом для этого. Он был описан как Tivo для веб-приложений и имеет множество способов предоставления подробностей об исключениях и помогает отследить, что не так.

...