Windows Info 第85回

Windowsの具体的なエラーコードからその意味を探る

　今回は、前回紹介したマイクロソフトのエラーコードに関する文書（ERREFと呼ばれる）を使って、具体的にエラーコードからその意味を調べていくことにしよう。

　とはいえ、エラーを簡単に起こすことはできないし、エラーが起きたとしても必ずしもエラーコードを得られるとは限らない。そこで、マイクロソフトのナレッジベース文書のうち、エラーコードが記載されているものを使って、そのエラーコードが意味するものを調べてみることにする。

　サンプルに使ったのは、以下のURLにあるKB文書だ（https://support.microsoft.com/ja-jp/help/10164/fix-windows-update-errors）。

　これは、Windows Updateのエラーに関する文書。その冒頭には、Windows Updateで発生しうるエラーとして、以下の表にあるようなものが挙げられている。これらは、最上位桁が0x8なので、HRESULTまたはWin32エラー（上位4桁が0x8007の場合）だ。まずは、前回解説した方法で、エラーの分類を示す「Facility」を調べてみる。

　このFacilityが0x007の場合、つまりエラーコードの上位4桁が0x8007の場合には「Win32エラーコード」であり、そうでない場合には「HRESULTのエラーコード」となる。それぞれでテーブルを見ればエラーメッセージに翻訳できるはずだ。

　というのが前回まで解説した部分だ。まずは、マイクロソフトが公開しているエラーコードに関する文書に記載されている情報を元にエラーコードの意味を探してみた。

　Win32エラーの場合とFACILITY_NULLの場合には、ERREFの範囲で解決ができる。しかし、Facilityが「FACILITY_WINDOWSUPDATE」（0x024）の場合のコードがほとんど記載されておらず、エラーの内容を知ることができなかった。　ERREFは、昨年改訂された文書なのでそれほど古いものではなく、Windows Updateも当然範疇に含まれるはずだが、実際に表を調べて見ると、ほとんど記載がなかった。

　そこで、マイクロソフトのサイトを捜したところ以下のURLにWindows Updateのエラーコードがあることがわかった。

●Windows Update error code list
　https://support.microsoft.com/ja-jp/help/938205/windows-update-error-code-list

　しかし、これは2011年のもので、その後の更新もなく、それほど新しいものではない。ここには複数のリストがあるが、明確にエラーコードになっているのは3つ目のリスト以降のものだ。

　最初のものは、Component Based Servicing (CBS) interface methodsが戻すエラーコードだというが、下位20bit分（16進5桁）しか表記されてない。おそらく、FACILITY_SETUPAPI（0x800F）に対応するものだと思われる。つまり、ここにある「0xF0xxxx」は、エラーコードとして表示される場合（HRESULTとして受け渡される場合）には、0x800F0xxxというエラーになるはずだ。

　ちなみにCBSは、Vista、Windows Server 2008世代で導入された技術で、Winods UpdateやWindows Installerで内部的に使われている。このCBSを利用するAPI自体は公開されていない。すでに解説ページなどはMSDN上にはないが、以下の記述がTechNetに残っている（https://technet.microsoft.com/ja-jp/library/cc756291%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396）。

　おそらく、内部的に使われているCBS関連APIからのエラーコードがそのままWindows Updateのエラー値として使われることがあるということなのだと思われる。なので、エラーコードそのものではなく、エラーコードと共に提示される拡張コードとして示される可能性もある。

　2つめのリストは、エラーが起こっていない場合のHRESULT値であり、「成功コード」（Success code）と呼ばれるもの。メッセージを見るとERRORという文字もある。たとえば、すでに適用したアップデートをもう一度適用しようとした場合、当然そのことが報告される。このときの値が「WU_S_ALREADY_INSTALLED」だ。適用しようとしたアップデートが適用できなかったというエラーではあるが、アップデートが失敗したわけではない（すでに成功終了している）、という意味でエラーを表すビットが1になっていない。つまりエラーコードとしては0x8から始まらない。ただし、構造的には、HRESULT形式に準拠している。

　3つめ以降のリストが、エラー時に表示される「エラーコード」である。とりあえず、ここにあるコードで、サンプルとして取り上げたナレッジベース文書に記載されているFACILITY_WINDOWSUPDATEのエラー内容は確定できる。

　ただ、エラーコードが示しているエラーの中には、あまり役に立たないように見えるものもある。たとえば、0x80004005は「Unspecified error」（特定できないエラー）となっていて、何が原因で何が起こったのかさえわからない。

　こうなる原因はさまざまだが、利用しているソフトウェアモジュールがエラーコードを正しく戻さない場合などが考えられる。たとえば、エラーにより、ソフトウェアがクラッシュしてしまい、何も情報が戻らなかった場合などだ。このような場合には、ログファイルなど、エラーコード以外の情報から原因を特定するしかない。

　逆に「0x80073712」は「ERROR_SXS_COMPONENT_STORE_CORRUPT」で、説明が「The component store has been corrupted」となっていて、Windows コンポーネントストアがおかしな状態になっていることを示す。「SxS」（Side by Sideを意味する）や「Componet Store」といったキーワードからいろいろと調べることができる。

　コンポーネントストアは、アプリケーションから共有できる機能をまとめたコンポーネントの複数バージョン（アプリケーションによって対応できるコンポーネントのバージョンが異なる場合がある）を保持するためのWindowsの仕組みだ。かつては、アプリケーションと特定バージョンのコンポーネントの関係を無視して、コンポーネントを自由に更新させたため、「DLL地獄」という問題を引き起こしていた。コンポーネントストアには、多くのコンポーネントがインストールされるため構造が複雑で、不完全な操作により、構造的な矛盾が生じてしまうことがある。なお、このエラーを解決するにはDISMコマンドが利用できる。

　一般に、エラーコードを定義して複数のソフトウェアで使う場合、同じコードに複数の意味を持たせることは不可能になる。というのは、一回、ユーザーの手に渡ったプログラムは、いつまで使われるかが不明であるため、同一のコードの意味を変えてしまうと、エラーコードの報告を受けてサポートを行う場合に、間違ったエラーとして認識される可能性があるからだ。

　このことには良い面と悪い面がある。良い面とは、エラーコードの意味が変わらないため、エラーコードやエラーメッセージでの検索は有効だということとであり、悪い面は、過去のバージョンのソフトウェアでも同じエラーコードが使われているため、検索すると古いプラットフォームの情報も見つかってしまうことだ。この問題があるため、エラーコードやエラーメッセージを使った検索では、対象となるプラットフォーム名（Windows 10など）を検索キーワードに含めようにする。

　とりあえず、エラーコードを、エラーメッセージに直すところまではなんとかこぎ着けたが、数値の並びを見るに、まだ公開されていないエラー情報のリストがあると思われる。とりあえず、数字の羅列というところからは脱したという感じでしかないが、次回はエラーメッセージなどを手がかりにもう少しエラーについて見ていくことにしよう。