services.exeは、コマンドラインmsiexec.exe / vを使用して、ソフトウェアの再インストールや再キャッシュなどを行っていると思います。問題は、実際にインストールするときに、インストール先のパスを選択すると、レジストリキーとして設定されることです。このmsiexec.exe/vが呼び出されると、すべてのレジストリキーがリセットされますが、このパスがなくなったため、パスキーは空白のままになります。
プロセスモニターを実行し、それが発生するのを待ちました。上記の情報は私が推測したものです。なぜそれを呼んでいるのか、そしてそれを止める方法を知る必要があります。私はこれを解決するために積極的に取り組んでいるので、何が起こっているのかを理解するのに役立つ情報や知識をいただければ幸いです。これらのイベントを開始するものは特にありません。おそらくスタートアップです。
何が起こっているのかを知るのは非常に難しい。MSIの一部として独自のサービス実行可能ファイルをインストールしていますか？その場合、呼び出されたときに「自己修復」エントリポイントになります（開始/停止）。これは、すべてのコンポーネントのすべてのキーパスがオンザフライで検証され、キーパスが欠落していることが判明した場合、アプリケーションの再インストールが自動的に実行されることを意味します。詳細ログファイルを使用して、どのコンポーネントが自己修復をトリガーしたかを判断できます。Windowsインストーラコマンドラインビルダーを使用して、ファイルを作成するためのmsiexec.exeコマンドラインを作成します。ここで私の答えを参照してください：サイレントインストールのmsiをインタラクティブにする方法は？（データを進行させてキャンセルします）
通常、システムのイベントログを確認することで、自己修復を担当するコンポーネントを見つけることもできます。これが最速のアプローチです。ログファイルはあなたにもっと多くの情報を与えるでしょう。ログを理解するには、Microsoft独自のログファイルアナライザーを使用します：http：//msdn.microsoft.com/en-us/library/windows/desktop/aa372811 （v = vs.85）.aspx
msiでレジストリキーをハードコーディングしている場合、修復が完了すると、レジストリキーは実際にリセットされる傾向があります。MSIコンポーネントをキーパスとしてレジストリパスに向けると、MSIファイルはそのキーを「所有」していると見なし、これを回避するようにMSIファイルを特別に設計しない限り、インストール時にリセットし、アンインストール時に削除します。これを回避するには、コンポーネントを「永続的」および「キーパスが存在する場合は上書きしない」として設定します。より適切なオプションは、サービスexeファイルに、インストール後に独自のデフォルトをレジストリに書き込む権限がある場合に書き込むことです。これにより、設定がMSIから切り離され、インストーラーが設定を混乱させることはありません。
私の直感が正しければ、サービスexeファイルはMSIが「所有している」と見なすレジストリ値をリセットし、サービスを開始するとキーパスチェックがトリガーされ、自己修復がトリガーされて値がMSIのデフォルトに戻ります。面倒な説明で申し訳ありませんが、私はここでデバッグのためのいくつかのポインタを提供しようとして腰から撮影しています。