Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 

DEVPATH 환경 변수의 사용 예 - .NET Reflector의 (PDB 연결이 없는) DLL의 소스 코드 디버깅

지난 글에서 설명한,

개발자를 위한 닷넷 어셈블리 바인딩 - DEVPATH 환경 변수
; https://www.sysnet.pe.kr/2/0/12276

DEVPATH를 멋들어지게 활용한 사례가 바로 ".NET Reflector"입니다. 일반적으로 "소스 코드가 없는" 어셈블리를 디버깅하는 방법이,

.NET Reflector를 이용한 "소스 코드가 없는" 어셈블리 디버깅
; https://www.sysnet.pe.kr/2/0/1201

".NET Reflector" 뿐만 아니라, dnSpy나 JetBrains의 "dotPeek"와 같은 도구에서도 제공하긴 합니다. 그런 와중에 .NET Reflector가 특별한 것은, 바로 PDB 정보가 없는 DLL에 대해서도 소스 코드 디버깅을 지원한다는 점입니다.

예전에도 이런 문제에 대해 설명한 적이 있는데요,

서드파티 dll 디버깅에 대해 질문드립니다.
; https://www.sysnet.pe.kr/3/0/4852

C# - PDB 파일 경로를 PE 파일로부터 얻는 방법
; https://www.sysnet.pe.kr/2/0/11237

"IMAGE_DEBUG_DIRECTORY"를 갖지 않는 어셈블리의 경우 dnSpy는 다음과 같이 "Save PDB File" 옵션이 아예 비활성화되어 있습니다.

save_pdb_debug_1.png

또한 dotPeek 도구에서는 해당 메뉴는 제공하지만 (오류 없이) 실행은 돼도 아무런 출력물이 없습니다. (사실 기능을 제공한다고 해도 이런 도구들은 DEVPATH와 연동을 하지 않기 때문에 정상적인 동작을 하지 않게 됩니다.)




그렇다면 IMAGE_DEBUG_DIRECTORY의 유무에 따라 어떻게 기능이 달라지는 걸까요?

우선, IMAGE_DEBUG_DIRECTORY가 있는 어셈블리는 디버거가 IMAGE_DEBUG_DIRECTORY를 읽음으로써 PDB 등의 심벌 파일을 로드해야 한다는 것을 알 수 있으므로 dnSpy, dotPeek, .NET Reflector 등의 도구에서는 해당 DLL을 기반으로 PDB 파일만을 생성해 비주얼 스튜디오가 관리하는 심벌 파일 위치에,

save_pdb_debug_2.jpg

넣어 놓으면 됩니다. 그럼, 비주얼 스튜디오는 디버깅 시 DLL에 대한 심벌 파일을 정해진 위치에서 찾아 로드하는 식으로 동작하게 됩니다.

문제는, IMAGE_DEBUG_DIRECTORY가 없는 경우입니다. 당연히 디버거 입장에서는 어떤 종류의 심벌 파일이 있는지, 그 심벌 파일의 이름이 뭔지조차 알 수 없으므로 아예 무시를 하게 됩니다. 즉, 심벌 파일을 로드하도록 만들려면 원본 DLL에 IMAGE_DEBUG_DIRECTORY를 심어 넣어야 하는 것입니다.

예상할 수 있듯이 dnSpy와 dotPeek 등의 도구는 원본 DLL을 수정하지 않기 때문에 IMAGE_DEBUG_DIRECTORY가 없는 어셈블리에 대해서는 역어셈블된 소스 코드에 대한 디버깅을 지원하지 못합니다. 반면 .NET Reflector는 마찬가지로 원본 DLL을 수정하지는 않지만, IMAGE_DEBUG_DIRECTORY를 가진 새로운 DLL을 생성해서 DEVPATH에 놓기 때문에 비주얼 스튜디오는 디버깅 시 IMAGE_DEBUG_DIRECTORY를 가진 DLL을 로드하게 되고, 이어서 PDB 파일도 로드하게 되므로 소스 코드 디버깅이 가능해지는 것입니다.

(물론, IMAGE_DEBUG_DIRECTORY가 있는 DLL에 대해서는 DEVPATH에 변경된 어셈블리를 만들진 않습니다.)

보다 구체적으로 언급해 보면. ^^

Visual Studio 2019의 경우 ".NET Reflector Visual Studio Extension" 확장은 "Extensions" / ".NET Reflector" / "Generate PDBs..." 메뉴로 (PDB가 연결되지 않은) DLL 파일을 선택하면 시스템에 다음과 같은 작업을 해 둡니다.

  1. "%LOCALAPPDATA%\Red Gate\.NET Reflector\Cache\0" 폴더에 해당 어셈블리의 PDB 파일 및 역어셈블한 소스 코드 파일 생성
  2. 위의 1번 과정에서 생성한 PDB를 연결한 새로운 DLL을 %DEVPATH% 경로에 생성

위의 과정 중 2번 단계에서 재미있는 것은, 원본 DLL이 서명된 어셈블리라면 당연히 IMAGE_DEBUG_DIRECTORY를 포함한 새로운 DLL은 검증에 실패한다는 점입니다.

// 서명된 원본 DLL

D:\temp> sn -v InterSystems.Data.IRISClient.dll

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Assembly 'InterSystems.Data.IRISClient.dll' is valid

// DEVPATH에 새롭게 생성된 DLL

C:\ProgramData\Red Gate\.NET Reflector\DevPath> sn -v InterSystems.Data.IRISClient.dll

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Failed to verify assembly -- Strong name validation failed.

하지만, CLR은 DEVPATH로부터 로드하는 어셈블리에 대해 검증 절차를 생략해 줍니다. 정리해 보면 DEVPATH에 들어 있는 DLL은 CLR로부터 다음의 특별한 혜택을 누리는데,

  1. 로컬 경로에 있는 DLL보다 더 높은 로딩 우선순위
  2. 서명된 어셈블리여도 검증 생략

이것들은 마치... 뭐랄까 애당초 ".NET Reflector"에 의해 소스 코드 디버깅 용도로 활용하라는 배려였다는 느낌마저 듭니다. ^^ (아마도 DEVPATH에 저런 규칙을 만들어 둔 마이크로소프트의 개발자들조차도 저런 활용 사례를 예상치 못했을 것입니다.)




이런 특성으로 인해, 오히려 주의해야 할 사항이 있는데 저렇게 DEVPATH에 넣어진 DLL이 가장 우선순위가 높게 로딩이 이뤄지므로 개발 시 필요가 없어지면 반드시 해당 파일을 삭제하는 습관을 들여야 합니다. 그렇지 않고, 혹시라도 잊어버린다면 이후 개발할 때마다 분명히 비주얼 스튜디오에서 빌드하고 있는데도 불구하고 예전 기능을 수행하는 희한한 현상을 겪을 수 있습니다.

그리고, 아마도 아래의 오류들도 그런 식으로 캐시가 되어 발생한 문제들이지 않았나... 하는 예상을 해봅니다. ^^

regsvcs 등록 시 0x80040153 오류
; https://www.sysnet.pe.kr/2/0/1656

vcpkg 빌드 오류 - Starting the CLR failed with HRESULT 80040153
; https://www.sysnet.pe.kr/2/0/11427




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]





[최초 등록일: ]
[최종 수정일: 8/2/2020 ]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer@outlook.com

비밀번호

댓글 쓴 사람
 




[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
12350정성태9/25/2020114Windows: 175. 윈도우 환경에서 클라이언트 소켓의 최대 접속 수파일 다운로드1
12349정성태9/25/202053Linux: 32. Ubuntu 20.04 - docker를 위한 tcp 바인딩 추가
12348정성태9/25/202033오류 유형: 658. 리눅스 docker - Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock
12347정성태9/25/202085Windows: 174. WSL 2의 네트워크 통신 방법
12346정성태9/25/202033오류 유형: 657. IIS - http://localhost 방문 시 Service Unavailable 503 오류 발생
12345정성태9/25/202030오류 유형: 656. iisreset 실행 시 "Restart attempt failed." 오류가 발생하지만 웹 서비스는 정상적인 경우
12344정성태9/25/202043Windows: 173. 서비스 관리자에 "IIS Admin Service"가 등록되어 있지 않다면?
12343정성태9/24/2020174.NET Framework: 945. C# - 닷넷 응용 프로그램에서 메모리 누수가 발생할 수 있는 패턴
12342정성태9/25/2020130디버깅 기술: 171. windbg - 인스턴스가 살아 있어 메모리 누수가 발생하고 있는지 확인하는 방법
12341정성태9/23/2020171.NET Framework: 944. C# - 인스턴스가 살아 있어 메모리 누수가 발생하고 있는지 확인하는 방법파일 다운로드1
12340정성태9/23/202095.NET Framework: 943. WPF - WindowsFormsHost를 담은 윈도우 생성 시 메모리 누수
12339정성태9/21/202070오류 유형: 655. 코어 모드의 윈도우는 GUI 모드의 윈도우로 교체가 안 됩니다.
12338정성태9/21/202042오류 유형: 654. 우분투 설치 시 "CHS: Error 2001 reading sector ..." 오류 발생
12337정성태9/21/202044오류 유형: 653. Windows - Time zone 설정을 바꿔도 반영이 안 되는 경우
12336정성태9/21/2020152.NET Framework: 942. C# - WOL(Wake On Lan) 구현
12335정성태9/21/202054Linux: 31. 우분투 20.04 초기 설정 - 고정 IP 및 SSH 설치
12334정성태9/21/202034오류 유형: 652. windbg - !py 확장 명령어 실행 시 "failed to find python interpreter"
12333정성태9/20/2020102.NET Framework: 941. C# - 전위/후위 증감 연산자에 대한 오버로딩 구현 (2)
12332정성태9/18/202090.NET Framework: 940. C# - Windows Forms ListView와 DataGridView의 예제 코드파일 다운로드1
12331정성태9/24/202081오류 유형: 651. repadmin /syncall - 0x80090322 The target principal name is incorrect.
12330정성태9/20/2020231.NET Framework: 939. C# - 전위/후위 증감 연산자에 대한 오버로딩 구현 [2]파일 다운로드1
12329정성태9/16/2020116오류 유형: 650. ASUS 메인보드 관련 소프트웨어 설치 후 ArmouryCrate.UserSessionHelper.exe 프로세스 무한 종료 현상
12328정성태9/16/202089VS.NET IDE: 150. TFS의 이력에서 "Get This Version"과 같은 기능을 Git으로 처리한다면?
12327정성태9/12/2020148.NET Framework: 938. C# - ICS(Internet Connection Sharing) 제어파일 다운로드1
12326정성태9/12/2020138개발 환경 구성: 516. Azure VM의 Network Adapter를 실수로 비활성화한 경우
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...