問題タブ [procmon]

Windows サービス (いくつかの C# コードを含む c++) があります。本番環境では、サービスが動作するマシンとそうでないマシンがあり、このエラー 1053 ですぐに停止します。

両方の procmon を比較したところ、「スレッド終了」操作を取得する前に、「イメージのロード」を試行し、サクカス マシンが起動し続けることがわかりました...

ここからどのように作業するか考えていますか？

この問題は、ドメイン内の複数のマシンで発生することがあります。ユーザーが .NET 4.0 アプリケーションを起動しましたが、何も起こりません。Windows XP を実行するマシン、.NET バージョンは 4.0.30319.1008

タスク マネージャーで確認できるように、プロセスは開始されますが、40 KB のメモリしか使用しません (たとえば 404 KB の場合もありますが、通常の実行中のプロセスではさらに多くのメモリが必要です)。このプロセスを強制終了しようとすると、システムは正常に終了したと表示しますが、プロセスはメモリに残り、.exe ファイルはロックされます。プロセスを強制終了し、ファイルのロックを解除するには、マシンを再起動するだけです。

分析にProcMonを使用しようとしましたが、イベントがほとんど表示されず、イメージをロードする前にプロセスが停止しました (イメージのロード操作は行われません)。したがって、原因は私のアプリケーション内ではありません。

回避策として、私はいくつかのことを試しました：

1. アプリケーションを再構築し、その場所にある .exe を置き換えます - 役に立ちます! ただし、2 つの EXE ファイルの違いは、変更された MVID GUID と、.exe に含まれるその他のコンパイル情報だけです。

2. したがって、クラッシュしたアセンブリのネイティブ イメージがどこかにキャッシュされているので、.exe を置き換えると、システムが再構築を開始するのではないかと考えました。私はこれに強いわけではありませんが、「ngen update」命令を試してみました - 役立つ場合もあれば、そうでない場合もあります。

しばらくすると、一部のマシンで問題が繰り返されます。

問題の原因を特定するにはどうすればよいですか?

私の理解では、process_monitor はクラッシュビン情報をローカルに保存します。これが仮想マシンで実行されていて、テスト ケースによってプロセスとターゲット マシンが応答しなくなると、vmcontrol は以前のスナップショットに戻ります。クラッシュビン情報は Web インターフェイスにどのように表示されますか、または以前のスナップショットに戻すときに失われた場合、この時点でアクセスされますか?

I am using procmon command line.

After running the above command, the procmon UI shows filtered events but the saved file - output.csv contains all the events.

Is there an option to save the filtered output via cmd? If not, is there a way to copy the output to cmd?

アプリケーションのビルド (複数の異なるプロセスを使用) の procmon トレースがありますが、別のプロセスで使用されているため、ある時点でファイルの書き込みに失敗します。最初に目にするのは、ビルドの開始時にファイルが削除されることです。

それは成功しているようです。次に気付くのは、「リーダーのみでロックされたファイル」を返す 2 つの「CreateFileMapping」呼び出しがあることです。ただし、どちらの場合も closefile が呼び出されているように見えるため、心配する必要はありません。興味深いことに、削除後に呼び出された QueryAllInformationFile は、作成時間の削除前の時間を返します。ファイルが適切に削除されていないということですか？

最後に共有違反を以下に示します。興味深いのは、同じプロセスが、読み取り/書き込みの前にファイルを閉じずに、読み取り用にファイルを開くことです。理論的にはそれができるはずですが、そうですか？

ファイルを開いた後に閉じていない場所はどこにもありません。最初にファイルを削除する必要があります。ビルドを開始する前に、ファイルへのハンドルがないことを確認しました（「ハンドルを使用して" 道具）。

あなたが提供できる指針は役に立ちます、ありがとう。

C++Builder 10.0 Seattle でビルドされた VCL アプリケーションがあります。フォーム上で Axis Media Control を使用してビデオを表示するため、AxisMediaControl.dll実行時にファイルがロードされます。

過去に、これを 32 ビットのターゲット マシンにデプロイしたことがあり、アプリケーションはC:\Program Files\AppNameディレクトリにあり、AxisMediaControl.dll同じ場所にインストールされていました。すべてが期待どおりに機能しました。

このアプリケーションは 32 ビット アプリケーションであるため、64 ビットのターゲット マシンにデプロイする場合は、C:\Program File (x86)\AppNameディレクトリにインストールされます。もう一度、AxisMediaControl.dllファイルがアプリケーション ディレクトリにデプロイされます。

アプリが「指定されたモジュールが見つかりませんでした」というエラーで起動に失敗します。Process Monitor を使用すると、プログラムがdirProgram Filesではなく古いディレクトリで Axis DLL を探していることがわかりました。x86アプリケーションがその場所で DLL を検索する原因は何ですか?

開発マシンで同じバイナリを実行すると、アプリケーションはSysWOW64ディレクトリから DLL をロードします。DLL がターゲット マシンのそこに配置されている場合でも、その場所を検索できません。私が理解できない古いアプリケーションパスのみを調べています。Program Files

誰かが光を当てることができることを願っています。