NONさん
ご提案有難うございます。
ただ、ＧＷ前の仕事の多忙さもあり
まとまった時間を要する作業時間をなかなか取れず、すみませんでした。
結果ご報告いたします。
ターミナルサービス(Terminal Service) が停止している(自動起動になっていない)と、「UI Failed to load.」と表示される現象が起きる場合があるようです。
正確性を高める為、2回再現検証しました。
このサービスは、無効にしてありました。
そして、17.3.2.291でUIが起動しない状態で手動に切り替えたら、無事起動しました。
ただ、現在ＸＰでこのサービスを有効にしている人は居ないかと存じます。
有効にすると、ウィンドウズ・アップデートの自動更新の切り替えや、
他、Winのセキュリティ関係の設定状態の確認をするツールが起動し、タスクトレイに状態アイコンが常駐するようになるからです。
また、外部からの新たなアクセスを許可するサービスでもある為、
セキュリティ上有効にしたくないので、この手法は見送り
どうにか他の方法でUI起動する17.3.2.291に更新するか、
ロールバックで2288をキープ出来る道を選択しました。
以下、自身の環境下に限った話とはなりますが
一つ言えるのは、
17.3.2.291のUIでは
明らかにこれまで不要だったアクセス権限許可をしないと起動しない、ということです。
企業がなにを目的に、こちらのリソースにアクセスしようとしているのかはわかりません。
今の仕様では、許可しなくても動作や性能に影響も関係もさほどなさそうなものですが、
裏で知らぬ間にアクセスしようとしてきたり
もっと許可しろと言われるのは、正直怖いものです。
ましてや、このサービスはマイクロソフトアップデート絡みのものですし
ＸＰで有効を求めるのはおかしいです。
不用意に仕様変更したなら、メーカー側は控え、修正すべきですし、
変更するなら、その旨、利用者側に説明と、出来れば確認も取るべきと考えます。
より正確に診断し、保護する為にアクセスが必要となるならば
このような不都合の出ない、別の手法を模索すべきと思います。
再度申し上げますが、
これは、あくまでも自身の環境下で起きた事象を元にした意見となり、
他環境下で同様の状態が再現される保障は無い旨、読まれる方は誤解のないようお願いします。
ウイルス定義も手動更新にしたうえでネットワークに接続し、再起動 -> 10分程度待つを数回繰り返し(この間にAvast のパッチの適用が実施されるはずです)、それから定義ファイルを更新してみて、どうなるかでしょうか。
こちらも2回、前回と差の出ないよう、クリーンインストール状態に戻してから検証してみました。
ただ、個人的にこのソフトの起動処理アルゴリズムを正確に把握していない為
そちらの危惧している検証したいポイントや、
失礼ですが、少し仰られていることの意味が判りかねる部分があり
※この提言は、17.3.2.291でUI起動させる為のもの、とも受け取れますし
２２８８から勝手に自動更新を阻止する為の確認手法、とも受け取れた為
17.3.2.291への更新は、これまでの結果から失敗の可能性が高いと判断し
自分なりの解釈で、２２８８で止める為の検証として、行いました。
監視した上での流れ
＞2288をOFFLINEインストール後、プログラムと定義、双方を手動更新に設定。
＞再起動し、ネット接続後、プログラムの最新版有無の確認が入り、17.3.2.291が利用可能との通知が更新UI画面上に表示される。
＞次に、定義の更新確認が入り、更新有の通知がタスクトレイ上へポップアップ表示され、手動設定の有効性を確認。
＞その後、１０分放置監視し、勝手にプログラムまで更新されるかを監視したものの
今回はＫＢkb970158_x86.exeは実行されず、プログラムも強制更新されずに、AVAST更新の動きも静止状態へ。
＞再度、再起動し、各種更新の挙動を10分ほど監視するものの、定義の更新有無のポップアップ確認が入った後は静止状態へ。
＞定義を手動で更新し、適用後、そのまま10分放置監視するものの、ＫＢやプログラム更新は発生せず静止。
＞再々起動かけ、挙動を監視するものの、特にどの更新も入ることなく、終了。
以上。
今回は、強制更新が入らず、2288で留まることが出来ました。
前回と全く同じPC状態（何もイジらず、クリーンインストール準備の為に掃除した手法も削除したゴミも一切が全く同じ）
違うのは、定義を手動にした点と、先に述べたKBの適用が今回は無かった点です。
KB970158はカーネルドライバのアップデート
とのことですが、
このパッチは前回でインストール済みであった為、今回発生しなかったのか？までは、つかめませんでした。
適用済みのパッチ一覧を呼び出して確認しましたが、全てを呼び出せず、一覧には見当たらずでした。
このＫＢが強制更新に絡んでいたか？今となっては判り様がありませんし、
提言通り、定義の適用を手動に切り替えた事が、功を奏したのかも不明です。
UIの起動が失敗するようになる人、ならない人が同じOSで居る以上、すっきりしませんよね。
そちらが、今回提言で気にされていた、処理の順番や通信状態などに起因するか？という点は
不明な点ばかりですね。
個人的にも、XP環境のＰＣなどは
基本処理が遅く、バッファやキャッシュの帯域も狭い、大きな処理を一括でこなせない、という点もある為
それらの内のどれかに、ちょっとした延滞や停滞が、更新作業という一番デリケートなタイミングで発生したり
更新の順序も狂うだろうし、飛んだり、正常に記録されなかったり、設定されなかったりすることも
十分起こり得る、とは思っています。
AVASTそのものも少し改善の余地はありそうですが。
ちなみに、それが嫌なので、
自身の環境下では極力無用な負荷をかけない、リソースを無用に消費しない、
軽快な最小構成OSに設定にし、業務用のワークステーションＰＣと光高速回線を使用し
混雑しない明け方などのタイミングで検証しています。
２２８８で各種スキャンが出来る様になったので、一歩進めたのですが、
なぜ強制更新されなかったのか？どうすれば最新版でUIを無事起動出来るのか？
まだ不明な点ばかりです。
メーカー側で、ターミナル・サービスの有効有無について言及してくれさえすれば
諦めもつくのですが。。
２２８８には致命的なバグや脆弱性もあり、更新出来るなら、そうしたいことに変わりありませんので。
今回の英フォーラム下調べや数々の有用な提言により、
まがりなりにも２２８８へは進めました。
貴重なお時間を割いて頂き、大変感謝しております。
また他に、アドバイスがおありでしたら
今後とも引き続き、宜しくお願いいたします。