Microsoft MVP성태의 닷넷 이야기
디버깅 기술: 5.10. Symbol Server 생성 [링크 복사], [링크+제목 복사],
조회: 32646
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
부모글 보이기/감추기
(연관된 글이 5개 있습니다.)

8. Symbol Server 생성

아마도 여러분들 중에는 왜 PDB 파일을 관리하기 위해 굳이 Symbol Server를 두어야 하는지에 대해 의문을 가지시는 분들도 계실 것입니다. 사실, 제 생각에도 프로젝트의 성격에 따라서는 Symbol Server를 생성할 필요없이 간단하게 나름대로 버전별 PDB 파일을 유지하는 것도 좋은 방법이 될 수 있다고 봅니다.
만약 여러분들이 만든 프로그램을 고객이 사용하다가 문제가 발생했을 경우, 항상 최신의 모듈과 PDB 파일을 보내줄 수 있는 경우에도 굳이 Symbol Server까지 생성할 필요는 없을 것입니다. 그렇지 않고, 그 이외의 상황에 놓인 분들이라면 Symbol Server를 구축하는 것에 대해 충분히 고려해 볼 여지가 있을 것 같습니다.

Symbol Server를 구축해 두면, 여러분들은 고객으로부터 받게 되는 미니 덤프 파일에 대해 별도의 PDB 경로를 지정해야 하는 수고로움을 덜을 수 있습니다. 물론, 고객이 사용하고 있던 모듈의 빌드 버전에 맞는 PDB 파일을 일일이 찾아야 하는 번거로움도 없어지게 되지요.
또한, 팀내의 다른 사람, 또는 고객이 직접 해당 PDB 파일을 사용하여 디버깅을 하도록 기능을 제공하고 싶다면, 단지 Symbol Server 주소를 알려주는 것으로 끝나게 됩니다. 결국 여러 모로 개발자 여러분들의 삶을 편안하게 해줄 수 있는 것이 바로 "Symbol Server"인 것입니다.

이를 구축하기 위해서는, 아래의 WinDBG 토픽에서 설명한 데로, "Debugging Tools for Windows"를 설치해야 합니다. 70MB 용량으로 더 없이 훌륭한 디버깅 기능을 제공해 주기 때문에, 설령 쓰지 않더라도 동료 개발자를 긴장시키기 위해 가끔 한번이라도 실행해 보는 용도로도 그만일 것입니다. ^^

커널 구조체 살펴보기

사실, Symbol Server 구축은 그다지 어려운 주제는 아닙니다. 문제는, 이 글을 읽고 난 후의 여러분들의 자세입니다. 바라건데, 적어도 이 글을 읽은 분들이라면 자신의 개발팀 만큼은 적절한 "Symbol Server" 관리를 꼭 하셨으면 좋겠습니다.

그럼, 이제 찬찬히 따라가 볼까요? ^^



1. 제품에 대해 PDB 파일을 쌓아둘 서버를 선정합니다. 가능한 하드 디스크 용량이 넉넉하고, http로 외부에 노출시킬 수 있는 컴퓨터를 선정하시기 바랍니다. 내부에서만 사용될 용도라면 공인 IP를 가지고 있을 필요까지는 없겠지요.
일단, 그 컴퓨터의 URL이 "www.sysnet.pe.kr"이고, 컴퓨터 이름은 "w2003ayukon"이라고 가정하겠습니다.

2. Symbol 파일들이 저장될 폴더 경로를 정합니다. 여기에서는 "\\w2003ayukon\LibSymbols"라고 정하겠습니다. 이 폴더를 접근하기 위한 HTTP 경로는 "https://www.sysnet.pe.kr/LibSymbols"입니다.

3. 여러분의 제품을 빌드한 폴더에서 "*.dll; *.pdb; *.exe"에 해당하는 파일들을 별도의 폴더에 보관합니다. 예를 들어, 해당 파일들을 "D:\temp2\PdbSample\Symbols" 폴더에 복사했다고 가정하겠습니다.

4. 이제, "D:\temp2\PdbSample\Symbols" 폴더에 존재하는 바이너리 파일들을 "\\w2003ayukon\LibSymbols" 폴더에 "Symbol Server" 역할을 할 수 있도록 저장해 보겠습니다. 이를 위해서 "C:\Program Files\Debugging Tools for Windows\symstore.exe" 파일을 이용하는 다음과 같은 배치 파일을 만듭니다.

symstore add /r /f D:\temp2\PdbSample\Symbols\*.* /s \\w2003ayukon\LibSymbols /t "TestLib" /v "1,0,0,0"

형식을 풀어보면 다음과 같습니다.

symstore add /r /f [Symbol 서버에 저장될 바이너리 파일 지정] /s [Symbol 서버 경로] /t [임의의 제품명] /v [임의의 버전 문자열]

5. 제품이 릴리스 될 때마다, 또는 의미있는 빌드로 공개될 때마다 여러분들은 해당 바이너리들에 대해 위와 같이 Symbol Server에 저장해 두어야 합니다. 이것이 Symbol Server를 구축하는 방법에 대한 모든 설명입니다.

지금까지 보여드렸던 WinForm App를 위와 같은 단계를 거치는 경우, 최종적으로 다음과 같이 구성되어져 있어야 합니다.

C:\Program Files\SysNET\SmallTool>symstore add /r /f D:\temp2\PdbSample\Symbols\*.* /s \\w2003ayukon\LibSymbols /t "TestLib" /v "1,0,0,0"
Finding ID...  0000000001

SYMSTORE: Number of files stored = 4
SYMSTORE: Number of errors = 0
SYMSTORE: Number of files ignored = 0

위와 같이 명령을 실행한 결과 다음과 같이 폴더가 생성되어져 있어야 합니다.

PDB 구성 파일 시스템

아울러, 인터넷 정보 관리자에서는 아래와 같이 보여져야 합니다.

IIS 관리자에서 본 PDB 구성

위와 같이 웹 서버를 이용해서 심벌 파일을 내려받게 하고 싶은 경우에는, PDB/EXE/DLL 파일들에 대해서 다음과 같이 Mime-Type을 별도로 추가해 주어야 합니다.
(보안상, 반드시 LibSymbols 가상 디렉토리에만 이 설정을 하도록 합니다.)

MimeType 설정



이제, 남은 것은 여러분들이 구축한 실제 Symbol 서버를 어떻게 사용하는 지에 대한 방법입니다. 사실, 이 부분은 지난 토픽이었던 "3.7. Microsoft 의 PDB 파일 관리"
를 보시면 아실 수 있는 부분인데요. 복습 겸 실습을 위해서 다시 한번 위의 환경 설정을 가지고 설명해 보도록 하겠습니다.

우선 상황을 가정해보면, 여러분들은 라이브러리 개발자이고 위와 같은 구성을 통해서 이미 심벌 서버를 마련해 둔 상태입니다.
동료 개발자들이 여러분이 만든 라이브러리를 사용하고 있으며, 어느 순간 문제가 발생되어서 디버깅을 요청이 들어왔습니다.
다행히 그 동료 개발자는 여러분들과 함께 제 웹사이트에 연재된 "PDB 이야기"를 정독했기 때문에 ^^ 심벌 서버의 URL을 알려주는 것으로 마무리 할 수 있습니다.
(만약, 그 동료 개발자가 아직 "PDB 이야기"를 읽어 보지 않았다 해도 간단합니다. 그런 경우에는 "PDB 이야기" URL과 함께 심벌 서버의 URL을 알려주기만 하면 됩니다. ^^; 그런데, 그 개발자가 그냥 직접 해서 결과만 알려달라고 말한다면? 그런 경우에는 "http://blog.naver.com/saltynut/120027616587" URL을 알려주시고 4번 항목을 읽어보라고 하십시오. 그랬는데도 심경의 변화가 없다면...? OTL)

자, 이제 적어도 여러분들은 계속해서 여러분들의 업무에 집중할 수 있으며, 동료 개발자는 가장 오류 정보를 확실하게 얻을 수 있는 자신의 개발 환경에서 디버깅을 할 수 있게 되었습니다.
잘 배운데로, 동료 개발자는 우선 다음과 같이 "_NT_SYMBOL_PATH" 환경 변수를 설정할 것입니다.

*** 원래는 한줄입니다. ***
SRV*\\localhost\d$\Symbol\OSSymbols*http://msdl.microsoft.com/download/symbols;
SRV*\\localhost\d$\Symbol\TestSymbols*https://www.sysnet.pe.kr/LibSymbols;
C:\Windows\system32

이제 디버깅을 시작하면, 여러분들이 평소에 잘 저장해 두었던 PDB 파일들이 현재의 동료 개발자에게 보내졌던 라이브러리 버전에 맞게 "D:\Symbol\TestSymbols" 폴더에 다운로드 되어지는 것을 확인할 수 있습니다.
여러분들의 훌륭한 동료 개발자는 이제 문제가 해당 개발 환경상의 문제였는지? 여러분들의 코드가 문제였는지 짚어줄 것입니다.




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






[최초 등록일: ]
[최종 수정일: 7/5/2021]

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

비밀번호

댓글 작성자
 



2006-10-16 03시23분
[오규태] 좋은 자료를 공유해 주셔서 정말로 감사드립니다.
덕분에 많이 미흡하지만 어느정도 모양세를 갖춘 심볼서버를 구축하게 되었습니다.
정말로 좋은 정보 감사드립니다. 좋은 하루 되세요~
[guest]
2006-10-16 04시55분
사실, 저는 이것 저것 자료를 모은 것에 불과합니다. 암튼, 도움이 되셨다니... 다행입니다. ^^
kevin25
2011-04-02 12시37분
Debugging Series: Symbol Server
; (broken) http://blogs.msdn.com/b/camerons/archive/2011/04/01/debugging-series-symbol-server.aspx
; https://docs.microsoft.com/en-us/windows/win32/dxtecharts/debugging-with-symbols#symbol-servers
정성태
2013-05-21 01시13분
GitHub Source Symbol Indexer
; (broken) http://hamishgraham.net/post/GitHub-Source-Symbol-Indexer.aspx

Haemoglobin/GitHub-Source-Indexer
; https://github.com/Haemoglobin/GitHub-Source-Indexer
정성태

1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13561정성태2/20/20242054닷넷: 2218. C# - (예를 들어, Socket) 비동기 I/O에 대한 await 호출 시 CancellationToken을 이용한 취소파일 다운로드1
13560정성태2/19/20242086디버깅 기술: 195. windbg 분석 사례 - Semaphore 잠금으로 인한 Hang 현상 (닷넷)
13559정성태2/19/20242944오류 유형: 895. ASP.NET - System.Security.SecurityException: 'Requested registry access is not allowed.'
13558정성태2/18/20242176닷넷: 2217. C# - 최댓값이 1인 SemaphoreSlim 보다 Mutex 또는 lock(obj)를 선택하는 것이 나은 이유
13557정성태2/18/20241921Windows: 258. Task Scheduler의 Author 속성 값을 변경하는 방법
13556정성태2/17/20241966Windows: 257. Windows - Symbolic (hard/soft) Link 및 Junction 차이점
13555정성태2/15/20242116닷넷: 2216. C# - SemaphoreSlim 사용 시 주의점
13554정성태2/15/20241861VS.NET IDE: 189. Visual Studio - 닷넷 소스코드 디컴파일 찾기가 안 될 때
13553정성태2/14/20241943닷넷: 2215. windbg - thin/fat lock 없이 동작하는 Monitor.Wait + Pulse
13552정성태2/13/20241896닷넷: 2214. windbg - Monitor.Enter의 thin lock과 fat lock
13551정성태2/12/20242089닷넷: 2213. ASP.NET/Core 웹 응용 프로그램 - 2차 스레드의 예외로 인한 비정상 종료
13550정성태2/11/20242206Windows: 256. C# - Server socket이 닫히면 Accept 시켰던 자식 소켓이 닫힐까요?
13549정성태2/3/20242504개발 환경 구성: 706. C# - 컨테이너에서 실행하기 위한 (소켓) 콘솔 프로젝트 구성
13548정성태2/1/20242335개발 환경 구성: 705. "Docker Desktop for Windows" - ASP.NET Core 응용 프로그램의 소켓 주소 바인딩(IPv4/IPv6 loopback, Any)
13547정성태1/31/20242085개발 환경 구성: 704. Visual Studio - .NET 8 프로젝트부터 dockerfile에 추가된 "USER app" 설정
13546정성태1/30/20241947Windows: 255. (디버거의 영향 등으로) 대상 프로세스가 멈추면 Socket KeepAlive로 연결이 끊길까요?
13545정성태1/30/20241859닷넷: 2212. ASP.NET Core - 우선순위에 따른 HTTP/HTTPS 호스트:포트 바인딩 방법
13544정성태1/30/20241883오류 유형: 894. Microsoft.Data.SqlClient - Could not load file or assembly 'System.Security.Permissions, ...'
13543정성태1/30/20241881Windows: 254. Windows - 기본 사용 중인 5357 포트 비활성화는 방법
13542정성태1/30/20241913오류 유형: 893. Visual Studio - Web Application을 실행하지 못하는 IISExpress - 두 번째 이야기
13541정성태1/29/20241973VS.NET IDE: 188. launchSettings.json의 useSSL 옵션
13540정성태1/29/20242078Linux: 69. 리눅스 - "Docker Desktop for Windows" Container 환경에서 IPv6 Loopback Address 바인딩 오류
13539정성태1/26/20242365개발 환경 구성: 703. Visual Studio - launchSettings.json을 이용한 HTTP/HTTPS 포트 바인딩
13538정성태1/25/20242418닷넷: 2211. C# - NonGC(FOH) 영역에 .NET 개체를 생성파일 다운로드1
13537정성태1/24/20242508닷넷: 2210. C# - Native 메모리에 .NET 개체를 생성파일 다운로드1
13536정성태1/23/20242595닷넷: 2209. .NET 8 - NonGC Heap / FOH (Frozen Object Heap) [1]
1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...