- Installshield 2008 によって作成された MSI ファイルが「自己修復」によって再インストールされる原因となった変更のみをログに記録するにはどうすればよいですか?
- 自己修復の背後にある理由は何ですか?
- Installshield 2008 を使用して MSI の自己修復を無効にするにはどうすればよいですか?
1 に答える
自己修復、シンプル & ショート 説明:ファイルを削除すると MSI インストーラーが再構成されるのはなぜですか?
代替回答あり
更新: より短く、より「ソリューションに焦点を当てた」回答が利用可能です。おそらく最初に試してください。この回答は、問題を解決するための手順を説明するのではなく、「自己修復を理解する」ことに焦点を当てています。この回答の最初のセクションも読みたいと思うかもしれません。
予期しない Windows インストーラーの自己修復の問題 - クイック フィックス?
この「記事」は大きくなり、やや読めなくなりました。ここに新しく書かれた序文があります -予期しない自己修復を修正するための短い「回避策バージョン」です (VB6、Visual Studio、MS Office、MS Outlook、AutoCAD などでよく見られます...)
- 予期しない自己修復が発生した場合、最初に試すことができるのは、問題が発生したときに起動しているアプリケーションの実行可能ファイルへの直接のデスクトップ ショートカットを手動で作成することです。これにより、自己修復の最も一般的なトリガーである「宣伝されているショートカット」がバイパスされます。これが機能する場合、問題は「解決」(または回避) されています。ここに簡単で肉付けされた説明があります
- それでも問題が発生する場合、または問題がMS Office、MS Outlook アドインなど (ショートカットから起動できない) の読み込みに関連している場合は、システムで COM 登録の競合が発生している可能性があります。 、そして修正ははるかに複雑です。最も簡単な方法は、問題のアプリケーションのアドイン ダイアログで不要なアドインを無効にして、問題が解決するかどうかを確認することです。
- それでも問題が発生する場合は、多くの場合、本物の COM 登録の競合(または競合するファイル/MIME 関連付け、またはコマンド動詞) をデバッグする必要があります。これには通常、(少なくとも) システム上で競合する 2 つのアプリケーションが含まれます。これらのアプリケーションは、他のアプリケーションが実行された後、起動するたびにレジストリを更新します (常にいずれかのアプリを起動しても自己修復はトリガーされません。競合は次の場合に表面化します)。アプリケーションを交互に切り替えます)。また、パーミッションの問題により、同じアプリケーションがシステムの更新に失敗し、自己修復を繰り返し実行することで延々と試行し続ける可能性もあります。さらに可能性があります。詳細は以下をご覧ください。
- 「本当の修正」は、両方のアプリケーション ベンダーに連絡して問題の修正を依頼することですが(多くの場合、修正には両方のベンダーの MSI の修正が必要になるため)、これが成功することはめったにありません。ただし、これを試してみてください - これは長年悩まされているすべての人を助ける方法だからです! 私は個人的に銀行の展開の修正を含むセットアップを提供しましたが、パッケージで問題が解決されてとてもうれしかったです
- 自分でデバッグするには、システムにキャッシュされた MSI ファイルを開くためのツールを入手する必要があり、データベースを「ハック」する必要があります。これは非常に複雑な作業であり、専門家のスキルが必要です。この問題は、デスクトップ環境にとって非常に深刻です。うまくいくかもしれませんが、奇跡を期待しないでください。
- MSI ファイルを表示および変更するためのツールを入手する方法の詳細については、以下の「自己修復のトリガーまたは犯人を見つける」というセクションを参照してください。
「記事」の残りの部分では、自己修復の問題について詳しく説明します。この「短い」セクションで説明されている以外にも、自己修復の潜在的な原因は多数あります。
全体的な問題: 開発者のデバッグと自己修復
Windows インストーラーは展開テクノロジです。その役割は、指定されたファイルとレジストリ設定をインストールし、指定されたインストール場所に保持し、それらが正しいバージョンであることを確認することです。自己修復または回復力は、そのためのメカニズムです。その操作は、開発者がデバッグ、開発、およびテストのためにオンザフライでファイルを交換する必要があることと競合します。
したがって、多くの自己修復(回復力) は、開発者がインストール済みのアプリケーションとその場でホットスワップ ファイルをデバッグしようとすることによって引き起こされます。これを処理する方法については、以下の「いくつかの典型的な自己修復問題のシナリオ」のセクション 2 を参照してください。また、修正が必要なMSI の真の設計エラーや、自己修復につながるシステム管理の落とし穴がある場合もあります。また、エラーの原因を見つけるのが難しい場合もあります。
serverfault.com の回答で自己修復の問題について書きました。システム管理者向けの言葉とは少し異なります。今読んでみると、この長い説明 (開発者向け) よりも理解しやすいかもしれません。また、stackoverflow に関する別の短い回答もあります。ファイルを削除すると、MSI インストーラーが再構成されるのはなぜですか? (これはおそらく最も短く、理解しやすいものです)。そして最後に、 Vadim Rappによる自己修復に関する非常に優れた記事を見つけました: How to fix Windows Installer Efforts to Self-Repair。この記事は一読の価値があります。
起動する製品が正しくインストールされていると Windows インストーラーが判断した場合、自己修復は行われません。自己修復が発生した場合、アプリケーションを適切に実行するには、システムで何かを変更する必要があります。
自己修復の主な原因
詳細は、以下のセクション「いくつかの典型的な自己修復問題のシナリオ」に示されていますが、簡単な予兆リストとして- 主な原因は次のとおりです。
1. 不適切にパッケージ化された企業の MSI ファイルまたはベンダーからの MSI 設計上の欠陥(MSI パッケージ自体の設計が不適切であり、さまざまな理由で予期せず自己修復をトリガーします)
- ユーザーごとのファイルまたはユーザーごとのレジストリ キーの過剰または誤った使用。多くの場合、(HKCU ではなく) ユーザー プロファイルに誤ったキー パスが設定されています。詳細については、以下のセクション 5 を参照してください (およびそのような状況のカラー イラスト)。
- 誤った COM サーバーの登録によるパッケージの干渉(特に、Autodesk の
AutoCADなどの製品のVB6 COM ファイルまたはVBA ファイルとライブラリ、および同様の製品)。
- 2 つの MSI パッケージは、2 つの異なる場所から同じ COM ファイル (ActiveX/OCX) を登録し、アプリケーションの起動ごとに「自己修復の戦い」を行って、バージョンを正しく登録します。
- 最後に起動されたアプリケーションは、レジストリを自分自身に適切に置き、他のアプリケーションが起動されて同じことを行うまで続きます。アプリケーションを切り替えると、問題が発生します。VB / COM 自己修復の詳細については、以下のセクション 7を参照してください。
- コンポーネント キー パスは、Windows インストーラーが自己修復時に削除する空のフォルダーに設定されます (削除とその後の自己修復の無限ループをトリガーします)。
- ACL ロックダウン許可の問題 (ログオン ユーザーがキー ファイルにアクセスできず、Windows インストーラーが修復を繰り返しトリガーする)。これは、外部で行われた ACL の変更によっても発生する可能性がありますが、多くの場合、MSI 自体によって行われます
- これは、一般的な MSI 設計の欠陥を説明する serverfault.com の進行中の作業です。
2. ファイルまたはレジストリ キーは、(ログオン) スクリプトから標準の OS 機能、ウイルス、セキュリティ ソフトウェアなどに至るまで、外部要因による干渉によって削除されます。
- 一時ファイルは、MSI パッケージによって一時フォルダーに誤ってインストールされた後、Windows によって自動的に削除されます。
- 不正なログオンによる干渉- ハッピー クリーンアップ スクリプトとクリーンアップ アプリケーションのトリガー
- ウイルス対策アプリケーションがファイルまたはレジストリ キーをブロックまたは削除するため、Windows インストーラーはそれらを検出またはアクセスできなくなります
- ファイルおよびレジストリ設定を変更または削除するコンピュータ ウイルス
- 過活動なコンピューターいじくり回しやユーザーは、理解できないファイルや設定を削除します
3. Windows の設計変更、欠陥、または制限により、欠陥または問題のある展開が発生する
- AD が宣伝する MSI パッケージはインストールに失敗し (インストールに時間がかかりすぎるためキャンセルされる可能性があります)、人々を悩ませ続けます。これは厳密に言えば自己修復ではなく、打ち切られた宣伝されたインストールですが、結果は同じです:無限の再インストール
- ターミナル サーバーの複雑化。通常、ターミナル サーバーでは自己修復は完全に無効になっています。通常、これによって自己修復の問題が発生することはありませんが、アプリケーションは、必要なユーザーごとのファイルやレジストリ キーなしでインストールされます。これらのファイルは、自己修復の無害な使用によって追加できます (以下を参照)。ユーザー ファイルとユーザー レジストリ キーが失われ、問題が発生します。
- UACの干渉、証明書の検証の失敗、およびWindows の設計変更に起因するその他の問題。Windows のすべてのバージョンで、このようなセキュリティ機能が追加され、通常、信頼性の高い展開に新たな障害が追加されます。
- 特定のWindows 更新プログラム(更新プログラム、セキュリティ更新プログラム、修正プログラムなど) でさえ、MSI パッケージのセキュリティの実施方法を大幅に変更することができ、その結果、非常に問題のある動作を引き起こす可能性があります。
- これは MSI の作成に関連しており、主にエンド ユーザーによる使用ではありませんが、 失効したルート証明書を Windows がチェックする方法を更新するWindows Update KB3004394は、Installshieldのコマンド ライン ビルドの古いバージョン (デジタル署名されたセットアップの場合) を壊します。これで大部分は解決された問題ですが、Microsoft がコア MSI 機能をどのように変更し続けているかを示しています
- 同様に、Microsoft 更新プログラム MS14-037「Internet Explorer バージョン 6、7、8、9、10、および 11 のセキュリティ更新プログラム」をインストールした後、多くのユーザーで Installshieldがクラッシュしました (KB2962872)
- kb2918614 (Vista) のインストール後に、Windows インストーラの基本機能に非常に問題のある変更が発生しました。突然、単純な MSI 修復操作に管理者の資格情報が必要になりました。これにより、MSI の主な利点である一時的な管理者権限で承認されたインストールを実行できる通常のユーザーの機能が完全に失われました。その修正をインストールした後、他の報告された MSI の問題もありました。別の Windows アップデートで問題が修正されたようです: kb3008627 (後で kb3072630 に置き換えられました)
セルフリペアについて
Windows インストーラーは、アプリケーションのバイナリ、設定、およびデータ ファイルをインストールし、それらをインストールしたままにして、それらが正しいバージョンであることを確認するように設計されています。自己修復はそのためのメカニズムです。全体的な概念は回復力と呼ばれます。つまり、インストールが破損すると、アプリケーションが起動される前に自己修復がトリガーされます。
回復力、または自己修復は、Windows インストーラーに組み込まれている主要な概念であり、安全な方法で無効にすることはできません。人々は、 Windows インストーラ エンジン全体を無効にして自己修復を停止するなど、非常に驚くべきことを行うことがあります。これは明らかに絶対に行ってはなりません。新しい問題を作成したり、システムをハッキングしたりするのではなく、修復の原因を特定し、問題を解決する必要があります。
アドバタイズされたショートカット(ファイルを直接指定するのではなく、Windows インストーラの機能を指定する特別なショートカット)を起動するたびに、Windows インストーラは製品の「コンポーネント キー パス」をチェックしてインストールを検証します。不一致が見つかった場合は、不完全なインストールを修正するために修復がトリガーされます。「コンポーネント キー パス」は、MSI 内のコンポーネントに指定された「キー ファイル」です。コンポーネントごとに 1 つあります。自己修復は、誰かが COM サーバーをインスタンス化する (またはしようとする) こと、ファイル拡張子または MIME 登録を介してファイルをアクティブ化すること、および他のいくつかの方法によって開始することもできます。「自己修復エントリ ポイント」に関するシマンテックの包括的な記事を次に示します。Entry Point による自己修復と広告機能の開始。
ファイルが削除、移動、または単純に上書きされた場合 (ユーザーが手動で、または何らかの形で自動的に)、自己修復が行われる可能性があります (ファイルまたはレジストリ設定がキー パスとして設定されていない場合、自己修復はトリガーされません)。
自己修復のトリガーまたは原因を見つける
自己修復のトリガーは、通常、自己修復が行われたシステムのイベント ビューアで見つけることができます。次の手順に従って、イベント ビューアーを開きます。
- 「マイコンピュータ」を右クリック
- [管理] をクリックします
- UAC プロンプトが表示されたら、[続行] をクリックします。
- イベント ビューアー セクションに移動し、Windows ログを確認します。
別の方法として、次のように実行することもできます: Start => Run... => イベント ビューアーのみのeventvwr.exe 。スタート メニューに run が表示されない場合は、WINKEY+を押しますR。
- イベント ログの「アプリケーション セクション」を見ると、ID 1001 および 1004 のイベント ソース「MsiInstaller」からの警告が見つかるはずです。
- 上記のサンプル スクリーン ショットでは、製品コードが赤いボックス内に示されています。
- 製品コードがどの製品のものかを判断するには、次の手順で製品名を調べることができます:インストールされている MSI セットアップの製品 GUID を見つけるにはどうすればよいですか?
- MSI ファイルの実際の内容を詳しく調べたい場合は、MSI ファイルを表示できるツール ( Orca、Installshield、Advanced Installer など) を入手する必要があります。次に、前の箇条書きにリンクされている回答にあるスクリーンショットに示されているように、「LocalPackage」パス リストにリストされているパッケージを開きます。
- (宣伝されている) ショートカット、COM 登録、ファイルの関連付け、MIME の関連付け、またはコマンド動詞などの宣伝されているエントリ ポイントを削除するために、システムにキャッシュされた MSI ファイルやレジストリを実際に変更することは、専門家の仕事です。これは非常に複雑で、良い方法ではありませんが、私が知っている唯一の「最後の手段」です。
- 最後に、アプリケーションが Windows インストーラー自体を明示的に呼び出して、共有コンポーネント (スペル チェッカーなど) の自己修復をトリガーすることができます。Microsoft Access のいくつかのバージョンでこれが行われたと思いますが、私の知る限り、この動作を変更または回避することはできません。
MSI の専門家でMVP の Stefan Krügerには、同じ自己修復の問題に関する記事があります。そして、彼は実際のイベント ログ エントリとその意味について非常に重要な議論をしています。実際のデバッグ手順についてはそちらをお読みください。
いくつかの典型的な自己修復問題のシナリオ:
これは、上記の概要で既に概説したいくつかの自己修復の問題シナリオの「詳細な説明」です。
- コンポーネントキー パスは、Windows インストーラーが自己修復時に削除する空のフォルダーに設定されます(削除とその後の自己修復の無限ループをトリガーします)。これは、代わりにCreateFolder テーブルにフォルダーを追加することで解決されます( Wix と同等)。私の経験では、これは不要な自己修復の最も一般的なシナリオです。非常に一般的です。
多くの自己修復の問題は、開発者がアプリケーションをその場で置き換えたり、ファイルを削除したり、名前を変更したりして、アプリケーションをデバッグしようとすることによって実際に引き起こされます。または、クリーンアップレジストリ スクリプトやバッチ スクリプトを使用して、COM ファイル、COM-Interop、GAC ファイル、ファイルの関連付け、またはその他の一般的な開発者のデバッグおよび開発タスクを登録解除および登録する場合があります。
このホットスワップは、アプリケーションがアドバタイズされたショートカットを介して起動されると、自己修復をトリガーする可能性があります。
アプリケーションのデバッグ中に自己修復に苦労している開発者にとっての最大のヒントは、宣伝されているショートカットからアプリケーションを起動するのではなく、Windows エクスプローラーから直接、または手動で作成したショートカットからメインの EXE を起動することです。これにより、最も一般的な「自己修復のエントリ ポイント」である宣伝されているショートカットがバイパスされます。自己修復は、破損した COM データ、アドバタイズされたファイルの関連付け、およびその他のいくつかの特殊なケース (エントリ ポイント情報については、この Symantec の記事を参照) が原因で発生する場合があります。
他のアプリケーションまたは他の MSI パッケージは、レジストリ データ (通常は COM 設定だけでなく、他の設定やファイル) に干渉することで、インストールを中断し、自己修復を引き起こす可能性があります。アプリケーションは基本的にそれと戦い、最後に実行されたアプリケーションが毎回レジストリを更新するため、これらは解決するのが最も難しいケースの一部になる可能性があります。通常、アプリケーションが同じマシン上で動作するには、両方の MSI ファイルを再設計する必要があります。または、日常的に、アプリケーション全体が仮想化され (たとえば、Microsoft App-V 仮想パッケージ)、独自のサンドボックスで実行される場合があります。これは、最近の企業でますます行われているようです。このエラー シナリオは、多くの場合、一連の企業環境でアプリケーションをうまく再パッケージ化できませんでした。異なるパッケージの COM フラグメントが別のパッケージの COM サーバーのディスク パスを上書きし、宣伝されたショートカットを介してアプリケーションを起動するたびに自己修復の戦いが発生します。異なるファイル バージョンの同じファイル名が、異なるファイルの場所から登録され、干渉するいくつかのレジストリ設定を共有することもできます。私が思い出す限り、COM サーバーを適切にインスタンス化するには、ファイル システムとレジストリの少なくとも 7 つの変数または設定が同期している必要があります。VB6およびVBA COM アプリケーションのコンテキストにおける COM 干渉のより専門的な説明については、以下のセクション 7を参照してください。
コンポーネント キー パスは、アプリケーションによって削除された一時ファイルを指しています。または、何らかのクリーンアップ メカニズム (ccleaner などのクリーンアップ ツールの場合もあります) によって最終的にシステムによって削除されます。これは、一時フォルダー自体のファイルに共通です。これは、一時ファイルをインストールしないか、ファイルを別の場所に置いて永続的にすることで解決されます。このエラーは、企業アプリケーションの再パッケージ化の世界で最も頻繁に見られますキャプチャされたイメージのクリーンアップに失敗すると、パッケージにまったく含まれていないはずの一時ファイルがインストールされます。多くの場合、それらは再起動が意図した、おそらく保護された場所にインストールされるのを待っている一時ファイルである可能性があり、再起動は実行されませんでした - 一般的なアプリケーション パッケージ エラーです。程度は低いですが、自動ビルド システムから自動生成されたパッケージで見たことがあります。
パーミッションの問題: アプリケーションを呼び出すユーザーがアクセスできない場所にコンポーネントのキー ファイルがインストールされている場合。Windows インストーラーは、インストールされたファイル/キー パスを「認識」しないか、フォルダーにファイルを追加できない場合があります。これらの問題は、デバッグするのがより風変わりである可能性があり、それほど頻繁には発生しない可能性があります。この問題にはいくつかのバリエーションがあります。
- この例としては、ファイルを%USERPROFILE% パスにインストールした後、HKCU レジストリ キーパスを設定するのを忘れ、代わりにキーパスを %USERPROFILE% フォルダー/ファイルを指すように設定した場合が挙げられます。これにより、通常、ユーザー固有のアクセスできないハードコードされたキー パスが生成されます: C:\Documents and settings\user1\Desktop。このパスは、ログオンしている別のユーザーには見つからず、自己修復は循環して実行されます。こちらはカラーイラストです。
- もう 1 つの例は、システム アカウントに対して書き込み可能ではないフォルダーに設定されたキー パスです。これは奇妙に思えるかもしれませんが、MSI によるシステム ACL エントリの誤った変更、システム管理者の奇妙なセキュリティ設定、またはその他の非標準 ACL/セキュリティ記述子が原因である可能性があります。
ターミナル サーバーとCitrixに関連して、別の種類の自己修復の問題が発生します。Windows インストーラー サービス全体がロックダウンされる可能性があるため、ユーザーごとのデータを追加するために呼び出された自己修復が失敗し、その結果、自己修復が失敗するか、まったく実行されない可能性が高くなります。これは、一部の MSI ファイルのようにユーザー データを追加する方法として自己修復に依存しない十分な理由であり、そのような構造は、コンピューターごとの場所からコピーされたユーザー ファイルのアプリケーション展開または Microsoft の効果の低いActiveSetup機能に置き換える必要があります。ユーザーごとに 1 回実行されます。
VB6 アプリケーションとVBA アプリケーションは、 COM 干渉(COM 設定が相互に上書きされて不整合になる) の可能性が非常に高い COM ベースであり、いくつかの不可解な自己修復問題を引き起こすことが知られていますが、そのほとんどは適切に説明されていません。これは、Visual Basic 6 (VB6) または Visual Studio (および他の多くのアプリケーション) の起動時にも発生する可能性があります。共通点は、現在のインストール状態の何らかのエラーが原因で自己修復がトリガーされたことです。上記の「自己修復のトリガーまたは原因を見つける」セクションで概説した手順に従って、原因となっている製品とコンポーネントを突き止めることができます。 .ここで調査結果を必ず報告してください(私はもう VB6 や VBA を使用していません。詳細な調査結果は、長年悩まされている他の人を助けることができます)。
- このような VB6 の問題を詳細にデバッグしたことはありませんが、問題は、共通コントロール、VB6 COM ファイル、テンプレート、VBA ファイル、およびライブラリをインストールするアプリケーションが、既存のファイルおよびレジストリ設定とボックス上の登録と競合することから生じるようです。または、ユーザーごとのレジストリ キーまたはユーザー プロファイル ファイルをユーザーごとに 1 回追加する必要がある場合があります (自己修復を 1 回完了させ、問題が解決するかどうかを確認します)。特に、 AutoCAD (Autodesk から)、Visual Basic 6、およびその他のいくつかの製品 (多くの場合、ツールで利用可能な VBA オートメーションを使用)を起動するときに、これらの不思議な自己修復の問題について聞いたことがあります。
- 一部のアプリケーションは、VB6 ランタイムからビットとピースを誤って独自にインストールすることさえあり、それらのアプリケーションのアンインストール時にこれらの設定が「取り除かれます」。これにより、自己修復がトリガーされ、現在 (部分的に?) 壊れている VB6 ランタイムが修正される可能性があります。この問題にはいくつかのバリエーションがあり、VB6 ランタイムを完全にアンインストールして再インストールすることで、「すべてをキャッチ」することができます。ここでは、いくつかの COM レジストリ キーに関連する非常に一般的な「特定の」問題について説明します。このシナリオで何が起こるかをうまく説明しています。
- VB6、AutoCAD、Visual Studio、またはその他の製品を起動したときに予期しない自己修復が発生した場合は、最初に回避策を試して、これらの予期しない自己修復が最初に発生しないようにすることができます (これは問題を解決しませんが、バイパスする可能性がありますその症状): Visual Basic 6 を起動するたびに Windows インストーラーが起動するのはなぜですか
- 最も典型的な VB6 スタイルの自己修復の 1 つについては、このトピックの質問に対する私のコメントを参照してください。(ActiveX コントロールは、ディスク上の 2 つの異なる場所から 2 回登録されます)。
- 私の意見では、VB-COM の自己修復の問題に対する "一般的な修正" - 常に機能するはずです - は、ベンダーに問題のプロジェクトを更新して、最新の公式で適切にインストールされ、共有されている ActiveX コントロール / OCX を使用するように依頼することです。重複してインストールされ、間違った場所に登録された独自のバージョンに依存しないでください。
完全を期すために言及する価値のある Windows インストーラーの修復または自己修復の特殊なケースは、自己修復がトリガーされる数年前の Microsoft Office の問題であり、Microsoft Office インストール メディア(当時は CD-ROM や DVD でしたが、今日ではおそらくサム ドライブです)。私が思い出す限り、これは組み込みの Windows インストーラー標準アクション " ResolveSource " への誤った呼び出しに関連しており、予期せず (そして不必要に) インストール メディアのプロンプトをトリガーしました。非常に一般的なサポート コールバックは、完全を期すためにここで言及されています。この問題は引き続き発生する可能性があることに注意することが重要ですMS Office が任意のリムーバブル メディアからインストールされるときは常に(ネットワーク共有のより良いオプションではなく)。これは、MS Office が、最初にインストールされなかった製品のオプションの (通常は共有の) コンポーネントをさらにインストールする必要があることを検出した場合に発生します。たとえば、珍しいスペルチェッカー、さまざまなテンプレート、特定のめったに使用されないツールなどです。これらのコンポーネントを「初回使用時にインストール」するようにインストールすることができます (アドバタイズされた機能は、適切な Windows インストーラー用語です)。
他にも多くのシナリオが考えられます。いくつか言及すると:
- 不正なログオン スクリプトにより、システム上のものが削除され、自己修復がトリガーされる可能性があります
- AD で宣伝されているパッケージはインストールに失敗し、人々を悩ませ続ける可能性があります
- 2 つのアプリケーションが同じファイルの関連付けをめぐって争い始めることがある
- コンピュータいじくり回しやハッカーは、自己修復をトリガーするデータを手動で削除できます
- ウイルス対策は、修復をトリガーするファイルとレジストリ設定を隔離できます
- ウイルスは物事を変更または削除し、自己修復を引き起こす可能性があります
- ccleaner などのディスクおよびレジストリのクリーンアップ ツールを使用すると、ファイルを削除して自己修復をトリガーできます。
- 間違いなく他の多くのシナリオ...
自己修復のための無害な使用
最後に、一度発生し、エラーを構成しない自己修復の無害な使用法があります。これは自己修復の合法的かつ適切な使用法ですが、設計エラーと同じくらい厄介であり、ユーザーの介入により何度もポップアップする可能性があります。
- 自己修復は、ユーザーごとのデータをHKCUおよびユーザー プロファイルに追加するために使用されることがあります。この設計はほとんどの場合機能しますが、Windows のすべてのバージョンで、展開のために新たな障害が発生するにつれて悪化します。1 つには、自己修復は通常、ターミナル サーバーではまったく機能せず、セットアップが不完全になります。この説明の要点とは異なりますが、アプリケーションでファイルをユーザーごとの場所にコピーすることをお勧めします。別の問題は UAC です。その他の問題は、新しい Windows バージョンごとに表示され、上記の一部の Windows Update でも表示されます (仮想フォルダーのリダイレクト、証明書のプロンプト、以前は存在しなかったターゲット パスの制限など...)。
- ユーザー データを設定するために自己修復が必要な場合、ユーザーがデータを中止して継続するまでに時間がかかる場合があります。これにより、自己修復が終了するまで常に再表示されます。一般的なサポート コール。
- アプリケーションの使用中に「オンデマンド」でインストールされるように設計された「アドバタイズ機能」を備えた製品をインストールすることもできます。これを使用するアプリケーションはほとんどありませんが、使用すると、長い「自己修復スタイル」のインストーラーが実行され、必要なファイルと設定が引き出されます。このプロセスがキャンセルされた場合、機能のインストールはロールバックされ、再びトリガーされる可能性があります。このインストールは、いくつかの理由で遅くなる可能性があります。
- インストーラーが使用した大きな圧縮 CAB ファイルは、最初にダウンロードされて低速ディスクにローカルに抽出され、アンチウイルスが CAB全体のスキャンを開始し、抽出された各ファイルの操作に時間がかかる可能性があります。
- ネットワーク接続がワイヤレスで、ダウンロードする小さなファイルがたくさんある場合(待ち時間が長い場合) も動作が遅くなる可能性があり、ウイルス対策によって動作が遅くなる可能性があります。
- リムーバブル メディアからインストールした場合、ソース メディアを挿入してファイルをコピーできるようにするよう求めるメッセージが表示されることがあります。リムーバブル メディアがオフィス環境で使用されている場合の非常に一般的なサポート コール (そうすべきではありません -ネットワーク共有で管理者用インストールを使用します) 。
- 等...