StatusRivet
워크플로우

랩 PC 두 대 간 원격 Windows 디버거 설정

03
랩 환경

랩 머신 두 대 준비

원격 Windows 디버거 세션은 네트워크를 통해 한 머신의 디버거를 다른 머신의 프로그램에 연결합니다. 이 작업은 오직 소유한 랩 머신 사이에서만 수행해야 합니다. 심볼이 가장 먼저 필요합니다. 한 대의 머신을 호스트로, 다른 한 대를 타겟으로 지정하세요. 프로그램은 디버그 심볼을 포함하여 빌드하고, 해당 빌드와 정확히 일치하는 PDB 파일을 보관하세요. PDB가 일치하지 않으면 함수 이름이 잘못 표시되고 심볼이 없는 스택에서는 주소만 표시됩니다. 작업 중인 호스트 머신에 StatusRivet를 설치하고, 타겟 머신은 테스트할 프로그램만 유지하세요. 변경한 설정은 나중에 복원할 수 있도록 기록해 두세요. 가능한 가장 작은 입력으로 충돌을 재현하세요. 짧은 케이스는 짧은 스택과 더 쉬운 차이 분석을 제공합니다. 에이전트에게 작업을 요청하기 전에 호스트와 타겟이 서로 통신 가능한지 확인하세요. 연결 실패는 디버거 실패로 오해될 수 있기 때문입니다.

01

프로젝트 폴더 열기

소스와 빌드 파일이 포함된 폴더를 채팅의 작업 폴더로 선택하세요. 파일 도구들은 해당 폴더 내부에서만 읽고 편집하기 때문입니다. 저장된 스택과 메모도 여기에 넣으세요. 그러면 전체 케이스가 한 곳에 모여 에이전트가 모든 내용을 읽을 수 있습니다.

02

Ask first로 전환하기

Ask first는 변경 작업을 실행하기 전에 일시 중지하므로, 실행 전에 각 작업을 확인할 수 있습니다. Plan only를 사용하면 단계를 먼저 확인하고 아무것도 실행하지 않을 수 있습니다. 계획은 재시작 후에도 유지되므로 나중에 다시 이어갈 수 있습니다.

03

충돌 설명하기

프로그램 이름, 호스트와 타겟 머신, 증상을 명시하고 머신이 소유한 것임을 밝히세요. 랩 메모에 있는 연결 세부 정보를 제공하며, 추측하지 마세요. 타겟에서 실행 중인 빌드와 해당 PDB 파일을 명시하세요.

04

결과 확인하기

diff를 읽고 빌드 명령어로 다시 빌드한 후, 테스트 명령어를 타겟에서 다시 실행하세요. 변경 사항을 체크리스트와 함께 메모해 두세요. 새 테스트가 여전히 실패한다면 이전 덤프를 보관하세요. 그러면 다음 시도는 기억이 아닌 증거를 바탕으로 시작됩니다.

세션 체크리스트

debug-session.txt
# Debug session checklist
1. Build the app with debug symbols and keep the PDB
2. Note the build the crash happened on
3. Start the debugger on the host machine
4. Attach to the app running on the target
5. Reproduce the crash with the smallest input
6. Save a crash dump on the target
7. Save the faulting thread's call stack to stack.txt
8. Read the exception code and the top frames
9. Match the first frame to a source line
10. Propose a minimal fix and rebuild
11. Run the test again and note what changed

두 대의 랩 머신 간 단일 디버깅 세션을 위한 일반 텍스트 체크리스트입니다. 심볼 포함 빌드, 연결, 가장 작은 입력으로 충돌 재현, 덤프 및 호출 스택 저장, 상위 프레임 읽기, 수정 후 테스트 실행 및 변경 사항 메모를 다룹니다. 프로젝트 폴더에 복사하여 자신의 랩에 맞게 수정하세요. 복사하고 편집하세요.

원격 Windows 디버거로 충돌 분석하기

호스트 머신에서 연결하기

작업: 랩 타겟에서 실행 중인 자신의 프로그램에 호스트 머신에서 연결합니다. 먼저 연결하세요. StatusRivet에서 프로젝트 폴더를 열고 Ask first로 전환한 후 설정을 설명하세요. Shell은 제공한 연결 세부 정보로 디버거의 명령줄 모드를 실행하며, 카드에는 실제 종료 코드를 통해 연결 성공 여부가 표시됩니다. 에이전트는 연결 설정을 임의로 생성하지 않으므로, 호스트, 타겟 및 포트는 자신의 랩 메모에서 가져오세요. 원격 디버깅은 소유한 랩 머신에만 해당되며, 소유하지 않은 컴퓨터에서는 사용해서는 안 됩니다. 다음 단계를 진행하기 전에 카드를 읽어보세요. 연결이 실패했다면 다른 작업이 실행되어서는 안 되며, 먼저 연결을 수정한 후 다시 시도하세요. 카드에는 정확한 명령어가 유지되므로 나중에 이를 반복할 수 있습니다.

덤프 및 호출 스택 저장하기

작업: 타겟에서 가장 작은 입력으로 충돌을 재현한 후 증거를 저장하세요. 두 파일 모두 저장하세요. Shell은 디버거에 충돌 덤프를 작성하고 오류 스레드의 호출 스택을 텍스트 파일로 저장하도록 요청하며, 카드에는 두 결과 모두 표시됩니다. 타겟의 Windows JIT 디버거 설정은 애플리케이션 충돌 시 자동으로 디버거를 시작합니다. 이는 시스템 설정이므로 테스트 머신에서만 변경하고, 이전 값을 기록한 후 나중에 복원하세요. 미니덤프에서 시스템 충돌 원인을 파악하려면 저장된 호출 스택부터 시작하세요. Ask first 모드에서는 각 단계를 승인하며, 다음 사람이 케이스를 읽을 수 있도록 체크리스트와 함께 두 파일을 보관하세요. 파일명은 빌드 이름으로 지정하여 혼동을 피하세요.

프레임을 소스 줄에 매칭하기

작업: 상위 프레임을 코드에 연결하세요. 심볼부터 시작하세요. read_file은 stack.txt를 열고, grep은 프로젝트에서 함수 이름과 예외 코드(예: 액세스 위반의 0xC0000005)를 검색하며, read_file은 해당 줄의 소스 파일을 엽니다. 일치하는 PDB가 있으면 스택에 함수 이름, 소스 파일 및 줄 번호가 표시되지만, 없으면 주소만 표시됩니다. 커널 보안 검사 실패 bsod로 끝나는 시스템 동결은 정확히 이 절차(덤프, 스택, 소스)에 해당합니다. 에이전트가 무언가를 수정하기 전에 증거를 직접 읽어보세요. 에이전트는 텍스트로 작업하며 프로그램을 단계별로 실행할 수 없기 때문입니다. 단계별 실행은 자신의 디버거를 사용하고 에이전트에게 본 내용을 알려주세요.

수정 제안 및 테스트 재실행

작업: 발견 사항을 변경 사항으로 전환하세요. edit_file은 최소한의 diff를 제안합니다(예: 누락된 null 체크 또는 잘못된 인덱스). Ask first 모드에서는 에이전트가 변경된 줄을 읽을 수 있도록 일시 중지합니다. Shell은 심볼 포함 빌드 명령어와 테스트 명령어를 실행하며, 카드에는 실제 종료 코드가 표시됩니다. 작성한 드라이버의 커널 모드 힙 부패 bsod은 잘못된 쓰기 후 오래 후에 나타날 수 있으므로, 마지막 프레임뿐만 아니라 스택에서 이전에 작성된 버퍼도 확인하세요. 랩 타겟의 예외 스토어 bsod도 동일한 방식으로 처리됩니다. 테스트가 통과한 후에만 diff를 수락하고 변경 사항을 기록하세요. 수락 전에 테스트하세요. 테스트가 여전히 실패한다면 새 스택을 보관하고 두 번째 단계부터 루프를 다시 시작하세요.

Windows용 StatusRivet

랩 세션 설정하기

StatusRivet 다운로드 ↗