Windows Server などで XenServer Tools を入れると、途中で『クラッシュしました』『インストール失敗』と出るのに、実際はインストールが完了しているように見えることがあります。イベントビューアーに Event ID 1000/1026 が出る原因と、最短で切り分ける手順をまとめます。
症状：インストール中に「クラッシュしました」と出るのに、実際はインストール完了しているように見える
XenServer（Citrix Hypervisor）上の Windows VM に XenServer Tools をインストールしている最中、セットアップ画面やポップアップで「クラッシュしました」「インストールに失敗しました」といった表示が出ることがあります。
ところが、作業後に確認すると次のような状態になっていて、一見すると成功しているように見えるため混乱します。
- 「プログラムと機能」に XenServer Tools（または Citrix XenServer Tools）が登録されている
- デバイスマネージャーで PV ドライバー（XenBus / XenNet など）が入っているように見える
- VM のシャットダウンや再起動など、最低限の操作はできる
一方で、イベントビューアーの「Windows ログ ＞ アプリケーション」には次のエラーが残ります。
- Event ID 1000（Application Error）
- Event ID 1026（.NET Runtime）
結論：Event ID 1000 / 1026 は「インストーラー（またはその一部）が落ちた」サインになりやすい
このパターンでは、OS 自体の深刻な故障というより、インストール処理に関わる実行ファイル（インストーラー UI、カスタムアクション、補助ツール等）が例外で落ちた可能性が高いです。特に Event ID 1026 が同時に出ている場合は、.NET 実行環境の不整合や、インストーラー側（今回なら XenServer Tools 側）の .NET 例外に寄った切り分けが最短になります。
まず現実的な回避策としては、次の 2 本柱が効きやすいです。
- .NET Framework の修復／更新（Event ID 1026 が出る以上、土台の健全性を先に担保する）
- XenServer Tools 側の既知問題・バージョン差分の確認（ホストに対応する Tools を使う、ベンダー情報に当たる）
なぜ「失敗表示」と「インストール完了」が両立するのか
ここが最大のポイントです。インストールは「最後まで正常終了すること」と「ファイルやドライバーが導入されること」が必ずしも一致しません。特に XenServer Tools のように複数コンポーネントを段階導入する製品では、導入は進んだが、最後の UI／後処理だけが落ちたという状態が起き得ます。
| フェーズ | 内部で起きていること | 画面上の見え方 | 失敗が起きやすいポイント |
|---|---|---|---|
| 起動（ブートストラップ） | setup.exe 等が前提条件をチェックし、MSI/ドライバー導入を呼び出す | インストーラー画面が出る | 権限不足、セキュリティ製品の干渉 |
| 本体導入（MSI コミット） | ファイルコピー、レジストリ登録、サービス登録などが進む | 進捗バーが進む | ファイル競合、保留中の再起動、ディスク権限 |
| ドライバー導入 | PV ドライバー等が入ってデバイスが再構成される | 一瞬固まる／ネットワークが切れることも | 署名・互換性・再起動待ち |
| 後処理（カスタムアクション/UI） | 設定初期化、完了表示、追加設定、ログ生成など | 「完了」「失敗」など最終表示 | .NET 例外（1026）、外部依存の不整合 |
重要なのは、後処理で落ちても “すでにコミットされた部分” は残ることがある点です。つまり「インストールは進んだが、最後が落ちた」＝「入ってはいるが、完全ではない」になり得ます。
Event ID 1000 / 1026 の意味と読み方
イベントビューアーの 2 つのイベントは役割が違います。セットで出ている場合は「.NET で書かれた何かが落ちた」を疑うのが効率的です。
| イベント | ログ名 | 何を意味するか | 最優先で見る項目 |
|---|---|---|---|
| Event ID 1000（Application Error） | Application | 特定のプロセス（exe）がクラッシュした | 障害が発生したアプリ名／モジュール名／例外コード |
| Event ID 1026（.NET Runtime） | Application | .NET アプリで未処理例外が発生し、プロセスが終了した | 例外型／スタックトレース／.NET バージョン |
イベントログで必ず拾うべき「4点セット」
- 障害が発生したアプリケーション名（例：setup.exe、xen*.exe、msiexec.exe など）
- 障害が発生したモジュール名（例：KERNELBASE.dll、ntdll.dll、clr.dll など）
- 例外コード（例：0xe0434352 は .NET 例外でよく見かける）
- .NET Runtime の例外内容（System.NullReferenceException など）
特に、Event ID 1000 の「障害アプリ名」が XenServer Tools のセットアップ関連 exe なら、OS 一般の問題というより製品側・実装側の問題として切り分けやすいです。
まず確認：本当に「成功」しているのかを客観的にチェックする
ポップアップが「失敗」でも、実害が出ないこともあります。ただし XenServer Tools はドライバーやゲストエージェントが絡むため、中途半端に入ると後から運用で効くことがあります。次の観点で導入状態を確認してください。
| 確認ポイント | どこで見る | OK の目安 | NG のサイン |
|---|---|---|---|
| インストール登録 | プログラムと機能 | XenServer Tools が表示される | 表示されない／バージョンが空／修復が効かない |
| ゲストエージェント | サービス（services.msc） | XenService（名称は環境により異なる）が「実行中」 | 停止／起動失敗／存在しない |
| ドライバー導入 | デバイスマネージャー | Xen 関連デバイスが警告なし | 黄色い警告、不明なデバイスが残る |
| 管理ツール連携 | XenCenter 等 | Tools がインストール済みとして認識される | 未導入扱い／状態が不明 |
| リモート運用の安定性 | RDP/監視/バックアップ | 切断やタイムアウトが増えない | RDP が不安定、シャットダウン連携が効かない |
サービスが起動しない、デバイスに警告が出る、管理画面が Tools 未導入扱いのいずれかがあるなら、「入ったように見えるが完全ではない」可能性が高いです。
対処の優先順位：まず試す現実的な回避策（最短ルート）
Event ID 1000 / 1026 の組み合わせは、.NET 実行環境の破損・競合、または XenServer Tools 側の既知不具合で起きやすいです。現場で効きやすい順に並べます。
保留中の再起動を解消してから再実行する
ドライバー導入や .NET 更新が絡むと「再起動待ち」が残り、後段が例外で落ちることがあります。まずは Windows Update の再起動要求や、直前のソフト導入の影響をリセットするために再起動を挟みます。
- Windows Update が「再起動が必要」になっていないか
- 直前に .NET 更新や Visual C++ ランタイム更新をしていないか
- サーバー用途なら、作業前にスナップショット／バックアップを確保する
インストーラーを「管理者として実行」し、干渉要因を減らす
後処理ではサービス登録やドライバー操作が入るため、権限不足や EDR のブロックがあると例外化しやすくなります。
- setup.exe を右クリックして「管理者として実行」
- 強いセキュリティ製品がある場合、インストール中だけ例外設定や一時停止を検討（運用ポリシーに従う）
- 可能ならコンソール接続で実行（ドライバー更新で RDP が切れると、失敗に見えやすい）
.NET Framework を修復／更新する（Event ID 1026 が出ているなら最優先）
Event ID 1026 は .NET アプリが未処理例外で落ちたことを示します。アプリ側のバグでも起きますが、.NET の破損や依存関係の不整合があると落ちやすさが増えるため、まず OS 側の土台を整えるのが近道です。
| やること | 狙い | 効きやすい状況 | 補足 |
|---|---|---|---|
| .NET Framework Repair Tool の実行 | .NET 関連設定・ファイルの自動修復 | 突然 1026 が増えた／複数アプリが落ちる | Microsoft 提供ツールを利用 |
| Windows Update 適用（.NET 含む） | 既知不具合修正パッチの反映 | 更新が止まっている環境 | 再起動が必要なことが多い |
| SFC / DISM の実行 | システムファイル破損の修復 | KERNELBASE.dll 等が絡むクラッシュ | WSUS 環境ではソースが必要な場合あり |
| （必要なら）.NET 3.5 機能の有効化 | 古い依存の前提解消 | 古いインストーラーが依存している可能性 | Server Manager で有効化 |
コマンドの例（管理者のコマンドプロンプト／PowerShell）：
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth.NET 修復後は再起動し、同じ XenServer Tools インストールを再実行して再現性を確認します。「1回目は落ちたが、2回目は正常完了」というケースもあります。
XenServer Tools を「ホストに対応した版」で入れ直す
XenServer Tools はホスト側（XenServer / Citrix Hypervisor）との組み合わせ前提があります。古い Tools を新しい Windows に入れる、またはホストと異なる世代の Tools を使うと互換性問題が出やすくなります。
- ホストに付属する XenServer Tools ISO（または管理画面が提供する Tools）を使用する
- 既に中途半端に入っている疑いがある場合は、アンインストール → 再起動 → 再インストールを基本手順にする
- 同じ ISO を何度も使っている場合は、メディアを取り直して破損や展開失敗を疑う
原因究明を進める：イベントとログで「落ちた実体」を特定する
回避策で収まらない場合は、証跡を揃えて「何が落ちたか」を特定します。ここまでやると、ベンダー問い合わせでも話が早くなります。
Event ID 1000：障害アプリ名が何かで方針が変わる
- 障害アプリ名が msiexec.exe：MSI 実行中に落ちた可能性が高く、MSI ログ取得が最重要
- 障害アプリ名が setup.exe や Tools 固有 exe：ブートストラップ/UI のクラッシュで、.NET 修復や Tools 更新が効くことが多い
Event ID 1026：例外型で「権限」「欠落」「製品バグ」を切り分ける
| ログに出がちな例外 | 意味合い | ありがちな原因 | 先に試す対処 |
|---|---|---|---|
| System.UnauthorizedAccessException | 権限不足 | 管理者権限不足、ACL、EDR ブロック | 管理者実行、例外設定、実行ユーザー変更 |
| System.IO.FileNotFoundException | 必要ファイル欠落 | 展開失敗、メディア破損、依存不足 | メディア取り直し、Tools 更新、再インストール |
| System.Configuration.ConfigurationErrorsException | 設定読み込み失敗 | .config 破損、権限、特殊文字など | 再インストール、実行パス見直し |
| System.NullReferenceException | アプリ側ロジックの不具合 | 環境依存で再現する既知不具合の可能性 | Tools 更新、ベンダー情報確認 |
MSI ログを取る：インストールの「最後に何が失敗したか」を可視化する
セットアップが MSI ベースで動いている場合、ログを取れると原因究明が一気に進みます。MSI ログは情報量が多いですが、まずは「Return value 3」周辺を探すのが定番です。
MSI を直接指定できる場合の例：
msiexec /i "XenServerTools.msi" /L*V "C:\Temp\XenServerTools_install.log"setup.exe のようなラッパーの場合は、setup.exe /? でログオプションの有無を確認してください（引数は製品ごとに異なります）。
サポートに渡すと話が早い「証跡」一覧
社内での切り分けでも、Citrix/XenServer 側へ問い合わせる場合でも、以下をセットで揃えると最短で前に進みます。
| 情報 | 取得方法 | なぜ必要か |
|---|---|---|
| Event ID 1000 / 1026 の詳細 | イベントビューアーで該当イベントを開き、詳細タブの内容を保存 | 落ちた exe、例外、モジュールが特定できる |
| MSI ログ | msiexec の /L*V で取得 | どのアクションで失敗したかが分かる |
| Windows / .NET の状態 | winver、更新履歴、.NET の有効状態 | 特定ビルド依存の不具合切り分けに効く |
| ホスト側バージョン | XenCenter 等で確認 | Tools とホストの整合性確認に必須 |
| 再現手順（時系列） | 作業ログとして手順・時刻・結果を記録 | 再現できるほど解決が早い |
イベントログの書き出し例（必要に応じて）：
wevtutil epl Application "C:\Temp\ApplicationLog.evtx"「放置してよいか」の判断基準：XenServer Tools は特に慎重に
一般的なアプリであれば「動くならOK」で済む場面もありますが、XenServer Tools はドライバーや統合機能に直結します。中途半端な状態を放置すると、次のような “地味だけど効く” 問題に繋がることがあります。
- 管理画面からのシャットダウン／再起動連携が不安定
- ネットワークやストレージの性能・安定性に影響
- 時刻同期や監視の整合性が崩れる
- 将来の Tools 更新やアンインストールが失敗しやすくなる
最低でも、サービス稼働・デバイス警告なし・管理画面が Tools を認識の 3 点を満たす状態に寄せるのがおすすめです。
それでも直らないときの次の一手：製品側（Citrix/XenServer）で切り分ける
ここまで試しても 1000/1026 が消えない場合は、原因の軸を「OS」から「製品」へ寄せるのが現実的です。XenServer Tools は、特定 OS ビルドとの相性や、特定版インストーラーの既知不具合が解決策になることがあります。
- ホストに紐づく Tools の版を見直し、可能なら推奨される最新版で再実行する
- 同一 Windows バージョンの別 VM で再現するか確認し、環境依存か切り分ける
- インストールメディアを取り直し、破損や展開失敗を疑う
- イベントログと MSI ログを添えて、Citrix/XenServer 側のサポートやフォーラムで同様事例を探す
再発防止：インストールを “イベント化” しない運用のコツ
| やること | 効果 | 実務でのコツ |
|---|---|---|
| 作業前にスナップショット／バックアップ | 失敗時に即復旧できる | ドライバー更新は「戻せる前提」が重要 |
| Windows Update を先に適用 | .NET/OS の既知不具合を先に潰す | Tools より先に OS の土台を整える |
| Tools はホストに合わせる | 互換性問題を避ける | 古い ISO の流用を避ける |
| ログ取得を標準手順に含める | トラブル時に即分析できる | msiexec ログの保存先を決めておく |
まとめ
インストール中に「クラッシュしました」と出るのに導入が完了しているように見えるのは、インストーラーが多段で、最後の UI／後処理だけが落ちることで起き得ます。Event ID 1000 / 1026 が出ている場合は、まず 落ちた exe と .NET 例外の中身を確認し、.NET の修復と XenServer Tools の版の見直し（ホストに対応した版の利用）を軸に切り分けるのが最短ルートです。
コメント