릴리스 빌드에서 더 나은 PDB 분석을 위해 권장되는 VC++ 설정

Question

더 많은 정보가 포함된 더 나은 PDB 파일을 생성하기 위해 알아야 할 VC++ 설정이 있습니까?

프로젝트를 기반으로 크래시 덤프 분석 시스템을 갖추고 있습니다. 충돌.

또한 내 프로덕션 빌드 서버에는 D:\에 소스 코드가 설치되어 있지만 개발 컴퓨터에는 C:\에 소스 코드가 있습니다.VC++ 설정에 소스 경로를 입력했지만 크래시 호출 스택을 살펴보면 자동으로 소스 코드로 이동하지 않습니다.내 개발 컴퓨터의 소스 코드가 D:\에 있으면 작동할 것이라고 믿습니다.

Answer 1

"내가 알아야 할 VC++ 설정이 있나요?"

프레임 포인터 생략을 꺼야 합니다.Larry osterman의 블로그에는 역사적 세부 사항 fpo와 디버깅으로 인해 발생하는 문제에 대해 설명합니다.

기호가 성공적으로 로드되었습니다.콜스택이 표시되지만 항목을 두 번 클릭해도 소스 코드로 이동하지 않습니다.

어떤 VS 버전을 사용하고 있나요?(혹은 Windbg를 사용하고 계시나요?) ...VS에서는 위치를 찾지 못하면 처음으로 소스를 묻는 메시지를 확실하게 표시해야 합니다.그러나 '찾을 수 없는' 소스 목록도 유지하므로 매번 요청하지는 않습니다.가끔은 조회 금지 목록이 고통스러울 때가 있습니다.프롬프트를 백업하려면 솔루션 탐색기/솔루션 노드/속성/디버그 속성으로 이동하여 아래쪽 창에서 파일 목록을 편집해야 합니다.

마지막으로 '스트립된 기호'를 사용하고 있을 수도 있습니다.이는 FPO를 지나 콜스택을 탐색하기 위한 디버그 정보를 제공하기 위해 생성된 pdb 파일이지만 소스 위치는 제거됩니다(다른 데이터와 함께).Windows OS 구성 요소의 공개 기호는 제거된 pdb입니다.자신의 코드의 경우 이는 단순히 고통을 야기하며 pdb를 외부에 제공하지 않는 한 그만한 가치가 없습니다.이 끔찍한 제거된 PDB 중 하나를 어떻게 갖게 될까요?-a 명령과 함께 "binplace"를 사용하면 해당 파일이 있을 수 있습니다.

행운을 빌어요!적절한 미니 덤프 스토리는 프로덕션 디버깅을 위한 신의 선물입니다.

Answer 2

소스코드 관리 시스템에서 직접 빌드하는 경우 pdb 파일에 파일 출처에 대한 주석을 달아야 합니다.이를 통해 디버깅하는 동안 정확한 소스 파일을 자동으로 가져올 수 있습니다.(이는 .Net 프레임워크 소스코드를 검색하는 데 사용되는 프로세스와 동일합니다.)

보다 http://msdn.microsoft.com/en-us/magazine/cc163563.aspx 자세한 내용은.SCM으로 Subversion을 사용하는 경우 SourceServerSharp 프로젝트를 확인할 수 있습니다.

Answer 3

MS-DOS를 사용해 볼 수도 있습니다. 대체하다 소스 코드 디렉터리를 D:에 할당하는 명령운전하다.

Answer 4

이것은 귀하와 유사한 문제가 발생한 후에 사용한 절차입니다.

a) 빌드된 모든 EXE 및 DLL 파일을 프로덕션 서버에 복사하고 각각 해당 PDB를 동일한 디렉터리에 복사하고 시스템을 시작한 다음 충돌이 발생할 때까지 기다렸습니다.

b) 모든 EXE, DLL 및 PDB 파일을 미니덤프(동일한 폴더에 있음)와 함께 개발 머신(임시 폴더)에 다시 복사했습니다.Visual Studio를 사용하여 해당 폴더에서 미니덤프를 로드했습니다.

VS는 원래 컴파일된 소스 파일을 찾았으므로 항상 해당 파일을 식별하고 올바르게 로드할 수 있었습니다.여러분과 마찬가지로 생산 시스템에서는 사용된 드라이브가 C:가 아니었지만 개발 시스템에서는 C:였습니다.

두 가지 추가 팁:

• 제가 자주 했던 일 중 하나는 다시 빌드된 EXE/DLL을 복사하고 새 PDB를 복사하는 것을 잊어버리는 것이었습니다.이로 인해 디버그 주기가 망가졌고 VS는 호출 스택을 표시할 수 없게 되었습니다.

• 때로는 VS에서 이해되지 않는 호출 스택이 발생했습니다.약간의 두통 끝에 나는 windbg가 항상 올바른 스택을 표시하지만 VS는 종종 그렇지 않다는 것을 발견했습니다.이유를 모르겠어요.

Answer 5

누군가 관심이 있을 경우를 대비하여 동료가 이메일을 통해 나에게 이 질문에 답했습니다.

Artem은 다음과 같이 썼습니다.

Minidumpwritedump ()에 대한 플래그가 있으며, 모든 글로벌 변수 등의 전체 프로그램 상태를 볼 수있는 더 나은 충돌 덤프를 수행 할 수 있습니다.콜 스택에 관해서는, 최적화로 인해 그들이 더 나아질 수 있다고 의심 스럽다 ...당신이 (아마도) 최적화를 끄지 않는 한.

또한 인라인 기능과 전체 프로그램 최적화를 비활성화하는 것이 많은 도움이 될 것이라고 생각합니다.

사실, 많은 덤프 유형이 있습니다. 아마도 작은 하나를 선택할 수 있지만 여전히 더 많은 정보를 가지고 있습니다. http://msdn.microsoft.com/en-us/library/ms680519(VS.85).aspx

이러한 유형은 통화 스택에 도움이되지 않지만 볼 수있는 변수의 양만 영향을 미칩니다.

우리가 사용하는 DBGHELP.DLL 버전 5.1에서 이러한 덤프 유형 중 일부가 지원되지 않는다는 것을 알았습니다.그러나 최신 6.9 버전으로 업데이트 할 수 있습니다. MS 디버깅 도구를위한 EULA를 확인했습니다. 최신 DBGHELP.DLL은 여전히 ​​재분배해도 괜찮습니다.

Answer 6

Visual Studio에서 소스 파일의 경로를 묻는 메시지를 표시합니까?그렇지 않은 경우 콜스택에 대한 기호가 없다고 생각합니다.소스 경로 설정은 정확한 원래 위치를 매핑하지 않고도 작동해야 합니다.

Visual Studio의 '모듈' 창을 보면 기호가 로드되었는지 알 수 있습니다.

PDB를 구축한다고 가정하면 PDB의 정보 양을 직접 제어하는 ​​옵션은 없을 것 같습니다.디버그 가능성을 향상시키기 위해 컴파일러가 수행하는 최적화 유형을 변경할 수 있지만 이로 인해 성능이 저하됩니다. 동료가 지적했듯이 인라인을 비활성화하면 충돌 파일에서 상황을 더 명확하게 만드는 데 도움이 되지만 런타임에는 비용이 발생합니다.

애플리케이션의 성격에 따라 가능하다면 전체 덤프 파일로 작업하는 것이 좋습니다. 파일 크기는 더 크지만 프로세스에 대한 모든 정보를 제공합니다.어쨌든 얼마나 자주 충돌합니까 :)

Answer 7

Visual Studio가 소스 파일로가는 경로에 대해 알려주고 있습니까?

아니요.

그렇지 않으면 콜 스택에 대한 기호가 있다고 생각하지 않습니다.소스 경로 설정은 정확한 원본 위치를 매핑하지 않고도 작동해야합니다.

기호가 성공적으로 로드되었습니다.콜스택이 표시되지만 항목을 두 번 클릭해도 소스 코드로 이동하지 않습니다.물론 파일에서 문제의 줄을 검색할 수 있지만 이는 힘든 작업입니다. :)