1

複数の顧客サイトで、当社のパッチの 1 つに異常な散発的な障害が発生しています。最終的なエラー コードは 1648 (パッチ セットに有効なシーケンスが見つかりませんでした) です。これは、パッチ トランスフォームの 1 つから概要情報ストリームを読み取ろうとしたときにエラー 2219 (無効なインストーラ データベース形式) が発生したために発生しています。しかし、これは以前のサイレント エラーの副作用に過ぎないと思います。私たちのパッチはすべて MinorUpdateTargetRTM プロパティを使用しているため、以前にインストールされたパッチは自動的に置き換えられるため、シーケンスする必要はありません。当社のお客様は通常、ほぼ同一のラップトップを数百台使用しており、ほとんどのお客様がこの更新プログラムを問題なくインストールしています。ほとんどの場合、1 つのデバイスだけが更新に失敗しています。

ログの主要なセクションは次のとおりです。初期化が完了し、Windows インストーラー サーバー プロセスが実行シーケンスを開始します。最後の通常のログ エントリは、「Doing action: ISSetupFilesExtract」です。ISSetupFilesExtract は、実行シーケンスの最初のアクションです。3 分間の一時停止があり、その後、インストール全体が何らかの形でリセットされ、最初からやり直されたように見えます。次のログ エントリはクライアント プロセスによって書き込まれます。通常、サーバー プロセスは実行シーケンスを実行し続けます。インストールの最後まで、クライアント プロセスから別のログ エントリが表示されることはないと思います。ここで何らかの壊滅的な障害が発生していると思われますが、それが何であるかはわかりません。SequencePatches が失敗するのは、この不可解なリセットが発生した後でのみです。1回目で無事終了。

MSI (s) (C4:58) [09:28:32:565]: Doing action: INSTALL
Action start 9:28:32: INSTALL.
MSI (s) (C4:58) [09:28:32:581]: Running ExecuteSequence
MSI (s) (C4:58) [09:28:32:581]: Transforming table InstallExecuteSequence.
MSI (s) (C4:58) [09:28:32:581]: Transforming table InstallExecuteSequence.
MSI (s) (C4:58) [09:28:32:581]: Note: 1: 2262 2: InstallExecuteSequence 3: -2147287038 
MSI (s) (C4:58) [09:28:32:581]: Doing action: ISSetupFilesExtract

<-- What happened here?! -->

=== Verbose logging started: 7/21/2014  9:31:38  Build type: SHIP UNICODE 5.00.7601.00  Calling process: C:\MyCompany\Pwhc\Apps\AplPch.exe ===
MSI (c) (44:50) [09:31:38:192]: Font created.  Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg

私の質問は、インストールプロセスがこのように「リセット」される原因を誰か知っていますか?それについて私にできることはありますか? 前述のとおり、このパッチは 99% の確率で正常にインストールされます。失敗したマシンの完全なログは、https ://docs.google.com/document/d/1LK6HdIcetKOGqFbi5nGKAuDolvhZ3PcLxzJHv2wNDsQ/pub で入手できます。ありがとう。

コメントへの追加情報:

当社の製品は、サービス パック リリースには MSI を使用し、ポイント リリースにはパッチを使用します。各パッチは累積的であり、MinorUpdateTargetRTM プロパティを使用して以前のすべてのパッチに取って代わります。これらは、主にアプリケーション ファイルを更新するために使用されます。信頼性を向上させるために常にファイル全体を含め、ビット レベルのパッチは使用しません。ベース MSI は 46 MB で、1778 個のファイルが含まれています (これは複雑なエンタープライズ製品です)。失敗しているパッチは非常に大きく、57 MB です。240 の新しいファイルを追加し、413 の既存のファイルを更新します。

4

1 に答える 1

1

パッチを効果的に使用しているように聞こえますが、パッチに関する私の一番のルール、つまりベースの MSI よりも小さくする必要があることを確実に破っています。

その理由は単純明快で、パッチはすでに機能している更新プログラムを配信するためのメカニズムに過ぎないからです。そのため、元のセットアップ自体よりも複雑でエラーが発生しやすいコンテナーにすぎません。そのサイズが元の MSI を超えると、パッチを使用する明らかな理由がまったくありませんか? 変更せずに完全なセットアップを実行できますか? 実際、問題が発生したシステムでそれを正確に試す必要があります。

多分私は何か重要なものを見逃していますか？おそらく、それはより速くインストールされますか？適切に作成されたマイナー アップグレード、またはアンインストールと再インストールを行わず、古いバージョンの登録を解除するだけのメジャー アップグレード (RemoveExistingProducts の遅いシーケンス) も同様に高速です。

長年の経験と展開の専門知識にもかかわらず、私はパッチ適用の専門家ではありません。私は積極的にパッチの使用を最小限に抑えようとしています。しかし、これは私のパッチ適用経験の一部を掲載した投稿です。

これがまったく答えのないように思われる場合は申し訳ありませんが、パッチが 57 MB で非常に不要であるように思われるため、これは有効な入力であると思います。また、回避策が既にあるはずです: 完全な更新 MSI.

于 2014-07-24T20:38:26.910 に答える