Làm cách nào để xác định nguyên nhân gây ra vụ tai nạn IIS trên Máy chủ 64 bit

Question

Tôi có ứng dụng web .net 2.0 đang chạy trên máy chủ Windows 2003 Chuẩn x64, sử dụng IIS 6.

Nhóm ứng dụng cho chúng tôi trang web bắt đầu gặp sự cố gần đây và tôi không thể xác định lý do. Nó bắt đầu xảy ra vào cuối tuần và bản phát hành mới nhất của trang web là vài ngày trước đó. Tôi đã xác định rằng không có thay đổi nào khác được thực hiện cho máy chủ gần đây, bao gồm cả mã và cập nhật của Microsoft.

Nhật ký sự kiện cho thấy sau khi một vụ tai nạn xảy ra không có thêm thông tin trong khối dữ liệu:

Faulting ứng dụng w3wp.exe, phiên bản 6.0.3790.3959, tem 45d691cc, đứt gãy module kernel32.dll, phiên bản 5.2.3790.4062, đóng dấu 462643a7, gỡ lỗi? 0, địa chỉ lỗi 0x0000000000027d8d.

Điều này đang chạy trên máy chủ x64 vì vậy tôi không thể sử dụng bất kỳ Công cụ chẩn đoán Debug chuẩn nào vì mặc dù có phiên bản 64 bit, nó chỉ gắn với IIS đang chạy ở chế độ 32 bit.

Tôi đã thử sử dụng Công cụ gỡ lỗi cho Windows (x64) và có thể đính kèm vào quy trình w3wp và chờ một sự cố khác. Tuy nhiên, điều này làm chậm máy chủ xuống rất nhiều mà nó đã không sử dụng được, vì vậy tôi đã phải ngăn chặn nó.

Tôi có thể sử dụng phương pháp nào khác để xác định nguyên nhân gây ra sự cố IIS?

Answer 1

Đọc về ASP.NET 2.0 Crash case study: Unhandled exceptions.

Chiến lượC# 1 - đăng nhập trừ
Cách thứ nhất, và đây là cách tôi lẽ muốn giới thiệu, là tạo ra một UnhandledExceptionHandler để đăng nhập ngoại trừ cùng với dấu vết ngăn xếp của nó trong sự kiện này đăng nhập như trong bài viết này http://support.microsoft.com/?id=911816 Bạn thêm xử lý như thế này để các web.config:

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

Và nó gắn một eventhandler lên đến sự kiện UnhandledException của miền ứng dụng hiện tại . Bạn không thực sự cần để tên mạnh nó và thêm nó vào GAC, tuy nhiên nếu bạn có kế hoạch nó trong nhiều ứng dụng bạn nên để tránh cho các dll được nạp nhiều lần. Bây giờ, lần sau, bạn nhận được một trong các trường hợp ngoại lệ không được xử lý này, quá trình này sẽ vẫn còn thoát (trừ khi bạn thay đổi chính sách ngoại lệ chưa được giải quyết), nhưng bạn có rất nhiều cơ hội khắc phục sự cố.

Answer 2

Bạn có thể thiết lập bộ đếm hiệu suất để theo dõi những thứ như CPU, bộ nhớ và bộ đếm cụ thể .NET.Có rất nhiều chi tiết, nhưng bài viết này TechNet có thể giúp:

• Monitoring ASP.NET Performance (IIS 6.0)

ASP.NET chính nó có một không gian tên toàn cho sức khỏe của ứng dụng giám sát. Bạn có thể tạo các sự kiện của riêng bạn hoặc, thông thường nhất, định cấu hình ứng dụng của bạn cho các sự kiện mặc định. bài viết này MSDN có nhiều:

• ASP.NET Health Monitoring Overview

Nếu vấn đề là mã ứng dụng như một ngoại lệ unhandled (mặc dù nếu điều này là vấn đề của bạn tôi mong đợi để xem thêm chi tiết trong tổ chức sự kiện của Windows Đăng nhập), bạn có thể sử dụng các công cụ để bẫy và báo cáo về chúng. ELMAH là một công cụ tuyệt vời mà tôi đã sử dụng trong quá khứ cho việc này. Nó được mô tả là Tivo for web applications và có nhiều cách khác nhau để cung cấp chi tiết về ngoại lệ và giúp theo dõi những gì sai.

Answer 3

Microsoft Debug Diagnostic Tool (DebugDiag) sẽ thực hiện thủ thuật. Nó sẽ cung cấp một phân vùng bộ nhớ IIS và phân tích.