このページの本文へ

Windows Info 第85回

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

2017年02月19日 10時00分更新

文● 塩田紳二 編集● ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

 今回は、前回紹介したマイクロソフトのエラーコードに関する文書(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など)を検索キーワードに含めようにする。

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

カテゴリートップへ

この連載の記事

注目ニュース

ASCII倶楽部

プレミアムPC試用レポート

ピックアップ

ASCII.jp RSS2.0 配信中

ASCII.jpメール デジタルMac/iPodマガジン