ASP.NET MVC 웹 응용 프로그램에서 관리되는 C# 관리 라이브러리를 통합하여 관리되지 않는 플러그인을로드하여 파일 처리를 수행합니다. 이러한 관리되지 않는 플러그인은 몇 가지 타사 라이브러리를 사용하여 더러운 작업을 수행합니다. 그 중 일부는 IIS가 손상되도록합니다.신비한 IIS 크래시 디버그
우리는 파일을 올바르게 처리 할 수있는 데스크톱 응용 프로그램에서 똑같은 라이브러리를 사용합니다. Visual Studio 2008과 함께 제공되는 Cassini 웹 서버 (IIS 및 Cassini는 로컬 상자의 동일한 폴더에서 실행 중임)에서 실행하면 파일도 제대로 처리됩니다.
유용한 정보를 추출 할 수없는 Crash Analysis with Debug Diagnostic (img)을 작성했습니다.
procexp를 사용하여 문제의 원인이 될 수있는 파일이나 레지스트리 액세스 시도가 실패했는지 여부를 확인하기가 다소 어려웠습니다. 나는 아무 것도 보지 못했지만 그러한 종류의 벌목에서 생산 된 줄의 수를 고려해 쉽게 놓칠 수있었습니다.
도메인 계정을 사용하도록 응용 프로그램 풀을 구성하고 권한 문제 일 수도 있지만 운이 없다고 생각하는 내 상자의 관리자 계정을 만들었습니다. 내가 모르는 IIS에 다른 액세스 제한이 있습니까?
제안 사항? 조항? 도구? 부두교?
편집 : 타사 라이브러리의 초기화 루틴을 디버깅 할 수있었습니다. 라이브러리가 다른 호스트에서 잘 작동하기 때문에 사용 권한 문제 나 메모리 문제가 의심됩니다. IIS에서 실행할 때 스택 크기 제한으로 판명되었습니다. Stack sizes in IIS - affects ASP.NET
타사 구성 요소가 충돌을 일으킬 때 정확한 지점을 추적 할 수 있도록 액세스 권한이있는 코드에 일부 로그인 할 수 있습니까? 예를 들어, 충돌은 항상 동일한 함수 호출로 인한 것일 수 있습니다. 이런 식으로 알고 있으면 제 3 자 구성 요소 *가 어떻게 든 IIS를 중단시키는 것을 아는 것보다 문제를 해결하는 데 도움이 될 수 있습니다. – stakx