WMI가 동작하지 않음

WMI 스크립트 및 WMI 서비스 문제 해결

WMI는 상황에 따라 적절히 동작하는 탄력적인 소프트웨어입니다. 예를 들어 WMI 서비스가 중지된 상태에서 WMI 스크립트를 실행하려고 할 수 있습니다. 이 경우 어떤 일이 발생할까요? 스크립트가 실패하거나, 컴퓨터가 멈추거나, 공간이나 시간 구조에 문제가 생길까요? 그렇지 않습니다. WMI 서비스가 자체적으로 다시 시작되고 스크립트가 실행됩니다. 아마 사용자는 서비스가 중지되었었다는 사실조차 알아채지 못할 것입니다.

이러한 점은 스크립트 작성자가 다음과 같은 사항에 유의해야 한다는 것을 의미합니다. WMI 스크립트에 문제가 있는 경우 성급하게 WMI에 오류가 있다고 결론지어서는 안 된다는 것입니다. 스크립트가 동작하지 않는 것은 대개 WMI에 문제가 있기 때문이 아니라 스크립트에 문제가 있기 때문입니다. 물론 모든 WMI 구성 요소를 다시 등록하거나 WMI 리포지토리를 다시 빌드해야 하는 WMI 자체에 대한 오류가 발생했을 수도 있습니다. 하지만 이런 경우보다는 잘못된 네임스페이스를 입력하거나 로컬 관리자 권한이 없는 원격 컴퓨터에 연결하려고 하는 경우 등으로 인해 문제가 발생하게 되는 경우가 더 많습니다.

이 문서는 WMI 스크립트와 WMI 서비스 문제를 해결하는 데 도움을 주기 위해 Microsoft의 WMI 팀과 함께 작성한 것입니다. 여기서는 스크립팅에 대해 중점적으로 설명하겠지만 Systems Management Server(SMS)와 같은 다른 WMI 소비자에도 이와 동일한 문제 해결 정보를 적용할 수 있습니다. 스크립트, WMIC 명령줄, WMI를 호출하는 컴파일된 응용 프로그램(예: SMS) 등에서 어떤 것을 사용하다가 문제가 발생하든지에 관계없이 이와 관련된 시나리오와 생성된 오류 코드는 서로 동일한 경우가 많습니다.

이 문서에서 다루는 항목은 대략적인 순서대로 나열되어 있습니다. 예를 들어 마지막으로 취할 조치는 전체 리포지토리를 다시 빌드하는 것입니다. 그러나 WMI 스크립트와 WMI 서비스의 문제를 항상 단계별로 해결할 수 있는 것만은 아니라는 점을 알아 두어야 합니다. 따라서, 전체 문서를 읽어 보고 WMI 스크립트에서 발생할 수 있는 문제와 이를 해결하기 위해 수행할 수 있는 단계를 모두 숙지하는 것이 좋습니다.

또한 스크립트를 실행할 때 나타나는 모든 오류 메시지에 세심한 주의를 기울이는 것이 좋습니다. 이러한 오류 메시지는 WMI SDK (영문)에 설명되어 있으며 스크립트가 동작하지 않는 이유를 찾는 데 도움이 될 수 있습니다. 사실, 전체 문서를 읽어 보는 것이 좋지만 스크립트에서 생성되는 오류 메시지를 알고 있거나 문제가 보다 일반적인 시나리오 중 하나에 해당되는 경우에는 아래의 해당 항목으로 직접 이동할 수 있습니다.

이 페이지에서

스크립트에서 데이터를 반환하지 않습니다.

원격 컴퓨터에 연결할 수 없습니다.

0x8004100E("네임스페이스가 잘못되었습니다.") 오류가 발생합니다.

0x80041010("클래스가 잘못되었습니다.") 오류가 발생합니다.

속성이나 메서드가 지원되지 않는다는 오류(0x800A01B6)가 발생합니다.

네임스페이스, 클래스 및 속성 이름이 정확한지 확인했지만 스크립트가 여전히 동작하지 않습니다.

0x80041013("공급자를 찾을 수 없습니다.") 또는 0x80041014("구성 요소가 초기화하지 못했습니다.") 오류가 발생합니다.

공급자 등록과 관련하여 오류가 발생합니다.

스크립트가 올바르고 WMI 서비스가 실행되고 있으며 모든 .dll을 다시 등록했는데도 스크립트가 동작하지 않습니다.

WMI 리포지토리를 다시 빌드했지만 스크립트가 여전히 동작하지 않습니다.

스크립트에서 데이터를 반환하지 않습니다.

이런 경우 당황할 필요가 없습니다. 왜냐하면 WMI 스크립트는 데이터를 반환하지 않더라도 완벽하게 동작할 수 있기 때문입니다. 이것이 어떻게 가능한지 살펴보겠습니다. 예를 들어 컴퓨터에 설치된 모든 테이프 드라이브의 이름을 반환하는 다음 스크립트가 있습니다.

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colItems = objWMIService.ExecQuery("Select * from Win32_TapeDrive")

For Each objItem In colItems
    Wscript.Echo "Name: " & objItem.Name
Next

컴퓨터에 테이프 드라이브가 설치되어 있지 않다고 가정하면 이 스크립트는 아무런 정보도 반환하지 않게 됩니다. 이것은 당연한 결과입니다. 즉, 테이프 드라이브가 컴퓨터에 설치되어 있지 않으면 이 스크립트에서는 컴퓨터에 설치된 테이프 드라이브의 이름을 반환할 수 없습니다.

스크립트가 제대로 동작하지만 반환되는 데이터가 없는 이와 같은 상황을 확인하는 한 가지 방법은 Count 속성 값을 검색하는 것입니다. WMI 쿼리에서 반환하는 각 컬렉션에는 컬렉션의 항목 수를 나타내는 Count 속성이 포함되어 있습니다. 이것은 컬렉션에 항목이 없을 경우에도 적용되며 이 경우 Count는 0입니다. 예를 들어 다음은 컴퓨터에 설치된 테이프 드라이브의 수 즉, Win32_TapeDrive 인스턴스 수를 보고하는 스크립트입니다.

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colItems = objWMIService.ExecQuery("Select * from Win32_TapeDrive")

Wscript.Echo colItems.Count

Count가 0으로 나타나면 스크립트가 제대로 동작한다고 볼 수 있습니다. Count가 0보다 크면 테이프 드라이브가 하나 이상 설치되어 있다는 의미이므로 문제가 있는 것입니다. 이 경우에는 조건에 맞지 않는 WQL 쿼리를 작성한 것일 수 있습니다. 예를 들어 다음 스크립트는 현재 실행 중인 Alerter라는 이름의 모든 서비스에 대한 정보를 반환합니다.

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colItems = objWMIService.ExecQuery _
    ("Select * from Win32_Service Where Name = 'Alerter' and State = 'Running'")

For Each objItem In colItems
    WScript.Echo "Name: " & objItem.Name
Next

컴퓨터에서 Alerter 서비스가 중지되면 이 스크립트는 당연히 데이터를 반환하지 않습니다. 이것은 서비스가 두 가지 조건 즉, Name이 Alerter이고 State가 Running이어야 한다는 조건을 충족해야 하기 때문입니다.

데이터를 반환하는 스크립트를 작성하기 어려우면 WQL 쿼리를 단순화하는 것부터 시작합니다. 예를 들어 이 스크립트에서는 Where 절을 제거하고 컴퓨터에 설치된 각 서비스의 Name과 State를 보고하도록 작성하면 됩니다.

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colItems = objWMIService.ExecQuery ("Select * from Win32_Service")

For Each objItem In colItems
    WScript.Echo objItem.Name, objItem.State
Next

이 스크립트를 실행하여 Alerter 서비스의 이름과 상태를 확인한 다음 필요한 경우 Where 절을 조정하고 다시 실행할 수 있습니다. 모든 Windows 컴퓨터(Windows 98 컴퓨터는 제외)에는 최소한 몇 가지 서비스가 설치되어 있으므로 앞의 스크립트는 항상 어느 정도의 데이터를 반환합니다. 그렇지 않은 경우에는 보다 심각한 문제가 있는 것이므로 이후 내용을 계속 읽어 보아야 합니다.

페이지 위쪽

원격 컴퓨터에 연결할 수 없습니다.

로컬 컴퓨터에서는 잘 동작하지만 원격 컴퓨터에 연결하려는 순간 다음과 비슷한 오류 메시지를 표시하는 스크립트가 종종 있습니다.

이와 비슷한 메시지를 받은 경우 로컬 컴퓨터나 원격 컴퓨터의 WMI 서비스에 문제가 발생한 것일 수 있습니다. 그러나 대개는 이 경우에 해당되지 않습니다. 대신, 원격 컴퓨터에 연결할 때 문제가 발생한다면 일반적으로 다음 시나리오 중 하나에 해당됩니다.

• 원격 컴퓨터가 온라인이 아닙니다. 때때로 아주 간단한 사항이 해답이 될 수 있습니다. 컴퓨터가 오프라인이라면 WMI뿐 아니라 다른 어떤 방법으로도 컴퓨터에 연결할 수 없습니다. "원격 컴퓨터가 없거나 사용할 수 없습니다."라는 오류가 발생하면 가장 먼저 컴퓨터가 실제로 온라인인지 확인해야 합니다. 원격 컴퓨터에 ping을 수행하거나 명령줄 또는 GUI 도구를 사용하여 연결해 봄으로써 컴퓨터가 온라인 상태인지 확인할 수 있습니다. WMI 서비스보다는 네트워크와 관련하여 문제가 발생하는 것이 더 일반적입니다. 따라서 WMI 문제를 살펴보기 전에 네트워크 문제를 조사해 보아야 합니다.

• 원격 컴퓨터에 대해 로컬 관리자 권한이 없습니다. 일반 사용자 즉, 관리자가 아닌 사용자는 로컬 컴퓨터에서 제한적으로 WMI 스크립트를 실행할 수 있습니다. 이러한 사용자는 일반적으로 WMI를 사용하여 정보를 검색할 수는 있지만 설정을 변경할 수는 없습니다. 그러나 원격 컴퓨터에 연결할 때는 이 사항이 적용되지 않습니다. 원격으로 WMI를 사용하려면 원격 컴퓨터에 대해 로컬 관리자 권한을 가지고 있어야 합니다. 그렇지 않을 경우 해당 컴퓨터에 대한 액세스가 거부됩니다.

  물론 이러한 사항이 항상 적용되는 것은 아닙니다. 로컬 관리자가 아닐지라도 WMI 네임스페이스에 대한 액세스가 허용되는 경우가 있습니다. 이러한 경우는 매우 드물지만 가능합니다. 네임스페이스 보안을 확인하려면 내 컴퓨터 아이콘을 마우스 오른쪽 단추로 클릭하고 관리를 선택합니다. 컴퓨터 관리에서 서비스 및 응용 프로그램을 확장한 다음 WMI 컨트롤을 마우스 오른쪽 단추로 클릭하고 속성을 클릭합니다. WMI 컨트롤 등록 정보 대화 상자의 보안 탭에 네임스페이스 보안에 대한 정보가 나와 있습니다.

  WMI 보안 설정에 대한 자세한 내용은 이 기술 자료 문서에서 볼 수 있습니다.

• 방화벽이 원격 컴퓨터에 대한 액세스를 차단하고 있습니다. WMI에서는 DCOM(Distributed COM) 및 RPC(원격 프로시저 호출) 프로토콜을 사용하여 네트워크를 순회합니다. 기본적으로 많은 방화벽에서 DCOM 및 RPC 트래픽을 차단하며, 방화벽에서 이러한 프로토콜을 차단하면 스크립트가 실패합니다. 예를 들어 Microsoft Windows XP 서비스 팩 2의 Windows 방화벽은 DCOM 및 WMI를 포함하여 원하지 않는 모든 네트워크 트래픽을 자동으로 차단하도록 구성되어 있습니다. 이러한 기본 구성에서는 Windows 방화벽이 들어오는 WMI 요청을 거부하고 "원격 컴퓨터가 없거나 사용할 수 없습니다."라는 오류를 나타냅니다.

  컴퓨터가 온라인이고 해당 컴퓨터에 대한 로컬 관리자 권한이 있는 경우에는 방화벽을 통과하는 문제 때문에 종종 스크립트가 실패하게 됩니다. DCOM 및 RPC 트래픽을 허용하도록 방화벽을 구성하는 방법은 사용 중인 방화벽 종류에 따라 다르므로 여기서 설명할 수 없습니다. 하지만 Windows 방화벽으로 인해 문제가 발생한다고 의심되면 I Married Bigfoot! Oh, and Windows Service Pack 2 Made My Computer Disappear (영문) 문서에서 방화벽 설정의 구성 및 관리에 관한 정보를 볼 수 있습니다. WMI SDK (영문)에는 Windows 방화벽을 통과하여 WMI 서비스에 연결하는 데 대한 추가 정보가 수록되어 있습니다.

• 로컬 컴퓨터의 WMI 버전이 원격 컴퓨터의 WMI 버전과 호환되지 않습니다. 유감스럽게도 WMI의 모든 버전은 동일하게 작성되지 않았습니다. Windows XP 또는 Windows Server 2003(적절한 관리자 권한을 가지고 있고 방화벽이 적절하게 구성되었다고 가정)을 실행하는 경우 모든 원격 컴퓨터에 연결할 수 있어야 합니다. 그러나 이전 Windows 버전의 경우 반드시 그렇지만은 않습니다. 예를 들어 Windows 2000 서비스 팩 1이 설치되었다고 가정합니다. 이 설정에서는 Windows Server 2003을 실행하는 원격 컴퓨터에 연결할 수 없으며 Windows Server 2003을 실행하는 원격 컴퓨터에 연결하려면 서비스 팩 2 이상의 서비스 팩이 설치되어 있어야 합니다.

  서로 다른 Windows 버전을 실행하는 컴퓨터 연결에 대한 자세한 내용은 WMI SDK에서 Connecting Between Different Operating Systems (영문)를 참조하십시오.

원격 컴퓨터 연결 문제가 발생할 경우 가장 먼저 할 일은 스크립트에 문제가 있는지 아니면 연결을 만드는 데 문제가 있는지를 판별하는 것입니다. 이를 위해서는 원격 컴퓨터로 가서 스크립트를 로컬로 실행합니다. 즉, 원격 컴퓨터에서 직접 스크립트를 시작합니다. 스크립트가 동작하면 연결을 만드는 데 문제가 있을 가능성이 크며 방화벽이나 DCOM 설정 때문에 발생한 문제일 수 있습니다. 스크립트가 동작하지 않으면 원격 컴퓨터의 WMI 서비스에 문제가 있음을 의미합니다. 이 경우에는 다른 원격 연결을 시도하기 전에 로컬로 스크립트를 실행해 봅니다.

WMI SDK의 Connecting to WMI on a Remote Computer (영문)에는 WMI 및 원격 컴퓨터에 대한 광범위한 토론 내용이 나와 있습니다.

페이지 위쪽

0x8004100E("네임스페이스가 잘못되었습니다.") 오류가 발생합니다.

일반적으로 잘못된 네임스페이스 오류는 두 가지 문제 중 하나로 인해 발생합니다. 그 중 하나는 네임스페이스 이름을 잘못 입력한 경우입니다. 예를 들어 다음 스크립트에서는 root\cim2v 네임스페이스에 연결하려고 하지만 해당 네임스페이스가 없으므로 0x8004100E 오류가 발생하고 스크립트가 실패합니다.

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cim2v")

이 경우 root\cim2v를 올바른 이름인 root\cimv2로 변경하면 문제가 해결됩니다.

또 다른 하나는 특정 컴퓨터에서는 유효하지만 다른 컴퓨터에는 존재하지 않는 네임스페이스에 연결하려고 하는 경우입니다. 예를 들어 Windows XP 및 Windows Server 2003에는 root\RSOP 네임스페이스가 있지만 Windows 2000에는 이 네임스페이스가 없습니다. 즉, 다음 스크립트가 Windows 2000을 실행하는 컴퓨터에서는 실패할 수 있습니다.

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\rsop")

이와 마찬가지로 어떤 응용 프로그램은 운영 체제의 기본 설치에 포함되지 않는 사용자 지정 네임스페이스인 자체 네임스페이스를 만듭니다. 컴퓨터에서 SMS 클라이언트를 실행하면 이 컴퓨터는 root\SMSDm 네임스페이스를 갖게 됩니다. 그러나 컴퓨터에 SMS가 설치되어 있지 않으면 이 네임스페이스도 없습니다. 운영 체제가 다르거나 설치된 응용 프로그램 및 하드웨어가 달라 A라는 컴퓨터에서 잘 동작하는 스크립트가 B라는 컴퓨터에서는 "네임스페이스가 잘못되었습니다." 오류가 나타나면서 실패하기도 합니다.

"네임스페이스가 잘못되었습니다." 오류가 발생하면 보다 과감한 결론을 내리기 전에 네임스페이스 이름을 잘못 입력하지 않았는지와 특정 컴퓨터에 없는 네임스페이스가 아닌지를 확인해야 합니다. 네임스페이스의 존재 여부와 철자가 정확한지를 모두 확인할 수 있는 쉬운 방법은 Scriptomatic 2.0 (영문)을 사용하는 것입니다. Scriptomatic 유틸리티는 간단한 WMI 스크립트의 작성을 돕기 위해 디자인되었지만 이 도구는 WMI 서비스 문제를 진단하는 데에도 사용할 수 있습니다.

Scriptomatic을 다운로드하고 설치한 다음 이 유틸리티를 시작하고 WMI 네임스페이스 정보가 로드되기를 기다립니다. 그런 다음 WMI Namespace라고 표시된 드롭다운 목록을 클릭합니다.

이 드롭다운 목록은 컴퓨터에 있는 모든 WMI 네임스페이스를 보여 주므로 1) 네임스페이스가 컴퓨터에 실제로 존재하는지 여부와 2) 네임스페이스 이름의 철자가 올바른지 여부를 쉽게 확인할 수 있습니다.

네임스페이스가 존재하고 이 이름의 철자를 정확히 입력한 경우라면 어떻게 해야 할까요? 이 경우에는 root\default 네임스페이스에 바인딩하는 다음 스크립트를 실행해 봅니다.

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\default")

이 스크립트가 성공하면 WMI 서비스가 올바르게 동작하는 것이므로 이 경우에는 특정 네임스페이스 하나가 문제가 될 수 있습니다. 이 때는 문제가 되는 네임스페이스의 MOF 파일을 다시 컴파일해야 합니다. MOF 파일을 다시 컴파일하는 것에 대한 자세한 내용은 공급자 등록과 관련하여 오류가 발생합니다 항목을 참조하십시오. root\default에 대한 연결이 실패하면 보다 심각한 문제가 있음을 의미합니다. 이 경우에는 WMI 서비스를 중지하고 다시 시작한(네임스페이스, 클래스 및 속성 이름이 정확한지 확인했지만 스크립트가 여전히 동작하지 않습니다 항목 참조) 다음 해당 위치에서 계속합니다.

명령 프롬프트에서 다음 명령을 사용하여 root\default 네임스페이스에 연결을 시도할 수도 있습니다.

wmic /interactive:on /namespace:\\root\default

"Interactive mode set"(대화형 모드 설정) 메시지가 나타나면 네임스페이스에 연결할 수 있습니다. "네임스페이스가 잘못되었습니다." 메시지는 연결이 실패했음을 나타냅니다.

페이지 위쪽

0x80041010("클래스가 잘못되었습니다.") 오류가 발생합니다.

0x80041010 오류 메시지는 존재하지 않는 WMI 클래스를 참조하려고 했음을 의미합니다. 이 오류는 일반적으로 다음과 같은 경우에 발생합니다.

• 클래스 이름을 잘못 입력한 경우. 예를 들어 실제 클래스 이름이 Win32_Service(끝에 s가 없음)인데 Win32_Services(끝에 s가 있음)라는 클래스에 연결하려고 하는 경우입니다.
• 잘못된 네임스페이스를 참조하는 경우. 스크립트 작성자들은 종종 root\cimv2 네임스페이스에 연결한 다음 StdRegProv 클래스에 액세스하려고 합니다. 그러나 StdRegProv는 실제로 root\default 네임스페이스에 있습니다.
• 특정 운영 체제에서 지원하지 않는 클래스에 액세스하려고 하는 경우. 예를 들어 root\default 네임스페이스에 있는 SystemRestore 클래스는 Windows XP에서만 지원됩니다. Windows 2000을 실행하는 컴퓨터에서 이 클래스에 액세스하려고 하면 "클래스가 잘못되었습니다." 오류가 발생할 수 있습니다.

잘못된 클래스와 관련하여 오류가 발생해도 Scriptomatic (영문)을 사용하여 해결할 수 있습니다. Scriptomatic을 다운로드하고 설치한 다음 이 유틸리티를 시작하고 WMI 네임스페이스 정보가 로드되기를 기다립니다. 정보가 로드되면 WMI Namespace라고 표시된 드롭다운 목록을 클릭하고 해당 네임스페이스를 선택합니다. 예를 들어 클래스가 표면상 root\wmi 네임스페이스에 있으면 root\wmi를 선택합니다. 클래스 정보가 로드되면 WMI Class 드롭다운 목록을 클릭하여 이 클래스가 존재하는지 확인하고 클래스가 존재하면 이름을 정확히 입력했는지 확인합니다.

클래스가 표시되지 않으면 클래스가 없거나 실제로 다른 네임스페이스에 있는 것입니다. 드롭다운 목록에서 다른 WMI 네임스페이스를 선택하여 전체 WMI 리포지토리를 찾아보고 해당 클래스가 있는지 확인할 수 있습니다.

지정한 네임스페이스에 클래스가 있고 네임스페이스와 클래스 이름을 정확히 입력한 경우라면 WMI 서비스에 보다 심각한 문제가 있을 수 있습니다. 이 경우에는 Win32_Process 클래스에 바인딩하는 다음 스크립트를 실행해 봅니다.

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2:Win32_Process")

이 스크립트가 성공하면 WMI 서비스가 올바르게 동작하는 것이므로 이 경우에는 해당 클래스 하나가 문제가 될 수 있습니다. 이 경우에는 문제가 되는 클래스의 MOF 파일을 다시 컴파일해야 합니다. MOF 파일을 다시 컴파일하는 것에 대한 자세한 내용은 공급자 등록과 관련하여 오류가 발생합니다 항목을 참조하십시오. Win32_Process 클래스에 대한 연결이 실패하면 보다 심각한 문제가 있음을 의미합니다. 이 경우에는 WMI 서비스를 중지하고 다시 시작한(네임스페이스, 클래스 및 속성 이름이 정확한지 확인했지만 스크립트가 여전히 동작하지 않습니다 항목 참조) 다음 해당 위치에서 계속합니다.

명령 프롬프트에서 다음 명령을 실행하여 Win32_Process 클래스에 연결을 시도할 수도 있습니다.

wmic path "Win32_Process" get Name

연결에 성공하면 컴퓨터에서 현재 실행되고 있는 모든 프로세스의 목록이 명령 창에 표시됩니다. 연결에 실패하면 "클래스가 잘못되었습니다." 오류가 발생합니다.

페이지 위쪽

속성이나 메서드가 지원되지 않는다는 오류(0x800A01B6)가 발생합니다.

스크립트를 실행하면 다음과 비슷한 오류 메시지를 받는 경우가 있습니다.

일반적으로 이 오류는 두 가지 경우 중 하나에서 발생합니다. 대부분은 단순히 잘못된 속성 또는 메서드 이름을 입력한 경우 발생합니다. 위의 예는 Name이라는 속성 이름을 존재하지 않는 Namex로 잘못 입력한 경우입니다. 이 문제를 해결할 때는 대화 상자에 나타나는 정보를 이용합니다. 일반적으로 대화 상자에는 오류가 발생한 코드 줄(이 경우 5번째 줄)과 잘못된 속성 또는 메서드 이름(Namex)이 표시됩니다. 그러면 Scriptomatic (영문) 또는 Wbemtest.exe (영문)를 사용하여 실제 속성 이름을 확인할 수 있습니다.

다른 버전의 Windows를 실행하는 컴퓨터로 작업하는 경우에도 이 문제가 발생할 수 있습니다. 예를 들어 Windows XP와 Windows Server 2003의 경우 Win32_UserAccount 클래스에는 LocalAccount라는 속성이 포함되어 있습니다. Win32_UserAccount 클래스는 Windows 2000에도 있지만 Windows 2000에 설치된 WMI 버전에는 LocalAccount 속성이 포함되어 있지 않습니다. 다른 Windows 버전에서 작업하는 경우 Scriptomatic을 사용하여 컴퓨터에 있는 속성과 다른 컴퓨터에 있는 속성을 비교합니다.

속성 이름이 정확해도 스크립트가 실패하면 이 문서에서 다음 네임스페이스, 클래스 및 속성 이름이 정확한지 확인했지만 스크립트가 여전히 동작하지 않습니다 항목을 참조하십시오.

명령 프롬프트에서 다음 명령을 입력하여 WMI 클래스의 모든 속성 및 메서드에 대한 XML 목록을 얻을 수도 있습니다.

wmic class "win32_useraccount"

페이지 위쪽

네임스페이스, 클래스 및 속성 이름이 정확한지 확인했지만 스크립트가 여전히 동작하지 않습니다.

대개 WMI 서비스(winmgmt)는 항상 실행되고 있습니다. 이 서비스는 컴퓨터가 시작됨과 동시에 시작되어 컴퓨터가 종료될 때까지 중지되지 않습니다. 서비스가 중지될 수도 있지만 Wbemtest.exe나 WMI 스크립트를 사용하여 WMI 네임스페이스에 연결하면 언제든지 자동으로 다시 시작되도록 디자인되었습니다.

드문 경우지만 서비스가 중지되었다가 사용자가 스크립트를 실행할 때 자체적으로 다시 시작되지 못할 수도 있고, 스크립트에 문제가 있을 때 서비스를 명시적으로 중지한 다음 다시 시작하여 이러한 문제를 해결할 수도 있습니다. WMI 리포지토리를 다시 빌드하는 것과 같은 보다 과감한 조치를 취하기 전에 항상 서비스를 중지한 다음 다시 시작해 보아야 합니다.

WMI 서비스 다시 시작

명령 프롬프트에서 다음 명령을 입력하여 WMI 서비스를 다시 시작할 수 있습니다.

net start winmgmt

서비스를 다시 시작하지 못했거나 다시 시작해도 문제가 해결되지 않으면 다음 단원에 있는 단계를 수행해 봅니다.

WMI 서비스를 중지한 후 시작

WMI 서비스에 문제가 있으면 수동으로 서비스를 중지한 후 다시 시작합니다. 그러나 그 전에 WMI의 로그 옵션을 자세한 정보 기록으로 설정해야 합니다. 자세한 정보 기록 옵션을 사용하면 문제를 진단할 때 유용할 수 있는 추가 정보가 WMI 오류 로그에 기록됩니다. WMI 컨트롤을 사용하여 자세한 정보 기록 옵션을 설정하려면 다음과 같이 합니다.

1. 컴퓨터 관리 MMC 스냅인을 열고 서비스 및 응용 프로그램을 확장합니다.
2. WMI 컨트롤을 마우스 오른쪽 단추로 클릭한 다음 속성을 클릭합니다.
3. WMI 컨트롤 등록 정보 대화 상자의 로깅 탭에서 자세한 정보 기록(Microsoft 문제 해결에 대한 추가 정보 포함)을 선택한 다음 확인을 클릭합니다.

또는 다음 레지스트리 값을 수정할 수 있습니다.

• HKEY_LOCAL_MACHINE\Software\Microsoft\WBEM\CIMOM\Logging을 2로 설정합니다.
• HKEY_LOCAL_MACHINE\Software\Microsoft\WBEM\CIMOM\Logging File Max Size를 4000000으로 설정합니다.

자세한 정보 기록 옵션을 설정한 후 명령 프롬프트에서 다음을 입력하여 WMI 서비스를 중지합니다.

net stop winmgmt

net stop 명령이 실패하면 다음을 입력하여 서비스를 중지할 수 있습니다.

winmgmt /kill

그런 다음 아래 명령을 입력하여 서비스를 다시 시작할 수 있습니다.

You can then restart the service by typing the following command:
net start winmgmt

서비스가 다시 시작되지 않으면 컴퓨터를 다시 부팅하여 문제가 해결되는지 확인합니다. 그래도 문제가 해결되지 않으면 이후 내용을 계속 읽어 보아야 합니다.

페이지 위쪽

0x80041013("공급자를 찾을 수 없습니다.") 또는 0x80041014("구성 요소가 초기화하지 못했습니다.") 오류가 발생합니다.

솔직히 이러한 오류는 해결하기가 약간 더 어렵습니다. 오류 번호 0x80041013은 "COM이 스키마에서 참조하는 공급자를 찾을 수 없습니다."를 의미하고 오류 번호 0x80041014는 WMI 공급자 등의 구성 요소가 "내부적인 오류로 초기화하지 못했습니다."라는 의미입니다. 이 두 가지 오류 중 하나가 발생하면 WMI와 관련된 모든 .DLL 및 .EXE 파일을 다시 등록해야 합니다.

우선 %windir%\System32\Wbem 폴더에 있는 모든 .DLL 파일을 다시 등록해야 합니다. 명령 창을 열고 cd 명령을 사용하여 %windir%\System32\Wbem 디렉터리로 변경합니다. 명령 프롬프트에서 다음을 입력한 다음 Enter 키를 누릅니다.

for %i in (*.dll) do RegSvr32 -s %i

.DLL이 다시 등록된 다음에는 Mofcomp.exe와 Wmic.exe를 제외하고 Wbem 폴더에 있는 모든 .EXE 파일을 다시 등록해야 합니다. 예를 들어 실행 파일인 Scrcons.exe를 다시 등록하려면 명령 프롬프트에서 다음을 입력합니다.

regsvr32 -s scrcons.exe

.EXE 파일을 다시 등록한 후 스크립트를 다시 실행해 봅니다. 오류 번호 0x80041011, 0x80041012 또는 0x80041085가 발생하면서 스크립트가 실패하면 이 문서의 공급자 등록과 관련하여 오류가 발생합니다 항목을 참조하십시오.

페이지 위쪽

공급자 등록과 관련하여 오류가 발생합니다.

WMI 구성 요소를 다시 등록한(0x80041013("공급자를 찾을 수 없습니다.") 또는 0x80041014("구성 요소가 초기화하지 못했습니다.") 오류가 발생합니다 항목 참조) 후에도 스크립트를 실행할 수 없으며 특히 다음 오류 중 하나가 발생할 수 있습니다.

이러한 오류 중 하나가 발생하면 .MOF 파일 중 하나 이상을 다시 컴파일해야 합니다. .MOF(Managed Object Format) 파일은 WMI 클래스에 대한 정보가 WMI 리포지토리에 입력될 때 사용되는 메커니즘입니다. 현재 리포지토리에 있는 클래스 정의가 손상될 수도 있는데 이 경우 .MOF 파일을 다시 컴파일하면 이러한 클래스 정의가 운영 체제가 원래 설치될 때 사용된 손상되지 않은 동일한 클래스 정의로 덮어쓰여져 바뀌게 됩니다.

.MOF 파일을 다시 컴파일하기 전에 두 가지 사항을 알아 두어야 합니다. 첫째, 대부분의 .MOF 파일은 %windir%\System32\Wbem 폴더에서 찾을 수 있습니다. 그러나, 예외가 있을 수 있으므로 시작하기 전에 하드 디스크에서 모든 .MOF 파일을 검색할 수 있습니다.

둘째, 설치하는 동안 리포지토리를 자동으로 채우는 몇몇 응용 프로그램이 있는데 이들 응용 프로그램은 .MOF 파일을 사용하지 않는다는 것입니다. 이들 응용 프로그램 중 하나로 인해 WMI 서비스 문제가 발생한 경우(확실히 진단하기 어려운 문제) 리포지토리의 클래스 정의를 수정할 수 있는 유일한 방법은 응용 프로그램을 다시 설치하는 것입니다.

.MOF 및 .MFL 파일(.MOF 파일에는 종종 클래스, 속성 및 메서드에 대한 지역화된 설명이 들어 있는 해당 .MFL 파일이 있음)을 다시 컴파일하는 가장 쉬운 방법은 명령 창을 열고 cd 명령을 사용하여 %windir%\System32\Wbem 폴더로 전환한 후 다음을 입력하는 것입니다.

for %i in (*.mof, *.mfl) do Mofcomp %i

스크립트 또는 배치 파일을 사용하여 .MOF 파일을 다시 컴파일하거나 수동으로 Mofcomp.exe를 호출하는 경우에는 해당 .MFL 파일을 컴파일하기 전에 .MOF 파일을 먼저 컴파일해야 합니다. 다시 말해 다음 순서로 파일을 컴파일합니다.

Mofcomp.exe cimwin32.mof
Mofcomp.exe cimwin32.mfl

사실 MOF 및 MFL 파일을 다시 컴파일하는 것보다 WMI 리포지토리를 다시 빌드하는 것이 더 빠르고 쉽습니다. 리포지토리를 다시 빌드하는 것에 대한 자세한 내용은 이 문서의 스크립트가 올바르고 WMI 서비스가 실행되고 있으며 모든 .dll을 다시 등록했는데도 스크립트가 동작하지 않습니다 항목을 참조하십시오. 레지스트리의 일부만 손상되었다는 확실한 근거가 있을 경우에는 .MOF와 .MFL 파일을 다시 컴파일하는 것이 유용합니다. 이 경우에는 전체 리포지토리를 다시 빌드할 필요 없이 영향을 받는 MOF와 MFL 파일만 다시 컴파일하면 됩니다.

물론 두 가지 의문이 생길 수 있습니다. 첫째는 왜 리포지토리를 다시 빌드하지 않을까? 하는 점입니다. 물론 그렇게 할 수 있습니다. 하지만 리포지토리를 모두 지우고 바꿀 경우 몇 가지 위험이 따를 수 있습니다. 예를 들어 WMI 리포지토리는 WMI 자체의 메타 정보에 대한 주 저장소입니다. 그러나 이 리포지토리에는 일부 정적 클래스 데이터가 저장될 수 있고 실제로 종종 저장됩니다. 리포지토리를 다시 빌드하면 이러한 모든 데이터가 손실됩니다. 이러한 예로 WMI 서비스에 등록된 영구 이벤트 소비자를 들 수 있습니다. 일반적으로 이 방법은 대부분의 사용자에게 문제를 일으키지는 않겠지만 그럴 가능성은 있습니다.

두 번째로 갖게 되는 의문은 리포지토리 중 일부만 다시 빌드하기로 결정한 경우 어느 MOF와 MFL 파일을 다시 컴파일할 것인지를 어떻게 알 수 있을까? 하는 점입니다. 이를 알 수 있는 가장 쉬운 방법은 .MOF 파일(대개 %windir%\System32\Wbem 폴더에 있음)을 검색하여 문제가 되는 클래스의 이름을 찾는 것입니다. .MOF 파일은 클래스에 대한 정보를 WMI 리포지토리에 추가할 책임이 있으므로 해당 .MOF 파일에는 클래스 이름이 정확하게 나와 있습니다.

페이지 위쪽

스크립트가 올바르고 WMI 서비스가 실행되고 있으며 모든 .dll을 다시 등록했는데도 스크립트가 동작하지 않습니다.

WMI 리포지토리(%windir%\System32\Wbem\Repository)는 WMI 클래스에 대한 정의와 메타 정보를 저장하는 데이터베이스이며 경우에 따라 정적 클래스 데이터도 저장합니다. 리포지토리가 손상되면 WMI 서비스가 제대로 동작할 수 없습니다. 지금까지 네임스페이스를 확인하는 방법부터 개별 .MOF 파일을 다시 컴파일하는 방법에 이르기까지 다른 모든 방법을 모두 시도해 보았다면 리포지토리가 손상되었을 가능성이 있습니다. 다행히 리포지토리는 복구할 수 있습니다. 복구 단계는 실행 중인 Windows 버전에 따라 달라집니다.

Windows Server 2003 서비스 팩 1

Windows Server 2003 서비스 팩 1을 실행하는 컴퓨터에서 문제가 발생하면 명령 프롬프트에서 다음을 입력하여 먼저 일관성 검사를 실행해야 합니다.

rundll32 wbemupgd, CheckWMISetup

이 명령을 실행한 후에는 WMI 설치 로그(%windir%\System32\Wbem\Logs\Setup.log)를 확인합니다. 다음과 비슷한 항목이 있으면 일관성 검사에 실패한 것입니다.

(Wed Oct 12 14:17:14 2005): Failing Connecting to Namespace [root\default] with result [80041002]

일관성이 없는 경우가 나와 있으면 리포지토리가 손상되었다는 의미입니다. 이 경우 명령 프롬프트에서 다음 명령을 입력하여 리포지토리를 복구할 수 있습니다. 여기서 RepairWMISetup 매개 변수도 대/소문자를 구분합니다.

rundll32 wbemupgd, RepairWMISetup

복구 명령이 성공하면 설치 로그에 다음과 비슷한 항목이 나타납니다.

(Wed Oct 12 14:21:24 2005): ERROR: wbemupgd.dll. The WMI repository has failed to upgrade.
The repository has been
backed up to C:\Windows\System32\Wbem\Repository.001 and a new one created.

복구에 실패하거나 스크립트가 여전히 동작하지 않으면 Microsoft 기술 지원 서비스에 문의해야 합니다.

Microsoft Windows XP 서비스 팩 2

Windows XP 서비스 팩 2를 실행하는 경우에는 명령 하나로 손상된 WMI 리포지토리를 찾아 복구할 수 있습니다. 이를 위해서는 명령 프롬프트에서 다음을 입력합니다. UpgradeRepository 매개 변수는 대/소문자를 구분하므로 표시된 것처럼 정확히 입력해야 합니다.

rundll32 wbemupgd, UpgradeRepository

UpgradeRepository를 실행한 후에는 설치 로그를 살펴보고 결과를 확인할 수 있습니다. 일관성이 없는 항목이 발견되었고 운영 체제에서 리포지토리를 다시 빌드할 수 있는 경우에는 Setup.log에 다음과 비슷한 정보가 나타납니다.

(Wed Oct 12 13:46:36 2005): ===========================================================================
(Wed Oct 12 13:46:36 2005): Beginning WBEM Service Pack Installation
(Wed Oct 12 13:46:36 2005): Current build of wbemupgd.dll is 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)
(Wed Oct 12 13:46:36 2005): Current build of wbemcore.dll is 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)
(Wed Oct 12 13:46:52 2005): Inconsistent repository detected; it will be recreated

-
-

(Wed Oct 12 13:47:33 2005): Wbemupgd.dll Service Security upgrade succeeded (XP SP update).
(Wed Oct 12 13:47:33 2005): WBEM Service Pack Installation completed.
(Wed Oct 12 13:47:33 2005): ===========================================================================

복구에 실패하거나 스크립트가 여전히 동작하지 않으면 Microsoft 기술 지원 서비스에 문의해야 합니다.

기타 Windows 버전

WMI 리포지토리를 다시 빌드하기 위한 명령은 Windows Server 2003 서비스 팩 1과 Windows XP 서비스 팩 2에서만 기본 제공됩니다. 다른 Windows 버전에서는 다음을 수행하여 리포지토리를 다시 빌드할 수 있습니다.

1. WMI 서비스를 중지합니다. 즉, 명령 프롬프트에서 net stop winmgmt를 입력합니다.
2. %windir%\System32\Wbem\Repository 폴더의 이름을 바꿉니다. 예를 들면 %windir%\System32\Wbem\Repository_bad로 변경합니다. 이 폴더의 이름을 변경하면 운영 체제에서 더 이상 WMI 리포지토리를 찾을 수 없습니다. 따라서 다음 번에 WMI 정보를 액세스해야 할 때 리포지토리가 자동으로 다시 빌드됩니다.
3. WMI 서비스를 다시 시작(net start winmgmt)하고 스크립트를 다시 실행합니다.

스크립트가 계속 실패하면 이 문서의 공급자 등록과 관련하여 오류가 발생합니다 항목에 설명되어 있는 단계를 사용하여 수동으로 리포지토리를 다시 빌드해 봅니다.

이 방법으로 문제가 해결되는 경우

리포지토리를 다시 빌드한 후 스크립트가 올바르게 동작하면 다음을 고려해 봅니다. WMI 서비스를 중지하고 사용 중인 Repository 폴더 이름을 예를 들어 Repository_good으로 바꾼 다음 Repository_bad의 이름을 다시 Repository로 변경하여 이 폴더를 리포지토리로 설정합니다. WMI 서비스를 다시 시작하고 스크립트가 올바르게 동작하는지 확인합니다. 제대로 동작하지 않으면 Repository_good을 다시 WMI 리포지토리로 만듭니다.

왜 이런 작업이 필요한지 궁금할 것입니다. 앞에서 언급했듯이 리포지토리를 다시 빌드하면 기본적으로 위험이 따릅니다. 예를 들어 설치 동안에만 리포지토리를 업데이트하는 응용 프로그램이 있는 경우 이러한 응용 프로그램은 MOF 파일이 없거나 MOF 파일을 사용하지 않습니다. 리포지토리를 다시 빌드하면 해당 프로그램을 다시 설치하기 전까지는 이러한 응용 프로그램의 WMI 데이터가 손실됩니다. 마찬가지로 영구 이벤트 소비자가 있거나 리포지토리에 다른 데이터 형식이 저장되어 있는 경우 리포지토리를 다시 빌드하면 이러한 데이터가 손실됩니다. 이전 리포지토리를 사용할 수 있으면 이러한 데이터 손실을 막을 수 있습니다.

페이지 위쪽

WMI 리포지토리를 다시 빌드했지만 스크립트가 여전히 동작하지 않습니다.

이 문서의 모든 단계를 수행해도 WMI가 여전히 동작하지 않으면 Microsoft 기술 지원 서비스에 문의해야 합니다. 이 때 다음 사항을 알고 있어야 합니다.

• 문제가 발생한 운영 체제
• 컴퓨터에 설치된 최신 서비스 팩
• 운영 체제가 클라이언트 버전과 서버 버전 중 어느 것에 해당하는지(예: Windows 2000 Professional 또는 Windows 2000 Server)
• 운영 체제가 설치된 하드 드라이브의 종류(IDE 또는 SCSI)

자세한 내용을 보려면 http://support.microsoft.com/default.aspx를 방문하십시오.

페이지 위쪽