WMIエラー10解決とスクリプト
一、WMIエラー10
Windows7やVistaにおいてService Packをインストールした後、イベントにWMI（Windows Management Instrumentation）のエラーが起動のたびに記録されることがある。以前、Win7でそのエラーをMicrosoftのサポートのウェブページに従って解決したことがあったが、Vistaでも同様のエラーが発生していたらしい。子供達が使うノートPCを調整していて気付いた。
そのエラーは、イベントビューアーによると
「クエリ "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA "Win32_Processor" AND TargetInstance.LoadPercentage > 99" のイベント フィルターを名前空間 "//./root/CIMV2" 内で再度使用できませんでした。原因はエラー 0x80041003 です。問題が解決されなければ、このフィルターではイベント表示できません。 」
とあり、
ログの名前: アプリケーション
ソース: WMI
イベント ID: 10
タスクのカテゴリ: なし
レベル: エラー
キーワード: クラシック
というものである。
その解決方法の説明は、Microsoft Supportのサイト内で、Windows7については、"Event ID 10 is logged in the Application log after you install Service Pack 1 for Windows 7 or Windows Server 2008 R2"と題されるページに、Vistaについては、「Windows Vista Service Pack 1 または Windows Server 2008 をインストールした後に、アプリケーション ログにイベント ID 10 が記録される」と題されるページにある。
それによると、このエラーは、「十分なアクセス許可がない状態で WMIフォルダーにアクセスした場合に発生」するようである。これは無視しても問題はないとされている。しかし、これをエラーとしてログに表示させない方法がそのページに記されている。やはり、エラーは表示されないことに越したことはない。
「この問題を解決するには、イベント ID 10 メッセージを停止するスクリプトを実行します。」として、スクリプトの実行手順が示されている。Windows7でも同様にスクリプトの実行方法が示されているが、スクリプトに不慣れな人のために「Microsoft Fix it 50688」という自動でこの問題を解決してくれるプログラムが、Win7では用意されている。Vistaには、そのようなプログラムは用意されていないので、自らスクリプトを実行するしかない。
メモ帳などのテキストエディターを開き、以下のコードをコピーして貼り付け、Test.vbsという名前を付けて任意の場所に保存する。別の名前であっても構わないが、コマンドプロンプトでは全角文字を打ち込むことはできないので（貼り付けでは可能だが）、半角の英数字等を用いた名前にしておいた方がよい。
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" _
& strComputer & "\root\subscription")
Set obj1 = objWMIService.Get("__EventFilter.Name='BVTFilter'")
set obj2set = obj1.Associators_("__FilterToConsumerBinding")
set obj3set = obj1.References_("__FilterToConsumerBinding")
For each obj2 in obj2set
WScript.echo "Deleting the object"
WScript.echo obj2.GetObjectText_
obj2.Delete_
next
For each obj3 in obj3set
WScript.echo "Deleting the object"
WScript.echo obj3.GetObjectText_
obj3.Delete_
next
WScript.echo "Deleting the object"
WScript.echo obj1.GetObjectText_
obj1.Delete_
（以上のコードを実際にコピーするのであれば、正確を期すため前述のMicrosoftの公式サポートページからコピーを行うことをお勧めします。）
さて、そのサポートページには、「このスクリプトを実行すると、イベントID 10 メッセージはアプリケーションログに表示されなくなります。」とある。日頃スクリプトを記述･実行している人は、これで滞りなく終了となる。ところが、スクリプトの作成はおろか実行すらほとんどしたことのない人は、ここでつまづくことがある。
「スクリプトを実行する」とあるから、このスクリプトファイルをダブルクリックする。
「deleting the object」と書かれたダイアログ・ボックスが現れるので、「OK」をクリック。
続いて、「instance of CommandLineEventConsumer」云々と書かれたダイアログ・ボックスが表示され、それも「OK」をクリックしてみる。
すると、「Windows Script Host」と題された赤×印のダイアログ・ボックスが立ち現れ、
「スクリプト：C:\temp\Test.vbs
行：18
文字：17
エラー：アクセスは拒否されました
コード：80041003
ソース：SWbemObjectEx」
などと宣告されるのである。
そこで、「アクセス」が「拒否され」ないようにするためには、コマンドプロンプトを管理者権限で起動し、そこからスクリプトを実行しなければならない。この点、先述のWindows7のエラーについて記したサポートページには、スクリプトに不慣れな人を考慮して親切に解説がなされている。
スタートメニューの検索欄に「cmd」と入力すると上欄に表示される「cmd.exe」を右クリックし（スタートメニュー⇒「アクセサリ」⇒「コマンドプロンプト」を右クリックでも）、「管理者として実行」を選択。「Test.vbs」をフルパス（ルートディレクトリから当該ファイルを置いたディレクトリまでのパスを当該ファイル名に冠したものをいう。例えば「C:\temp\Test.vbs」など）で入力し、Enterキーを押下する。何度かダイアログボックスが現れ、「OK」をクリックしていけばよい。
二、スクリプト
このエラーは、既に十分知られ、さしたる問題のないものであるが、そのようなエラーを解決するために与えられたソースコードの実行が求められることがあり、スクリプトに不慣れな人は上記のような場面に出くわし、うろたえる場合がある。これを質問サイト等に投稿するも、適切な回答が寄せられていないものもあった。
スクリプトに関して、業務として日常的にスクリプトを扱う人にとっては、スクリプトの単なる実行といった何の造作もないことであっても、スクリプトを用いることなどない一般のPC利用者にとっては、それさえも戸惑うことがある。
そこで、私も必要に迫られて簡単なバッチファイルを作成することがあるものの、VBScriptを利用することなどほとんどないので、スクリプトに馴染みのない人のためにも、改めて今一度スクリプトとは何か、簡単に確認しておくことにする。
スクリプト（script）とは、コンピュータ用語としても多義的に用いられているようであるが、一般的には簡易なプログラムを指し、それを記述する言語をスクリプト言語といわれる。それはソースコードを記述するだけで、機械語への変換などは自動でコンパイルないしインタープリットされ、そのまま実行できるものをいうとされる。このようなスクリプトは主にシステム管理等の様々な処理を自動化することに用いられている。
Windowsに限ってみると、Windows Script Host(WSH)という特定の言語に依存しない汎用のスクリプト実行環境が、Windows98以降OSに実装されている。WSH環境では、VBScript（Visual Basic Script）とJScriptがスクリプト・エンジン（スクリプト言語動作環境）としてデフォルトで利用可能であり、Perl、Python、Rubyといった他の言語であってもそのエンジンをインストールすることによって利用することができる。最新のバージョンは、5.8であり、Windows7や8に搭載されている。（「Windows Script Host の基礎」参照）。
しかしながら、WSHはメジャー・バージョンがアップグレードされる予定はないようで、Microsoftは、2006年に登場させたWindows PowerShellをWindowsにおけるスクリプト言語の中心に据えている（「Microsoft スクリプト センター」参照）。PowerShellの最新バージョンは4.0であり、Windows8.1に標準搭載されており、これをWindows7（標準搭載は2.0）で利用するには、SP1にアップグレードした後に、4.0をインストールする必要があるとのこと。
なお、Windows Technical Previewでは、PowerShellのバージョンは5.0となっているので（正確にはビルドナンバーが付されて2014年12月現在、5.0.9879.0）、おそらく2015年秋頃に発売されるであろうWindows 10では、マイナー・バージョンは少し上がるのかもしれない。WSHのバージョンは5.8で、Win7のそれと変わっていない。
PowerShellの特長としては、スクリプト言語であると同時にコマンド・ライン・インタフェース (CLI)シェルである点が挙げられる。即ち、「PowerShellコマンドは、コマンドプロンプトから実行することも、.ps1ファイルとして保存してスクリプトとして実行することもでき」るのであり、「コマンド プロンプトで入力するコマンドをそのままスクリプトで使用することも、その逆も可能だということ」（「Windows PowerShell 入門」）になる。今回初めてPowerShellに触れてみたが、種々の処理を大量に反復することなどほとんどない私用の場面では、スクリプトよりもむしろコマンドレット（cmdlet）と呼ばれるPowerShell専用のコマンドがインタラクティブな（対話型の）コマンド・ラインとして使用することができるPowerShellは素人目にも使い勝手がよいように感じた。
とはいえ、Windows9X時代から使われてきたのがWSHである。VBScriptを長らく利用してきた人には、多くのソースコードないしそのノウハウの蓄積があり、日々の業務に追われる中でそれらを捨てて、新たにPowerShellを導入することに伴う彼等の苦労は察するに余りある。XPからWindows7にようやく乗り換えたばかりの企業も少なくないことからすれば、なおさらである。もっとも、PowerShellといえども万能ではなく、専門家は状況によってWSHとPowerShellを使い分けることを勧めているようである。例えば、Get-Contentコマンドレットではバイナリファイルを読み込むことができないので、WHSに頼らざるをえない場面もあるらしい。
さて、WSHの話に戻すと、WSHにはスクリプト・エンジンとしてWScriptとCscriptとが用意されており、既定ではWscriptが標準となっている。両者は、同様の処理を行うが、出力において差異がある。Wscriptはコマンド毎にメッセージ・ボックスに結果が出力され、応答が求められる。Cscriptは一度にスクリプトが処理され、最後に結果がコマンドプロンプトに出力される。スクリプトはスクリプト・ファイルをダブルクリックして実行することも、コマンドプロンプトでスクリプト・ファイルを指定して実行することも可能となっている。従って、スクリプト・ファイルをダブルクリックしたときに、前述のように「アクセスは拒否されました」となる場合には、コマンドプロンプトを右クリックの「管理者として実行」から起動して、スクリプトを実行することができるのである。
Wscriptがデフォルトとなっているので、どちらの方法でスクリプトを実行してもメッセージ・ボックスが表示されることなり、「OK」をクリックしない限り、次の処理に進まない。それゆえ、大量の処理を一括して行いたい場合には、Cscriptを使用した方が便宜である。
スクリプト・ファイルをCscriptで実行するには、コマンドプロンプトで「Cscript」と入力して、そのあとにファイルを指定することになる。
例えば、インストールされているVBScriptのバージョンを取得するスクリプトをメモ帳などのテキスト・エディタで「Wscript.echo ScriptEngineMajorVersion & "." & ScriptEngineMinorVersion」と記述し、「VBS-Version.vbs」とファイル名を付して、C:\tempフォルダ内に保存するとする。
コマンドプロンプトを起動し、次のように「Cscript C:\temp\VBS-Version.vbs」と入力して、Enterで実行する。
すると、メジャー・バージョンが5、マイナー・バージョンが8であれば、以下のように「5.8」と表示される。
「Cscript」と指定せずに、単に「C:\temp\VBS-Version.vbs」と入力すると、
Wscriptで処理されるので、次のようなメッセージ・ボックスで「5.8」が表示される。
以上、Windowsにおいて不慣れなスクリプトを否応なく実行せざるをえないといった方の参考となれば幸いである。
Windows7やVistaにおいてService Packをインストールした後、イベントにWMI（Windows Management Instrumentation）のエラーが起動のたびに記録されることがある。以前、Win7でそのエラーをMicrosoftのサポートのウェブページに従って解決したことがあったが、Vistaでも同様のエラーが発生していたらしい。子供達が使うノートPCを調整していて気付いた。
そのエラーは、イベントビューアーによると
「クエリ "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA "Win32_Processor" AND TargetInstance.LoadPercentage > 99" のイベント フィルターを名前空間 "//./root/CIMV2" 内で再度使用できませんでした。原因はエラー 0x80041003 です。問題が解決されなければ、このフィルターではイベント表示できません。 」
とあり、
ログの名前: アプリケーション
ソース: WMI
イベント ID: 10
タスクのカテゴリ: なし
レベル: エラー
キーワード: クラシック
というものである。
その解決方法の説明は、Microsoft Supportのサイト内で、Windows7については、"Event ID 10 is logged in the Application log after you install Service Pack 1 for Windows 7 or Windows Server 2008 R2"と題されるページに、Vistaについては、「Windows Vista Service Pack 1 または Windows Server 2008 をインストールした後に、アプリケーション ログにイベント ID 10 が記録される」と題されるページにある。
それによると、このエラーは、「十分なアクセス許可がない状態で WMIフォルダーにアクセスした場合に発生」するようである。これは無視しても問題はないとされている。しかし、これをエラーとしてログに表示させない方法がそのページに記されている。やはり、エラーは表示されないことに越したことはない。
「この問題を解決するには、イベント ID 10 メッセージを停止するスクリプトを実行します。」として、スクリプトの実行手順が示されている。Windows7でも同様にスクリプトの実行方法が示されているが、スクリプトに不慣れな人のために「Microsoft Fix it 50688」という自動でこの問題を解決してくれるプログラムが、Win7では用意されている。Vistaには、そのようなプログラムは用意されていないので、自らスクリプトを実行するしかない。
メモ帳などのテキストエディターを開き、以下のコードをコピーして貼り付け、Test.vbsという名前を付けて任意の場所に保存する。別の名前であっても構わないが、コマンドプロンプトでは全角文字を打ち込むことはできないので（貼り付けでは可能だが）、半角の英数字等を用いた名前にしておいた方がよい。
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" _
& strComputer & "\root\subscription")
Set obj1 = objWMIService.Get("__EventFilter.Name='BVTFilter'")
set obj2set = obj1.Associators_("__FilterToConsumerBinding")
set obj3set = obj1.References_("__FilterToConsumerBinding")
For each obj2 in obj2set
WScript.echo "Deleting the object"
WScript.echo obj2.GetObjectText_
obj2.Delete_
next
For each obj3 in obj3set
WScript.echo "Deleting the object"
WScript.echo obj3.GetObjectText_
obj3.Delete_
next
WScript.echo "Deleting the object"
WScript.echo obj1.GetObjectText_
obj1.Delete_
（以上のコードを実際にコピーするのであれば、正確を期すため前述のMicrosoftの公式サポートページからコピーを行うことをお勧めします。）
さて、そのサポートページには、「このスクリプトを実行すると、イベントID 10 メッセージはアプリケーションログに表示されなくなります。」とある。日頃スクリプトを記述･実行している人は、これで滞りなく終了となる。ところが、スクリプトの作成はおろか実行すらほとんどしたことのない人は、ここでつまづくことがある。
「スクリプトを実行する」とあるから、このスクリプトファイルをダブルクリックする。
「deleting the object」と書かれたダイアログ・ボックスが現れるので、「OK」をクリック。
続いて、「instance of CommandLineEventConsumer」云々と書かれたダイアログ・ボックスが表示され、それも「OK」をクリックしてみる。
すると、「Windows Script Host」と題された赤×印のダイアログ・ボックスが立ち現れ、
「スクリプト：C:\temp\Test.vbs
行：18
文字：17
エラー：アクセスは拒否されました
コード：80041003
ソース：SWbemObjectEx」
などと宣告されるのである。
そこで、「アクセス」が「拒否され」ないようにするためには、コマンドプロンプトを管理者権限で起動し、そこからスクリプトを実行しなければならない。この点、先述のWindows7のエラーについて記したサポートページには、スクリプトに不慣れな人を考慮して親切に解説がなされている。
スタートメニューの検索欄に「cmd」と入力すると上欄に表示される「cmd.exe」を右クリックし（スタートメニュー⇒「アクセサリ」⇒「コマンドプロンプト」を右クリックでも）、「管理者として実行」を選択。「Test.vbs」をフルパス（ルートディレクトリから当該ファイルを置いたディレクトリまでのパスを当該ファイル名に冠したものをいう。例えば「C:\temp\Test.vbs」など）で入力し、Enterキーを押下する。何度かダイアログボックスが現れ、「OK」をクリックしていけばよい。
二、スクリプト
このエラーは、既に十分知られ、さしたる問題のないものであるが、そのようなエラーを解決するために与えられたソースコードの実行が求められることがあり、スクリプトに不慣れな人は上記のような場面に出くわし、うろたえる場合がある。これを質問サイト等に投稿するも、適切な回答が寄せられていないものもあった。
スクリプトに関して、業務として日常的にスクリプトを扱う人にとっては、スクリプトの単なる実行といった何の造作もないことであっても、スクリプトを用いることなどない一般のPC利用者にとっては、それさえも戸惑うことがある。
そこで、私も必要に迫られて簡単なバッチファイルを作成することがあるものの、VBScriptを利用することなどほとんどないので、スクリプトに馴染みのない人のためにも、改めて今一度スクリプトとは何か、簡単に確認しておくことにする。
スクリプト（script）とは、コンピュータ用語としても多義的に用いられているようであるが、一般的には簡易なプログラムを指し、それを記述する言語をスクリプト言語といわれる。それはソースコードを記述するだけで、機械語への変換などは自動でコンパイルないしインタープリットされ、そのまま実行できるものをいうとされる。このようなスクリプトは主にシステム管理等の様々な処理を自動化することに用いられている。
Windowsに限ってみると、Windows Script Host(WSH)という特定の言語に依存しない汎用のスクリプト実行環境が、Windows98以降OSに実装されている。WSH環境では、VBScript（Visual Basic Script）とJScriptがスクリプト・エンジン（スクリプト言語動作環境）としてデフォルトで利用可能であり、Perl、Python、Rubyといった他の言語であってもそのエンジンをインストールすることによって利用することができる。最新のバージョンは、5.8であり、Windows7や8に搭載されている。（「Windows Script Host の基礎」参照）。
しかしながら、WSHはメジャー・バージョンがアップグレードされる予定はないようで、Microsoftは、2006年に登場させたWindows PowerShellをWindowsにおけるスクリプト言語の中心に据えている（「Microsoft スクリプト センター」参照）。PowerShellの最新バージョンは4.0であり、Windows8.1に標準搭載されており、これをWindows7（標準搭載は2.0）で利用するには、SP1にアップグレードした後に、4.0をインストールする必要があるとのこと。
なお、Windows Technical Previewでは、PowerShellのバージョンは5.0となっているので（正確にはビルドナンバーが付されて2014年12月現在、5.0.9879.0）、おそらく2015年秋頃に発売されるであろうWindows 10では、マイナー・バージョンは少し上がるのかもしれない。WSHのバージョンは5.8で、Win7のそれと変わっていない。
PowerShellの特長としては、スクリプト言語であると同時にコマンド・ライン・インタフェース (CLI)シェルである点が挙げられる。即ち、「PowerShellコマンドは、コマンドプロンプトから実行することも、.ps1ファイルとして保存してスクリプトとして実行することもでき」るのであり、「コマンド プロンプトで入力するコマンドをそのままスクリプトで使用することも、その逆も可能だということ」（「Windows PowerShell 入門」）になる。今回初めてPowerShellに触れてみたが、種々の処理を大量に反復することなどほとんどない私用の場面では、スクリプトよりもむしろコマンドレット（cmdlet）と呼ばれるPowerShell専用のコマンドがインタラクティブな（対話型の）コマンド・ラインとして使用することができるPowerShellは素人目にも使い勝手がよいように感じた。
とはいえ、Windows9X時代から使われてきたのがWSHである。VBScriptを長らく利用してきた人には、多くのソースコードないしそのノウハウの蓄積があり、日々の業務に追われる中でそれらを捨てて、新たにPowerShellを導入することに伴う彼等の苦労は察するに余りある。XPからWindows7にようやく乗り換えたばかりの企業も少なくないことからすれば、なおさらである。もっとも、PowerShellといえども万能ではなく、専門家は状況によってWSHとPowerShellを使い分けることを勧めているようである。例えば、Get-Contentコマンドレットではバイナリファイルを読み込むことができないので、WHSに頼らざるをえない場面もあるらしい。
さて、WSHの話に戻すと、WSHにはスクリプト・エンジンとしてWScriptとCscriptとが用意されており、既定ではWscriptが標準となっている。両者は、同様の処理を行うが、出力において差異がある。Wscriptはコマンド毎にメッセージ・ボックスに結果が出力され、応答が求められる。Cscriptは一度にスクリプトが処理され、最後に結果がコマンドプロンプトに出力される。スクリプトはスクリプト・ファイルをダブルクリックして実行することも、コマンドプロンプトでスクリプト・ファイルを指定して実行することも可能となっている。従って、スクリプト・ファイルをダブルクリックしたときに、前述のように「アクセスは拒否されました」となる場合には、コマンドプロンプトを右クリックの「管理者として実行」から起動して、スクリプトを実行することができるのである。
Wscriptがデフォルトとなっているので、どちらの方法でスクリプトを実行してもメッセージ・ボックスが表示されることなり、「OK」をクリックしない限り、次の処理に進まない。それゆえ、大量の処理を一括して行いたい場合には、Cscriptを使用した方が便宜である。
スクリプト・ファイルをCscriptで実行するには、コマンドプロンプトで「Cscript」と入力して、そのあとにファイルを指定することになる。
例えば、インストールされているVBScriptのバージョンを取得するスクリプトをメモ帳などのテキスト・エディタで「Wscript.echo ScriptEngineMajorVersion & "." & ScriptEngineMinorVersion」と記述し、「VBS-Version.vbs」とファイル名を付して、C:\tempフォルダ内に保存するとする。
コマンドプロンプトを起動し、次のように「Cscript C:\temp\VBS-Version.vbs」と入力して、Enterで実行する。
すると、メジャー・バージョンが5、マイナー・バージョンが8であれば、以下のように「5.8」と表示される。
「Cscript」と指定せずに、単に「C:\temp\VBS-Version.vbs」と入力すると、
Wscriptで処理されるので、次のようなメッセージ・ボックスで「5.8」が表示される。
以上、Windowsにおいて不慣れなスクリプトを否応なく実行せざるをえないといった方の参考となれば幸いである。
コメントの投稿
Re: No title
コメントありがとうございます。
イベントビュアーにエラーが記録されていると、無視しても大丈夫だと言われても、やはり気持ちのよいものではありませんよね。
解決できて何よりです。
>無意味な情報、的外れな回答がある中で…
私も時折、質問掲示板に回答を書くこともあるのですが、的外れな回答というよりも明らかな誤りを含んだ回答を信じてしまう質問者がいることに虚しさを味わうことも少なくありません。知識のない人に理解してもらえるように書くことの難しさを痛感することもあります。難しいものです。
イベントビュアーにエラーが記録されていると、無視しても大丈夫だと言われても、やはり気持ちのよいものではありませんよね。
解決できて何よりです。
>無意味な情報、的外れな回答がある中で…
私も時折、質問掲示板に回答を書くこともあるのですが、的外れな回答というよりも明らかな誤りを含んだ回答を信じてしまう質問者がいることに虚しさを味わうことも少なくありません。知識のない人に理解してもらえるように書くことの難しさを痛感することもあります。難しいものです。
No title
助かりました。無意味な情報、的外れな回答がある中で明確な情報はとてもありがたいです。
