작업 관리자의 세부 정보 탭을 이름순으로 정렬하고 내리다 보면, s 근처에서 한참 동안 같은 이름만 이어진다. svchost.exe. 확인한 시점에 내 PC 에서는 101줄이었다. 전체 프로세스가 484개였으니 다섯에 하나꼴이다.

이 연재는 작업 관리자에서 "왜 이렇게 많지", "왜 CPU 를 먹지" 싶은 Windows 프로세스를 하나씩 열어 보는 기록이다. 첫 번째는 개수로 가장 먼저 눈에 띄는 svchost.exe 다.

101개가 모두 같은 파일이었다

먼저 정말 같은 파일인지부터 봤다. C:\Windows\System32\svchost.exe 는 88KB 의 작은 실행 파일이고, 파일 설명은 "Host Process for Windows Services", 서명은 Microsoft Windows 로 유효했다. 부모 프로세스도 101개 모두 같은 번호였고, 그 번호를 따라가면 services.exe 가 나왔다. 서비스 제어 관리자가 직접 띄운 것들이라는 뜻이다.

이름 그대로 svchost 는 서비스를 담는 그릇이다. Windows 서비스 상당수는 독립된 exe 가 아니라 DLL 로 만들어져 있고, DLL 은 혼자 실행될 수 없으니 누군가 불러 줘야 한다. 그 역할을 svchost.exe 가 한다. 서비스 설정에 적힌 실행 경로를 보면 이렇게 생겼다.

C:\WINDOWS\system32\svchost.exe -k netsvcs -p
C:\WINDOWS\system32\svchost.exe -k NetworkService -p
C:\WINDOWS\System32\svchost.exe -k LocalServiceNetworkRestricted -p

-k 뒤의 이름이 서비스 그룹이다. 작업 스케줄러(Schedule)와 WMI(Winmgmt)는 netsvcs, DNS 클라이언트(Dnscache)는 NetworkService, 이벤트 로그(EventLog)와 DHCP 클라이언트(Dhcp)는 LocalServiceNetworkRestricted 그룹이었다. 그룹은 어떤 계정 권한으로 돌지, 네트워크를 쓸 수 있는지 같은 조건이 비슷한 서비스끼리 묶은 것이다. 뒤의 -p 는 서명되지 않은 DLL 을 불러오지 못하게 하는 등 보호 정책을 거는 옵션으로 알려져 있다.

위 경로는 서비스 설정에서 읽은 것이다. 일반 권한으로는 svchost 프로세스 쪽 명령줄이 대부분 빈 값으로 나오고, 관리자 권한으로 보면 같은 명령줄이 보인다.

예전엔 묶여 있던 것이 왜 다 흩어졌나

예전 Windows 에서는 svchost 가 지금보다 훨씬 적었다. 같은 그룹의 서비스를 한 프로세스에 몰아 넣었기 때문이다. Windows 10 1703 부터 이 방식이 바뀌었다. 메모리가 일정 크기보다 큰 PC 에서는 그룹을 풀고 서비스를 하나씩 따로 띄운다. 그 기준이 레지스트리에 값으로 들어 있다.

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control' -Name SvcHostSplitThresholdInKB

내 PC 의 값은 3670016, KB 단위라 3.5GB 다. 이 PC 의 메모리는 47GB 남짓이니 기준을 한참 넘는다. 그래서 서비스가 거의 다 따로 떠 있었다. 실행 중인 svchost 기반 서비스를 그룹별로 세어 보니 이랬다.

서비스 그룹(-k) 실행 중 서비스 수
netsvcs 20
LocalSystemNetworkRestricted 17
LocalServiceNetworkRestricted 11
LocalService 9
NetworkService 6
그 밖의 그룹 30여 개 1~6

그룹은 30개가 넘지만 프로세스는 그룹 수가 아니라 서비스 수를 따라간다. 확인한 시점에 svchost 위에서 돌던 서비스 109개가 프로세스 100개에 나뉘어 있었고, 그중 96개는 서비스를 딱 하나만 담고 있었다. 예외는 일부 핵심 서비스다. DcomLaunch, PlugPlay, Power, BrokerInfrastructure, SystemEventsBroker 다섯 개는 여전히 한 프로세스에 모여 있었고, RpcSs 와 RpcEptMapper, 방화벽(mpssvc)과 BFE 도 둘씩 묶여 있었다. 서로 떼어 놓으면 오히려 문제가 되는 조합은 쪼개지 않도록 따로 지정해 둔 것으로 보인다.

나눠 띄우면 한 서비스가 죽어도 다른 서비스가 같이 쓰러지지 않고, 어떤 서비스가 CPU 나 메모리를 쓰는지 프로세스 단위로 바로 보인다. 대신 프로세스마다 기본 메모리가 든다. 101개의 작업 집합 합계는 약 1.5GB 였지만 공유 라이브러리가 중복으로 잡힌 값이고, 개인 메모리 합계는 약 600MB 였다. 메모리가 3.5GB 이하인 PC 는 예전처럼 묶어서 띄우므로 개수가 훨씬 적다.

개수는 고정도 아니다. 몇 분 뒤 다시 세어 보니 102개로 하나 늘어 있었다. 필요할 때만 켜졌다 꺼지는 서비스가 있고, 로그인한 사용자마다 따로 뜨는 서비스도 있어서다. 사용자별 서비스는 UnistoreSvc_ 처럼 이름 뒤에 밑줄과 무작위 문자가 붙는다.

tasklist /svc 로 어떤 서비스인지 찾기

svchost 하나하나가 무슨 서비스인지 보는 가장 빠른 방법은 명령 프롬프트나 PowerShell 에서 이것 한 줄이다.

tasklist /svc /fi "imagename eq svchost.exe"

Image Name                     PID Services
========================= ======== ============================================
svchost.exe                   2020 BrokerInfrastructure, DcomLaunch, PlugPlay,
                                   Power, SystemEventsBroker
svchost.exe                   1380 RpcEptMapper, RpcSs
svchost.exe                   2068 LSM
svchost.exe                   2260 HvHost
...

관리자 권한이 없어도 서비스 이름까지 나온다. 특정 번호 하나만 궁금하면 tasklist /svc /fi "pid eq 2020" 처럼 좁히면 된다.

작업 관리자로도 된다. 세부 정보 탭에서 svchost.exe 를 오른쪽 클릭해 "서비스로 이동"을 누르면 서비스 탭으로 넘어가 그 프로세스에 든 서비스가 선택된다. 프로세스 탭에서는 아예 "서비스 호스트:" 뒤에 서비스 이름을 달아서 보여 준다. 그러니 svchost 가 많다고 해서 정체를 모르는 상태로 둘 필요는 없다.

경로와 서명은 Runtime Broker 때와 같은 기준으로 본다. C:\Windows\System32 가 아닌 곳, 특히 사용자 폴더 아래에 svchost.exe 가 있거나, 부모가 services.exe 가 아니거나, 서명이 Microsoft Windows 가 아니라면 그때는 의심해야 한다.

CPU 를 먹는 svchost 의 범인 찾기

확인한 시점에 101개 svchost 의 CPU 를 성능 카운터로 3초 동안 재 보니, 다 합쳐도 전체의 1% 에 한참 못 미쳤다. 대부분은 이렇게 조용하다. 문제가 되는 건 하나가 몇 분씩 CPU 를 붙잡고 있을 때다.

순서는 간단하다. 작업 관리자 세부 정보 탭에서 CPU 열로 정렬해 높은 svchost 의 PID 를 확인하고, 위의 tasklist /svc 로 그 PID 에 든 서비스 이름을 본다. 자주 걸리는 이름은 이런 것들이다.

  • wuauserv, UsoSvc — Windows 업데이트. 업데이트를 받거나 설치를 준비할 때 한동안 바쁘다
  • DiagTrack, DPS — 사용 현황 수집과 진단 정책 서비스. 확인한 시점에 메모리를 가장 많이 쓴 svchost 가 DPS(작업 집합 69MB), 그다음이 DiagTrack(50MB)이었다
  • Winmgmt — WMI. 이 서비스가 바쁜 건 대개 다른 프로그램이 WMI 에 질의를 많이 보내서다
  • SysMain, BITS — 자주 쓰는 프로그램 미리 읽기, 백그라운드 전송

이름을 찾았다고 바로 서비스를 끄는 건 권하지 않는다. svchost 를 끝내면 그 안의 서비스가 모두 같이 죽고, DcomLaunch 가 든 프로세스라면 Windows 가 재시작을 요구한다. 업데이트 관련이면 설치가 끝날 때까지 기다리고, 매번 같은 서비스가 오래 잡고 있다면 그 이름으로 이벤트 뷰어 기록을 찾아보는 것이 원인에 가깝다. Winmgmt 처럼 남이 불러서 바빠지는 서비스는 부르는 쪽을 찾아야 한다.

서비스 전체 그림은 보안 연재의 서비스·드라이버·시작 프로그램 지도 편에서 다른 각도로 정리해 두었다.

다음 편은 svchost 다음으로 "CPU 를 먹는다"는 검색이 많은 Antimalware Service Executable, 곧 Microsoft Defender 의 MsMpEng.exe 다. 실시간 보호와 예약 검사가 언제 CPU 를 쓰는지 실제 기록으로 본다.