Process Monitor(ProcMon) 실전 가이드 ── 「설정이 반영되지 않는다」「ACCESS DENIED」를 10분 만에 특정하기

「설정 파일을 수정했는데도 애플리케이션의 동작이 바뀌지 않는다」「개발 머신에서는 동작하는데, 고객사 단말기에서만 실행 직후에 다운된다」「어제까지는 동작했다. 프로그램은 아무것도 바꾸지 않았다」──불량 조사 의뢰는 대체로 이런 형태로 들어옵니다. 그리고 이런 종류의 증상 대부분은 소스 코드를 아무리 읽어도 원인에 도달할 수 없습니다. 애플리케이션이 실제로 어떤 파일을 읽고, 어떤 레지스트리를 보고, 무엇에 실패했는가는 코드가 아니라 실행 환경이 결정하기 때문입니다.

그 「실제로 무슨 일이 일어났는가」를 기록해 주는 것이, Microsoft가 무상으로 제공하는 Sysinternals 도구인 Process Monitor(ProcMon)입니다. 파일 시스템·레지스트리·프로세스/스레드의 활동을 실시간으로 전부 기록하는, 말하자면 Windows의 행동 로그 레코더로, 당사의 불량 조사에서도 WinDbg와 나란히 자주 사용하는 도구입니다.¹

강력한 반면, 아무것도 하지 않고 실행하면 초당 수천~수만 건의 이벤트가 흘러들어와, 처음 보면 「너무 많아서 읽을 수 없다」로 끝나버리기 쉽습니다. 이 글에서는 ProcMon을 실무에서 사용하기 위한 최단 경로──Filter를 거는 방법, Result 열을 읽는 법, 증상별 대표적인 조사 패턴, 운영(프로덕션) 환경에서의 주의점, 그리고 다른 조사 도구와의 구분 사용──을, 불량 조사 현장의 시각에서 정리합니다.

1. 먼저 결론부터

• ProcMon이 답해주는 질문은 「이 프로세스는 언제·어느 경로에·무엇을 하여·어떻게 되었는가」입니다. 설정 파일이 어디에서 읽히고 있는지, DLL이 어떤 순서로 탐색되었는지, 어떤 조작이 ACCESS DENIED가 되었는지를 몇 분 만에 알 수 있습니다.
• 사용법의 정석은 「먼저 Process Name으로 대상 프로세스에 Include를 걸고, 다음으로 Result에서 이상 계열로 좁힌다」입니다. 원시 이벤트를 위에서부터 읽어 내려가는 도구가 아닙니다.
• Result 열에는 이상하게 보이지만 정상인 것이 다수 있습니다. BUFFER OVERFLOW는 정상적인 API 왕복이고, NAME NOT FOUND는 탐색 순서의 중간 경과인 경우가 대부분입니다(4장).
• Filter는 화면 표시상의 축소일 뿐이며, 뒤에서는 전체 이벤트가 기록되고 있습니다. 로그를 저장하여 다른 사람에게 전달할 때는 전체 이벤트로 저장합니다. 반대로 장시간 캡처에서는 Drop Filtered Events로 메모리를 보호합니다(5장).
• ProcMon은 만능이 아닙니다. 「지금 어떤 프로세스가 이 파일을 잡고 있는가」는 Process Explorer, 크래시 순간의 상태는 크래시 덤프, CPU를 어디에서 사용하고 있는가는 PerfView의 영역입니다(7장).

증상에서 도구를 선택하는 빠른 참조표를 먼저 실어 둡니다.

2. ProcMon이란 무엇인가 ── 도입은 1분이면 끝난다

Process Monitor는 Sysinternals 도구군 중 하나로, 파일 시스템·레지스트리·프로세스/스레드의 활동을 실시간으로 표시하는 모니터링 도구입니다. 과거의 Filemon과 Regmon이라는 두 도구를 통합·강화한 후속 제품으로, 이벤트별 상세 정보, 비파괴적인 Filter, 스레드 스택 기록, 부트 타임 로깅 등을 갖추고 있습니다.¹

도입은 간단합니다. 설치 프로그램은 없으며, 다운로드 페이지에서 ZIP을 받아 압축을 풀고 Procmon.exe를 실행하기만 하면 됩니다. 급하게 조사할 때는 Sysinternals Live라는 서비스를 이용해 https://live.sysinternals.com/procmon.exe에서 직접 실행할 수도 있습니다.² 처음 실행할 때 사용권 계약 동의를 요구받으며, 커널 드라이버를 로드하기 때문에 관리자 권한(UAC 상승)이 필요합니다. 관리자 권한이 왜 필요한가 하는 일반론은 「Windows의 관리자 권한이 필요한 시점」에 쓴 대로이며, OS 전체의 이벤트를 보는 도구는 전형적으로 「권한 상승이 필요한」 쪽에 속합니다.

실행한 순간부터 캡처가 시작되어, 화면에 이벤트가 흘러가기 시작합니다. 주요 조작은 세 가지만 기억하면 충분합니다.

한 줄의 이벤트는 「Time(시각)·Process Name(프로세스)·PID·Operation(조작)·Path(대상 경로)·Result(결과)·Detail(상세)」로 구성됩니다. Operation은 CreateFile(파일을 열기/만들기), ReadFile/WriteFile, RegOpenKey/RegQueryValue 등 Win32 API에 대략 대응하는 세분화 단위입니다. 즉 ProcMon의 로그는 「애플리케이션과 OS의 대화 기록」이며, 애플리케이션이 설정 파일을 읽으려고 했는데 실제로는 어디를 읽었는가 하는 「의도」와 「실제」의 차이가 그대로 보입니다.

3. Filter ── ProcMon은 좁힌 다음에 읽는 도구

아무것도 하지 않고 캡처하면, 유휴 상태의 Windows에서도 초당 수천 건의 이벤트가 흘러갑니다. ProcMon의 실용성은 Filter 사용법으로 결정된다고 해도 좋으며, 정석은 다음의 2단계입니다.

1단계: 프로세스로 좁힌다. Ctrl+L로 Filter 대화상자를 열고, Process Name / is / myapp.exe / Include를 추가합니다. 툴바의 조준 아이콘을 대상 애플리케이션 창으로 드래그하여 해당 프로세스에만 Filter를 거는 방법도 있습니다.

2단계: Result나 Operation으로 좁힌다. 「실패하고 있는 조작을 찾고 싶다」면 Result / is not / SUCCESS / Include(이상 계열만 표시). 「쓰기만 보고 싶다」면 Category / is / Write / Include. 「이 설정 파일을 건드리고 있는 것은 누구인가」라면 프로세스로 좁히지 않고 Path / contains / app.config / Include, 이런 식입니다.

또한 실무에서 자주 사용하는 것이 이벤트 행을 우클릭하는 대화식 축소입니다. 목적에 가까운 행을 하나 발견하면, 우클릭하여 「Include ‘this path’」「Exclude ‘this process’」를 선택하기만 하면, 대화상자를 열지 않고도 Filter가 계속 쌓여갑니다. 노이즈 원인(백신 소프트웨어, 인덱서 등)을 Exclude로 지워 나가며, 목적하는 조작의 전후만 남기는 것이 기본 동작입니다. 육안 확인을 돕는 데는 하이라이트(Ctrl+H)도 사용할 수 있습니다. Filter와 동일한 조건식으로 행에 색을 입힐 수 있으므로, 「전체 흐름은 보고 싶지만 이상 계열만 눈에 띄게 하고 싶다」는 경우에는 Filter가 아니라 하이라이트를 사용합니다.

모르면 헤매게 되는 사양이 세 가지 있습니다.

• Filter는 화면 표시의 축소일 뿐, 기록의 축소가 아닙니다. 뒤에서는(기본값으로는) 전체 이벤트가 기록되고 있으며, Filter를 해제하면 언제든 전체로 돌아갈 수 있습니다. 비파괴 Filter라고 불리는 이유이며, 「너무 좁혀서 증거를 놓치는」 일이 잘 일어나지 않는 설계입니다.¹
• Filter 설정은 다음 실행 시에도 그대로 이어집니다. 이전 조사의 Filter가 남은 채로 「아무것도 표시되지 않는다」며 고민하는 것은 누구나 한 번은 겪는 일입니다. 화면 표시가 이상하다고 느껴지면 우선 Filter 메뉴의 Reset Filter(Ctrl+R)를 의심해 보십시오.
• 기본값으로 몇 가지 Exclude가 들어가 있습니다. ProcMon 자체나 페이징 I/O 등은 처음부터 제외되어 있습니다. 「시스템 전체를 빠짐없이」가 요건인 조사에서는 기본 Filter의 존재를 의식하십시오.

4. Result 열을 읽는 법 ── 이상하게 보이지만 정상인 것

Filter로 이상 계열을 좁히면, 이번에는 「이상해 보이는 결과」가 대량으로 나와서 놀라게 됩니다. 여기서 중요한 것은 Result 열의 이상값 대부분은 정상 동작의 일부라는 점입니다. 주요 Result를 읽는 법을 정리합니다.

이 중 조사의 주역이 되는 것은 NAME NOT FOUND·ACCESS DENIED·SHARING VIOLATION 세 가지입니다. 각각 대표적인 조사 패턴이 있으므로, 다음 장에서 증상 쪽에서부터 살펴보겠습니다.

반대로 놓치기 쉬운 것이 「SUCCESS가 원인」인 패턴입니다. 예를 들어 「수정한 설정 파일이 반영되지 않는다」의 답이 다른 위치에 있는 오래된 설정 파일에 대한 SUCCESS였던 경우는 한두 번이 아닙니다. 이상 계열만 보고 있으면 정상적으로 읽힌 「잘못된 정답」을 놓치게 되므로, Path로 좁혀서 해당 파일 종류에 대한 접근을 성공까지 포함하여 전부 확인하는 것이 확실합니다.

5. 증상별 대표적인 조사 패턴

5.1 「설정을 수정했는데 반영되지 않는다」── 어디에서 읽고 있는지 특정하기

Path / contains / 설정 파일명으로 Include를 걸고 애플리케이션을 실행하면, 애플리케이션이 그 이름의 파일을 어느 폴더에서, 어떤 순서로 찾았는지가 목록으로 나타납니다. 흔한 진상은 다음 중 하나입니다.

• exe와 같은 폴더가 아니라 %APPDATA%나 ProgramData 아래의 사본을 읽고 있었다(최초 실행 시 복사하는 설계였다)
• 32비트 프로세스로부터의 레지스트리·시스템 폴더 접근이 WOW64 리디렉션을 받아, 보고 있다고 생각한 위치와 실제 위치가 어긋나 있었다
• 설치 대상인 Program Files 아래로의 쓰기가 가상화(VirtualStore)되어, 읽기·쓰기가 다른 위치로 바뀌어 있었다

어느 쪽이든 ProcMon이라면 Path에 전체 경로가 나오므로 한눈에 알 수 있습니다. 설정 파일을 어디에 배치하도록 설계해야 하는가라는 뒷면의 이야기는 「appsettings.json만이 아니다 ── 구성 관리의 실무」에 썼습니다.

5.2 「이 환경에서만 실행되지 않는다」── DLL 탐색을 추적하기

실행 직후에 다운되거나, 「DLL을 찾을 수 없습니다」 계열의 오류가 나오는 경우에는, 프로세스로 Include한 상태에서 Path / ends with / .dll을 추가하여 NAME NOT FOUND의 연쇄를 살펴봅니다. Windows의 DLL 탐색은 정해진 순서로 폴더를 따라가므로, ProcMon 로그에는 「탐색 순서대로 NAME NOT FOUND가 나열되고, 어딘가에서 SUCCESS한다(또는 끝까지 발견되지 않는다)」는 형태가 그대로 나타납니다. 끝까지 SUCCESS하지 않는 DLL이 범인입니다. 반대로 「SUCCESS하고 있지만, 의도하지 않은 위치의 오래된 DLL을 붙잡고 있다」는 패턴도 여기서 발견됩니다. 탐색 순서의 원리는 「Windows DLL 이름 해석의 구조」를 함께 읽어 보십시오.

COM/ActiveX 관련의 「클래스가 등록되어 있지 않습니다」도 같은 유형으로, RegOpenKey의 CLSID 아래로의 NAME NOT FOUND로 관측할 수 있습니다. 32비트/64비트를 혼동하여 다른 뷰의 레지스트리를 보러 가는 사고는, 「Office 2024/Microsoft 365에서 ActiveX가 동작하지 않는 원인과 확인 절차」에 쓴 절차대로 ProcMon이 가장 빠릅니다.

5.3 「ACCESS DENIED가 발생한다」── 누구의 권한으로 동작하고 있는지 의심하기

ACCESS DENIED를 발견하면, 그 이벤트를 더블클릭하여 Process 탭을 확인합니다. 그 프로세스가 어떤 사용자로 동작하고 있었는가가 나오므로, 「서비스는 SYSTEM이 아니라 제한된 서비스 계정으로 동작하고 있었다」「작업 스케줄러로 실행했을 때만 다른 사용자였다」라는 불일치가 여기서 밝혀집니다. 대상이 파일이라면, 해당 경로의 ACL과 대조하면 원인이 확정됩니다. 또한 백신 소프트웨어가 개입하고 있는 경우에는, 직전 직후에 다른 프로세스(백신의 엔진)가 같은 경로를 건드리고 있는 모습이 보이는 경우가 많으며, 이것도 시계열로 기록하는 ProcMon만의 증거가 됩니다.

5.4 「가끔 파일 처리가 실패한다」── SHARING VIOLATION의 상대를 찾기

공유 위반은 시계열이 생명인 조사입니다. Path로 Include를 걸고 프로세스 Filter는 걸지 않은 채 캡처하면, 실패 순간에 같은 파일을 누가 열고 있었는가가 앞뒤 행에 나타납니다. 백업 소프트웨어·백신·Excel의 잔류 프로세스 정도가 단골 상대입니다. 파일 연계에서 이러한 경합을 애초에 일으키지 않는 설계는 「파일 연계의 배타 제어 기초 지식」에, Excel 프로세스가 남는 문제는 「C#의 Excel 조작에서 EXCEL.EXE가 남는 문제」에 정리해 두었습니다. 「지금 이 순간, 누가 잡고 있는가」만 알고 싶다면, ProcMon보다 Process Explorer의 핸들 검색(Ctrl+F)이 더 빠르다는 점도 덧붙여 둡니다.³

5.5 「실행이 느리다」── 어디에서 시간을 잡아먹고 있는지 짐작하기

열 설정에서 Duration 열을 추가하면, 개별 조작에 걸린 시간을 볼 수 있습니다. 또한 Tools 메뉴의 Process Activity Summary나 File Summary로, 프로세스·파일별 조작 횟수와 시간을 집계할 수 있습니다. 「실행 시 수만 번의 레지스트리 읽기를 하고 있었다」「네트워크 너머 경로로의 접근이 타임아웃까지 대기하고 있었다」와 같은 짐작에는 충분합니다. 다만 CPU를 어디에서 사용하고 있는지에 대한 본격적인 프로파일링은 ProcMon의 영역이 아닙니다. I/O가 아니라 연산 때문에 느린 경우에는 PerfView와 dotnet-trace로 넘어갑니다.

5.6 부팅 시·로그온 시의 문제 ── 부트 로깅

「서비스가 로그온 전에 실패한다」「시작 프로그램에 등록한 애플리케이션이 실행되지 않는다」와 같이, ProcMon을 손으로 실행하기도 전에 문제가 발생하는 경우에는 Options 메뉴의 Enable Boot Logging을 사용합니다. 다음 부팅 시 부트 초기부터의 이벤트가 기록되며, 그 다음에 ProcMon을 실행했을 때 저장하라는 안내를 받습니다. 부트 타임 로깅은 ProcMon의 공식 기능으로 제공되는 것으로,¹ 시작 순서·로그온 스크립트 관련 조사에서는 이것이 유일한 눈입니다.

6. 로그 저장과 전달 ── 고객 환경에서 채취를 부탁하는 경우

불량 조사 실무에서는, 재현되는 환경이 고객 측에만 있는 경우가 드물지 않습니다. ProcMon 로그는 PML 파일로 저장할 수 있고, 다른 컴퓨터에서 열어도 모든 열·모든 상세 정보를 볼 수 있으므로, 「고객이 채취하고, 이쪽에서 분석한다」는 분업이 성립합니다. 의뢰할 때의 절차서는 다음과 같은 형태로 만들고 있습니다.

1. Procmon.exe를 관리자 권한으로 실행하고, 사용권 계약에 동의한다
2. 실행되면 일단 Ctrl+E로 캡처를 정지하고, Ctrl+X로 화면 표시를 지운다
3. Ctrl+E로 캡처를 시작하고, 문제의 조작을 재현한다
4. 재현되면(또는 오류가 발생하면) 즉시 Ctrl+E로 정지한다
5. File > Save에서 Events displayed using current filter가 아니라 All events를 선택하여 PML 형식으로 저장하고, ZIP으로 압축하여 전송한다

포인트는 5번의 「All events」입니다. 상대방 화면에 Filter가 남아 있더라도, 기록 자체는 전량 있으므로 이쪽에서 자유롭게 다시 좁힐 수 있습니다. 재현에 시간이 걸리거나 언제 발생할지 모르는 문제에서는, 그대로 두면 메모리를 계속 소비하게 되므로, Filter > Drop Filtered Events를 활성화하여 대상 프로세스만 기록하거나, File > Backing Files에서 저장 위치를 가상 메모리가 아니라 파일로 전환하는 것 중 적어도 하나를 지정합니다. 이 두 가지를 모르고 밤새 실행해 두면, 메모리를 다 써버려서 조사 대상보다 먼저 ProcMon이 한계를 맞이합니다.

자동화하고 싶은 경우에는 명령줄 스위치도 사용할 수 있습니다. /AcceptEula로 동의 대화상자를 억제하고, /BackingFile로 기록 대상 파일을 지정, /Runtime으로 초 단위 지정 자동 정지, /Terminate로 실행 중인 ProcMon을 종료, 이러한 조합으로 「장애 발생 시 운영자가 배치 파일을 하나 실행하면 증거가 남는」 형태로 만들 수 있습니다. 장애 시 무엇을 채취할 것인지 미리 정해 두는 사고방식은, 크래시 덤프 수집이나 이벤트 로그 설계와 공통됩니다.

7. ProcMon의 한계와 다른 도구와의 구분 사용

ProcMon은 「조작의 시계열」을 보는 도구이며, 모든 조사에 적합한 것은 아닙니다. 당사 조사에서의 역할 분담은 다음과 같습니다.

경계에서 헷갈리기 쉬운 것은 다음의 세 가지입니다.

• 네트워크: ProcMon은 TCP/UDP의 연결·송수신 이벤트(어떤 프로세스가 어디와 통신했는가)는 기록하지만, 패킷의 내용은 볼 수 없습니다. 프로토콜 조사는 Wireshark나 Windows 표준 pktmon으로.⁴
• 메모리: 「메모리 사용량이 계속 증가한다」는 ProcMon으로는 추적할 수 없습니다. 매니지드 힙이라면 GC인지 누수인지 판별, 핸들이라면 핸들 누수 조사 절차로 넘어갑니다.
• 스택: 사실 ProcMon도 각 이벤트를 발행한 스레드 스택을 기록하고 있어서(이벤트를 더블클릭 → Stack 탭), 심볼을 설정하면 「누가 이 파일 접근을 발행했는가」를 코드 수준에서 특정할 수 있습니다. 여기까지 오면 WinDbg의 세계와 이어져 있어서, 심볼(PDB) 관리가 중요해집니다.

8. 정리 ── 「코드를 읽기 전에, 사실을 본다」

환경 의존적인 불량 조사에서 가장 먼저 해야 할 일은, 코드를 읽는 것도 가설을 세우는 것도 아니라, 실제로 무슨 일이 일어났는지의 기록을 확보하는 것입니다. ProcMon은 그것을 위한 최단 경로로, 도입 1분·캡처 몇 분 만에 「어느 경로를·어떤 순서로·어떤 권한으로 건드려서·무엇에 실패했는가」라는 움직일 수 없는 사실을 얻을 수 있습니다. Filter의 2단계(프로세스 → Result), 이상하게 보이지만 정상인 Result를 읽는 법, 전체 이벤트 저장을 통한 전달──이 세 가지만 짚어 두면, 「개발 머신에서는 재현되지 않습니다」로 멈춰 있던 조사가 그날 안에 한 걸음 나아갑니다.

당사에서는 재현 조건을 알 수 없는 불량 조사, 고객 환경에서만 발생하는 장애의 증거 채취 절차 정비, ProcMon·WinDbg·PerfView를 조합한 원인 분석을 담당하고 있습니다. 「로그에는 아무것도 나오지 않지만 동작하지 않는다」는 단계에서부터도 도와드릴 수 있습니다.

관련 글

• WinDbg + SOS로 크래시 덤프 읽기 ── 수집 후 실무 분석 입문
• PerfView와 dotnet-trace로 “느리다”를 특정하기 ── .NET 성능 조사 실무 입문
• Windows 크래시 덤프 수집 입문 - WER/ProcDump/WinDbg
• Windows DLL 이름 해석의 구조 - 검색 순서와 SxS
• 산업용 카메라 장기 가동 크래시 조사 - 핸들 누수 편

관련 상담 분야

합동회사 코무라소프트에서는 환경 의존적이라 재현하기 어려운 불량의 원인 조사, 장애 시 증거 채취 절차 정비, 기존 Windows 애플리케이션의 문제 해결 지원을 다루고 있습니다.

• 불량 조사·원인 분석
• 기술 상담·설계 리뷰
• 기존 Windows 소프트웨어 개수·유지보수
• 문의하기

참고 자료

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

ProcMon을 운영(프로덕션) 환경에서 실행해도 괜찮습니까?

짧은 시간의 캡처라면 실무상 자주 이루어지지만, 무조건 안전한 것은 아닙니다. ProcMon은 드라이버를 로드하여 대량의 이벤트를 기록하기 때문에, 이벤트 발생량이 많은 서버에서는 CPU와 메모리를 눈에 띄게 소비합니다. 대책은 세 가지로, (1) 재현 조작 직전에 시작하여 직후에 정지하여 캡처 시간을 최소화한다, (2) 장시간 모니터링이 필요한 경우 Filter 메뉴의 Drop Filtered Events를 활성화하여 필터 밖의 이벤트를 보관하지 않는다, (3) 기록 위치를 메모리가 아닌 파일로 하는 Backing File을 설정한다, 입니다. 또한 업무 시간 외 실시나 스냅숏 취득 후 실시 등, 통상적인 변경 작업과 동일한 승인 프로세스를 거치는 것을 권장합니다.

이벤트가 너무 많아서 원하는 행을 찾을 수 없습니다. 어떻게 좁혀야 합니까?

먼저 Process Name으로 대상 프로세스에만 Include를 걸고, 다음으로 Result에서 이상 계열(NAME NOT FOUND, ACCESS DENIED 등)로 좁히는 것이 정석입니다. 원하는 행을 하나 발견하면, 그 행을 우클릭했을 때 표시되는 Include나 Exclude로 대화식으로 좁혀 나갑니다. 반대로 「필터를 건 채로 저장했다가 정보가 부족했다」는 실패도 많으므로, 로그를 파일로 저장하여 다른 사람에게 전달할 경우에는 필터는 어디까지나 화면 표시상의 축소일 뿐임을 의식하여 전체 이벤트를 저장하십시오. 또한 필터 설정은 다음 실행 시에도 그대로 이어지기 때문에, 「아무것도 표시되지 않는다」고 느껴질 때는 이전의 오래된 필터가 남아있지 않은지 Filter 메뉴의 Reset Filter로 확인하십시오.

Result 열의 BUFFER OVERFLOW는 버그나 공격의 징후입니까?

아닙니다. 보안 용어인 버퍼 오버플로 공격과는 무관하며, 「호출 측이 준비한 버퍼보다 필요한 데이터가 컸기 때문에 필요한 크기를 돌려주었다」는 정상적인 API 왕복입니다. 많은 API는 처음에 작은 버퍼로 호출하여 필요한 크기를 알려받은 뒤, 다시 확보하여 재호출하는 설계이므로, 직후에 같은 경로로의 SUCCESS가 이어진다면 문제없습니다. 마찬가지로 NAME NOT FOUND도 「탐색 순서 도중에 발견되지 않았다」는 것뿐인 경우가 많으며, 최종적으로 어딘가에서 SUCCESS하고 있다면 이상이 아닙니다. 이상 계열의 Result는 「그 조작의 실패가 애플리케이션의 증상과 인과적으로 연결되어 있는가」까지 확인해야 비로소 원인이라고 말할 수 있습니다.

Process Explorer와 Process Monitor는 어떻게 구분하여 사용합니까?

Process Monitor는 「조작의 흐름(언제·어느 프로세스가·어느 경로에·무엇을 하여·어떻게 되었는가)」을 시계열로 기록하는 도구이고, Process Explorer는 「지금 이 순간의 상태(어느 프로세스가 어떤 파일이나 DLL을 열고 있는가, CPU·메모리 사용 현황)」를 보는 도구입니다. 예를 들어 「이 파일을 삭제할 수 없다. 누가 잡고 있는가」를 알고 싶다면 Process Explorer의 핸들 검색이 가장 빠르고, 「애플리케이션이 이 파일을 언제·어떤 순서로 읽고 있는가」를 알고 싶다면 Process Monitor입니다. 실무에서는 둘 다 Sysinternals Suite로 항상 준비해 두고, 상태는 Process Explorer, 이력은 Process Monitor라고 기억해 두면 헷갈리지 않습니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.