는, 그것이 c:\code\appV2 폴더에 PDB 파일을 찾습니다, c:\code\appV1 폴더windbg가 덤프 및 EXE 파일의 다른 경로를 검색하는 이유는 무엇입니까? 나는 WinDbg는에 덤프 파일을 열 때 나는 WinDbg를 직접 EXE 파일을 열 때
에 PDB 파일을 찾습니다. 두 경우 모두, windbg를가 C에있는 같은 exe를 디버깅하기 때문에
이
이 날 미치게한다 : \ MyApp를 \는에서 검색c:code\appV1 메이크업 감각 App.exe가,이 PDB 파일이 있었다 경로는 exe가 생성하지만 왜 덤프 파일이나 exe와 연결이 전혀없는 c:\code\appV2을 검색합니까?
나는 이것을 광범위하게 파고 들었고, 데모 프로젝트와 시뮬레이션 된 충돌을 만들고 다양한 조합을 시도했다. 그 대답은 덤프 파일이 기본 검색 경로 (pdb)에서 실행 파일에 우선하는 효과가있는 것 같습니다.
당신이이 시나리오를 재현 할 수있는 방법이다.
지금 첫번째 다 말할 앱 1 복사 : \ 테스트 폴더를 실행합니다. 충돌하고 덤프 파일을 만듭니다.
이제 App1Clone 폴더의 App1을 c : \ test 폴더로 복사하고 실행하십시오. 충돌하고 덤프 파일을 만듭니다.
이제는 두 덤프 파일이 c : \ test \ app1.exe에 연결되지만 잘못된 app1.exe가있는 경우 (검색 경로가 일치하지 않음) 덤프 파일에 저장된 경로를 분명히 선택합니다. 덤프 파일이이 경로를 저장하는지 여부는 알 수 없지만 내 실험을 기반으로하는 것으로 보입니다.
'.sympath'로 설정 한 것을 모르거나 DLL이 어디서로드되었는지 알지 못해도 대답 할 수 없습니다. 아마도 DLL이 해당 위치에 등록되어 있습니까? 디버깅 할 때 정확하고 자세한 내용을 살펴볼 필요가 있습니다. 당신은 아마 작은 세부 사항을 놓치고 당신은 우리가 그것을 해결하기 위해 당신의 질문에 더 적은 세부 사항을 제공합니다. –
@ThomasWeller는 이해할 수 있지만'.sympath'로는 아무 것도 설정하지 않습니다. '.reload' 디버그 출력은 어느 경로를 검색해도 프로세스 모니터 사용을 파헤 치고 각각의 경우에 어디에서 찾고 있는지 놀랐다는 것을 알려주지 않습니다. 프로세스 모니터 출력은 결과를 보여 주어야하는 유일한 것이며 시각적 인 창입니다. – zar
@zar! sym noisy를 사용하면 검색된 경로를 포함하여 심볼 로딩 문제를 디버그하는 데 도움이됩니다. – Dono