WinDbg에 익숙하지 않은 것 같아서 필요한 것보다 좀 더 자세한 정보를 얻을 수 있습니다.
WinDbg는 - 86 덤프를 열 수 있습니다이 덤프 파일
에게 WinDbg는 모든 버전 및 비트 수를 열 수있는 버전입니다. 심지어 32 비트 WinDbg는 64 비트 .dmp 파일을 열 수 있습니다. 그렇다고 올바른 버전을 사용하여 달성하려는 작업을 수행한다는 의미는 아닙니다.
이 오류는 발생하지 않지만 다른 출력은 없습니다.
괜찮습니다. 확장이 성공적으로로드되었음을 의미합니다. WinDbg의 올바른 비트 니스를 사용하고 있다는 것을 의미하기 때문에 알아두면 좋습니다. 실제로 사용하는 x86 WinDbg 인 경우 이는 32 비트 SOS DLL이 있음을 나타냅니다. 비트 수가 잘못된 경우 64 비트 프로세스 또는 그 반대에 32 비트 DLL을로드하려고 것처럼
, 당신은 같은 오류 메시지가 (일명. .NET에서 BadImageFormatException를)
확장 명령을 수행하려면 clr.dll이 필요합니다.
SOS 확장은 .NET 용이므로 SOS는 프로세스에로드 된 .NET 프레임 워크를 찾고 있습니다. 이 .NET 4/4.5
clr.dll 상기 메시지로부터 실버 및 .NET 코어 어쩌면 더mscorwks.dll위한 .NET 2/3/3.5coreclr.dll
수있다 , 우리는 당신이 SOS.dll을 가지고 있다는 것을 알 수 있습니다.NET 4, 왜 다른 대신에 clr.dll을 찾고 있습니다. 하늘빛은 .NET보다 최신이기 때문에, 푸른 웹 서비스를위한 합리적인 소리 2.
.NET 실제로 프로세스에로드되었는지 여부, 다음 명령을 사용 보려면 : 이러한 명령 중 하나가 발생하면
lm m clr
lm m mscorwks
lm m coreclr
을 일부 출력,로드 된 버전을 알 수 있습니다. .NET 4와 .NET 2는 병렬로 (프로세스에서 사용 된 두 버전 모두) 발생할 수 있습니다.
mscordacwks.dll에서 .load를 직접 실행하여 이름을 clr.dll로 변경했습니다. WinDbg를 프로세스에
.load로드 뭔가 :
여기에 큰 오해입니다. 당신이 거기에 그것을로드 관리하더라도, SOS는 여전히 덤프 파일에서 그것을 검색 할 것입니다.
mscordacwks은 .NET 프레임 워크가 아닙니다. 그것을 mscorwks과 혼동하지 마십시오. dac 부분은 데이터 액세스 제어용입니다. .NET은 자체 메모리 관리 기능을 가지고 있기 때문에 메모리의 .NET 구조에 대한 액세스를 관리하는 DLL입니다.
그러나 이름을 변경해야 할 수 있습니다. 그것은 어려운 이야기입니다.
그것은 올바른 방향으로가는
을 mscordaccore_X86_X86_4.6.24628.01.dll하기 위해 이름을 변경 ... 당신은 이미 그것을 위해 Google 결과를 찾을 것 같다,하지만 난 그 올바른 생각하지 않습니다 이름. 원래 조언을 연결해 주시겠습니까? 내가 오래된 지식을 가지고 있을지 모른다고 불평하기 전에 조사를 할 수 있습니까?
IMHO 이름 (버전 번호가 일치하는지)
mscordacwks_x86_x86_4.6.24628.01.dll
이어야한다. correct symbol path pointing to Microsoft 다음
!analyze -v
을하고 Microsoft에서 필요한 mscordacwks 파일을 다운로드해야 데 이미 의견 @Lieven Keersmaekers에서 언급 한 바와 같이
. 그렇게하면 자동으로 정확한 이름을 가지며 올바른 폴더에 위치합니다.
는 또한 DebugDiag가 제대로 작동하려면, 그것은 또한 mscordacwks을 필요로 DebugDiag이 분석 도구를
을 실행하려고했습니다. 가장 쉬운 방법은 파일 자체를 다운로드 할 수 있도록 Microsoft 심볼 서버를 사용하는 것입니다.
난 그냥 내 응용 프로그램 서비스가 하나의 크래시 덤프 파일에서 잘못된 것으로 분석 100 %의 CPU
에 걸리면 이유를 알고 싶습니다.크래시 덤프 파일을 캡처 할 때 프로세스가 "정상"상태 일 수 있습니다.
동일한 호출 스택에서 많은 크래시 덤프가있는 경우이 메서드는 끝이 없거나 반복적으로 실행되고 있음을 나타낼 수 있습니다. 높은 CPU에서 많은 크래시 덤프를 자동으로 가져 오려면 ProcDump를 시도하십시오 (how to take a good crash dump for .NET 참조).
그 밖의 무엇이 잘못되었을 수 있습니까?
당신은 이러한 파일이 제공되었다고하셨습니다. 파일의 이름에서 충돌이 발생한 컴퓨터에서 파일을 가져온 것으로 가정합니다. 기본적으로 좋은 생각입니다. PC에는 그러한 파일이 많이 있다는 것을 알아 두십시오.
내 도구 mscordacwks Collector을 실행하면 내 뜻을 알 수 있습니다. 그 도구는 버전을 감지하고 그에 따라 파일의 이름을 바꿉니다. 아마도 당신은 그것을 시도 할 수 있습니다, 그것은 기계가 여전히 사용할 수 있습니다.
'! analyze -v' 또는 아마도'! runaway'를 시도해 보았습니다. (단 하나라고 가정합니다) * 및'~ s; kbnf'를 사용하여 스택 추적을 얻었습니다 실? 즉, 덤프는 단지 시점 일 뿐이므로이 방법으로 실제 원인을 놓칠 수도 있습니다. 일정 기간 동안 프로세스 개요를 얻으려면 procmon * (분석하기 쉬움) * 또는 ETW * (분석하기는 더 어렵지만 정보의 shipload) *를 사용하는 것이 좋습니다. –
@LievenKeersmaekers 감사합니다. 나는 그것들을 시도 할 것입니다. Azure 앱 서비스입니다. procmon을 설치하거나 ETW를 서버에 설치할 수 있다고 생각하지 마십시오. 많은 스레드 (~ 40), 일부 작업 (App Insights 업로드 스레드) 및 쿼리 캐시 (EF 코어)에 대한 액세스를 기다리는 중 일부가 있습니다 –
ETW를 더 잘 사용합니다. http://stackoverflow.com/a/39856838/덤프에서 스냅 샷을 분석하는 대신 1466046. WPT는 다른 시스템에 xcopied 될 수 있습니다 (단지 CPU 아키텍처가 일치하는지 확인하십시오). – magicandre1981