경력 있는 Windows 관리자라면 누구나 WMI(Windows Management Instrumentation) 서비스와 그 구성 요소에서 발생하는 문제를 한 번쯤 겪어봤을 것입니다. WMI 하위 시스템에 문제가 생기면 Windows의 정상적인 운영 전반에 심각한 영향을 미치기 때문에, 관리자는 최대한 빨리 WMI의 정상 작동 여부를 점검하고 복구해야 합니다. 이 글에서는 Windows 10 및 Windows Server 2016/2019 환경에서 WMI 문제를 비교적 간단하게 진단하고 해결하는 방법을 단계별로 소개합니다.
WMI 문제의 주요 증상
WMI에 문제가 있다면 다음과 같은 다양한 오류가 나타날 수 있습니다.
- 시스템 및 응용 프로그램 로그에서 WMI 쿼리 처리 오류 발생 (
0x80041002 - WBEM_E_NOT_FOUND,WMI: Not Found,0x80041010 WBEM_E_INVALID_CLASS) - GPO 처리 오류 — 그룹 정책의 WMI 필터가 제대로 작동하지 않는 경우 등
- WMI 쿼리 응답이 비정상적으로 느려지는 현상
- SCCM/SCOM 에이전트 설치 또는 운영 중 오류
- Get-WmiObject 등 WMI 네임스페이스를 사용하는 VBS 또는 PowerShell 스크립트 오류
WMI 문제 해결: 기본 점검
가장 먼저 Windows Management Instrumentation(Winmgmt) 서비스가 설치되어 있고 실행 중인지 확인해야 합니다. services.msc 콘솔에서 확인하거나 PowerShell로 다음 명령을 실행하면 됩니다.
Get-Service Winmgmt | Select DisplayName,Status,ServiceName
Winmgmt 서비스가 정상적으로 실행 중이라면, 간단한 WMI 쿼리로 WMI 상태를 테스트할 수 있습니다. 명령 프롬프트나 PowerShell 어디에서든 WMI 요청을 실행해 보세요. 예를 들어 다음 명령은 Windows에 설치된 프로그램 목록을 출력합니다.
wmic product get name,version
PowerShell에서 WMI를 통해 Windows 10의 버전과 빌드 정보를 가져오는 가장 간단한 명령은 다음과 같습니다.
get-wmiobject Win32_OperatingSystem
위와 같이 WMI 서비스가 요청에 정상적으로 응답하면 문제가 없는 것입니다. 반대로 이러한 WMI 쿼리 실행 시 오류가 반환된다면, WMI 서비스가 올바르게 작동하지 않거나 WMI 리포지토리가 손상되었거나, 그 밖의 다른 문제가 있을 가능성이 높습니다.
실제 사례를 들면, 컴퓨터 관리 스냅인(compmgmt.msc)에서 WMI 컨트롤 속성을 열 때 다음과 같은 메시지가 표시되는 경우가 있습니다.
Failed to initialize all required WMI classes Win32_Processor. WMI: Invalid namespace Win32_WMISetting. WMI: Invalid namespace Win32_OperationSystem. WMI: Invalid namespace
WMIDiag 진단 도구 활용하기
예전에는 Microsoft 공식 진단 도구인 WMIDiag.vbs(Microsoft WMI Diagnosis)를 사용해 WMI를 진단했습니다. WMIDiag는 VBS 스크립트로, WMI의 다양한 하위 시스템을 검사하고 수집한 정보를 로그 파일로 저장합니다. 기본 로그 위치는 %TEMP% 폴더, 즉 C:\USERS\%USERNAME%\APPDATA\LOCAL\TEMP\입니다. 생성되는 보고서는 WMIDIAG-V2.2로 시작하는 파일들로 구성되며 다음과 같은 유형이 있습니다.
- LOG 파일: WMIDiag 도구의 동작 및 작업 과정에 대한 상세 보고서
- TXT 파일: 발견된 오류 중 주목해서 살펴볼 항목을 요약한 보고서
- CSV 파일: WMI 성능의 장기 분석에 필요한 정보
팁: x64 버전 Windows에서는 wmidiag를 반드시 다음과 같이 실행해야 합니다.
c:\windows\System32\cscript.exe wmidiag.vbs
그렇지 않으면 아래와 같은 오류가 발생합니다.
WMIDiag must be run from native 64-bit environment. It is not supported in Wow64.
WMIDiag 실행이 끝나면 관리자는 로그 파일을 검토·분석하여 발견된 오류를 수정해야 합니다.
다만 안타깝게도 WMIDiag의 마지막 버전인 2.2는 Windows 8.1/Windows Server 2012 R2까지만 정상적으로 작동합니다. 현재 Microsoft는 다운로드 센터에서 WMIDiag 다운로드 링크조차 제거한 상태이며, 필요하다면 웹에서 스크립트를 찾아볼 수는 있습니다.
WMIDiag는 WMI의 로컬 오류를 수정하는 방법을 상세히 알려주지만, 대부분의 경우 시간이 많이 걸리는 작업이므로 중요 시스템(주로 운영 서버)의 문제를 추적할 때만 그만한 가치가 있습니다. 일반 사용자 워크스테이션이라면 차라리 WMI 리포지토리를 초기화하고 재구축하는 편이 훨씬 빠르고 간단합니다.
WMI 리포지토리 복구 및 MOF 파일 재컴파일
Windows 10/Windows Server 2016에서는 다음 명령으로 WMI 리포지토리의 무결성을 확인할 수 있습니다.
winmgmt /verifyrepository
명령 결과 WMI 데이터베이스가 일관되지 않은 상태(INCONSISTENT 또는 WMI repository verification failed)라고 표시되면, 먼저 소프트웨어 수준의 WMI 리포지토리 오류 수정을 시도해 보세요.
Winmgmt /salvagerepository
WMI repository has been salvaged.
이 명령은 WMI 리포지토리의 일관성을 검사하고, 불일치가 발견되면 WMI 데이터베이스를 재구축합니다.
그다음 WMI 서비스를 재시작합니다.
net stop Winmgmt
net start Winmgmt
DLL 재등록 및 MOF 재컴파일 스크립트
표준 복구 방법으로 해결되지 않는다면 아래 스크립트를 사용해 보세요. 이 스크립트는 컴퓨터의 WMI 서비스를 "소프트"하게 복구하는 방식으로, DLL 라이브러리와 WMI를 다시 등록하고 MOF 파일을 재컴파일합니다. 이 절차는 안전하며, 운영체제에 추가적인 문제를 일으키지 않습니다.
sc config winmgmt start= disabled
net stop winmgmt
cd %windir%\system32\wbem
for /f %s in ('dir /b *.dll') do regsvr32 /s %s
wmiprvse /regserver
sc config winmgmt start= auto
net start winmgmt
for /f %s in ('dir /b *.mof') do mofcomp %s
for /f %s in ('dir /b *.mfl') do mofcomp %s
64비트 Windows에서는 SysWOW64 디렉터리에 대해서도 동일한 작업을 수행해야 합니다. 스크립트의 세 번째 줄을 다음과 같이 바꿔 한 번 더 실행하세요.
cd %windir%\SysWOW64\wbem
이 명령들은 명령 프롬프트에 직접 붙여넣어 실행할 수도 있고, BAT 파일(wmi_soft_repair.bat)로 저장한 뒤 관리자 권한으로 실행할 수도 있습니다. 스크립트 실행이 끝나면 Windows를 재시작하고 WMI가 정상 작동하는지 확인하세요.
WMI 리포지토리 재구축
앞서 소개한 방법으로도 해결되지 않는다면, WMI 리포지토리를 새로 생성하는 더 "강력한" 복구 방법을 사용해야 합니다.
WMI 리포지토리는 %windir%\System32\Wbem\Repository에 위치하며, WMI 클래스의 메타데이터와 정의 정보를 담고 있는 데이터베이스입니다. 경우에 따라 정적 클래스 정보도 함께 포함됩니다. 리포지토리가 손상되면 WMI 서비스(Winmgmt)의 동작 전반에서 오류가 발생합니다.
WMI 리포지토리가 손상된 것으로 의심되더라도, 리포지토리 재생성은 다른 어떤 복구 방법으로도 WMI를 되살릴 수 없을 때만 사용해야 하는 최후의 수단이라는 점을 기억하세요.
다음 명령은 WMI 데이터베이스를 Windows 클린 설치 직후의 초기 상태로 되돌립니다. salvagerepository 매개변수로 문제가 해결되지 않았을 때 하드 리셋 용도로 사용하세요.
Winmgmt /resetrepository
팁: 실제로 WMI 리포지토리를 재구축하면 서드파티 소프트웨어에 문제가 생기는 사례가 있습니다. 그 이유는 WMI 데이터베이스의 모든 레코드가 삭제되어(클린 시스템 상태로 초기화) 해당 소프트웨어가 등록해 둔 정보가 사라지기 때문입니다. 이 경우 복구 모드로 소프트웨어를 다시 설치해야 할 수 있습니다.
두 명령(Winmgmt /salvagerepository와 Winmgmt /resetrepository) 모두로도 WMI 데이터베이스의 일관된 상태가 복원되지 않는다면, 다음 스크립트로 WMI 데이터베이스를 강제 초기화해 보세요.
sc config winmgmt start= disabled
net stop winmgmt
cd %windir%\system32\wbem
winmgmt /resetrepository
winmgmt /resyncperf
if exist Repos_bakup rd Repos_bakup /s /q
rename Repository Repos_bakup
regsvr32 /s %systemroot%\system32\scecli.dll
regsvr32 /s %systemroot%\system32\userenv.dll
for /f %s in ('dir /b *.dll') do regsvr32 /s %s
for /f %s in ('dir /b *.mof') do mofcomp %s
for /f %s in ('dir /b *.mfl') do mofcomp %s
sc config winmgmt start= auto
net start winmgmt
wmiprvse /regserver
64비트 Windows에서는 %windir%\sysWOW64\wbem 디렉터리의 DLL/EXE도 다시 등록하고 MOF 파일도 재컴파일해야 합니다.
이 스크립트는 WMI 리포지토리 폴더를 완전히 삭제하고 새로 생성합니다. 기존 리포지토리는 Repos_backup 디렉터리에 백업되므로, 문제가 생기면 되돌릴 수 있습니다. 스크립트 실행 후에는 Windows를 재시작하고, 간단한 쿼리로 WMI 서비스를 점검하세요.
마지막으로 WMI 리포지토리 상태를 확인합니다. 오류가 해결되었다면 winmgmt /verifyrepository 명령이 다음을 반환해야 합니다.
WMI repository is consistent
이 글에서는 WMI 서비스와 리포지토리를 진단하고 문제를 해결하는 기본적인 방법들을 살펴보았습니다. 소프트 복구(salvagerepository)부터 하드 리셋(resetrepository), MOF 재컴파일까지 단계적으로 적용하면 대부분의 WMI 오류를 안정적으로 해결할 수 있습니다.