5

コードプロファイラー（この場合はドローンプロファイラー）が.NETアプリを直接実行するのとは異なる方法で実行する方法を理解しようとしています。これを知る必要がある理由は、開発用コンピューターの.NETインストールに非常に奇妙な問題/破損があり、プロファイラーの外部に現れるが、非常に奇妙なことに内部には現れないためです。コンピューターの問題を修正できる理由を理解できれば。

この問題は、System.Net.NetworkInformationのメソッドの呼び出しにのみ影響するようです（4に対して何かを構築した場合は、.NET 3.5から2.0内でのみ問題ありません）。System.Net.NetworkInformation.IsNetworkAvailable（）を呼び出す、1つのことだけを行う小さなテストアプリを作成しました。プロファイラーの外で、System.dllで「致命的な実行エンジンエラー」が発生しました。これがすべての情報です。私が理解していることから、エラーは通常、ネイティブメソッド呼び出しに起因します。これは、おそらくSystem.dllによって一部のネイティブDLLにIsNetworkAvailable（）ロジックを実行させたときに発生します。

  • プロセスモニターを使用してプロファイラーの内部と外部の違いを把握し、両方の状況からのイベントを記録して比較しようとしました。iphlpapi.dllとwinnsi.dllが呼び出された直後、およびdnsapi.dllと呼ばれるプロファイラー実行コードと非プロファイラーコードがクラッシュレポート関連のものの読み込みを開始する直前まで、両方のログは同じでした。プロファイラー実行コードが4〜6個の新しいスレッドを作成し、非プロファイラー（クラッシュ）コードが1個または2個しか作成しなかったその瞬間、それが何を意味するのかわかりません。

おそらく不必要な背景

Windows 7に含まれる.NETインストール（3.5から2.0）は、ハードドライブが破損し、チェックディスクが不良クラスターを検出し始めるまで、正常に機能していました。ドライブを新しいものにイメージしましたが、.NETのこの1つの問題を除いて、すべて正常に動作します。

この問題を解決するには、Windowsを再インストールするか、イメージバックアップに戻す必要があります。

これが私が調べたもののいくつかです：

  • ディスクの前後の問題に最も関連があると思われるファイル/ディレクトリ（Windowsおよびプログラムファイルの.NETのもの）を比較しましたが、予期しない変更は見られませんでした（明らかなファイルの破損はありません）。
  • ソフトウェアとシステムレジストリのハイブのディスク前後の問題を比較しましたが、関連性があると思われる変更は見られませんでした。
  • 新しいユーザーアカウントを作成し、環境が関連している場合に備えて環境変数をクリーンアップしました。変化なし。
  • 「sfc/scannow」を実行しましたが、整合性の問題は見つかりませんでした。
  • 「ngenupdate」を試して、破損している可能性のあるものを見逃して何も変更されていない場合に備えて、コンパイル済みのコードを再生成しました。
  • ウイルススキャナーを取り外して、干渉しているかどうかを確認しました。違いはありません。
  • セーフモードでテストコードを実行してみましたが、同じクラッシュの問題です。

.NETインストールを修復する必要があると思いますが、Windows7には.NET3.5-2.0が含まれているため、.NETインストーラーを再実行してやり直すことはできません。Windowsを自分自身に再インストールするためのWindowsディスクにアクセスできません（コンピューターにはリカバリパーティションがありますが、使用できません）。また、ドライブはディスク全体の暗号化ソリューションを使用しており、再インストールは困難です。

ここで最初からやり直して新しいWindowsをインストールし、数十のソフトウェアパッケージを再インストールし、開発関連の数十のカスタマイズなどを覚えておくのは絶対に嫌です。

それをすべて考えると...誰かが何か役立つアドバイスがありますか？私は開発者であり、それに対してビルドしてテストする必要があるため、.NET3.5-2.0が機能する必要があります。

ありがとう！

Quinxy

4

2 に答える 2

1

簡単な答えは、私のSystem.ni.dllファイルが破損していて、それを置き換えて、すべてが順調であるということです。

長い答えは、解決策へのアプローチによって他の誰かを助けるかもしれません...

私の問題は、プロファイラーを介さない限りアプリが実行されないような方法で.Netが破損していることに関連していました。SlimTuneオープンソースプロファイラーのソースをダウンロードし、ローカルでビルドして、Process.Start（）を呼び出す直前にブレークポイントを設定しました。次に、プロファイラーを使用してアプリを正常に起動する場合と手動で起動する場合のすべてのパラメーターを比較しました。私が見つけた唯一の意味のある違いは、環境変数に追加された.NETプロファイルパラメーターの追加でした。

  • cor_enable_profiling = 1
  • cor_profiler = {38A7EA35-B221-425a-AD07-D058C581611D}

次に、これらを自分のユーザーの環境に設定してみました。これで、手動で実行したどのアプリでも機能します。（実際には数時間前に同じことを試しましたが、例に含まれているGUIDを使用しましたが、実際のプロファイラーを指していませんでした。.NETは、偽のGUIDを指定したことを認識しており、指定しなかったようです。プロファイリングモードで実行します。）

私は今戻って、プロファイリングを有効にしてアプリを実行することが重要である理由を理解することを期待して、CLRによってPEファイルがどのように実行されるかについて読み始めました。私はたくさんのことを学びましたが、当てはまると思われることは何もありませんでした。

ただし、ドライブの障害によって損傷したファイルをリストし続けたchkdskログを再確認する必要があることを思い出しました。失敗した後、リストされたすべてのファイルIDをファイルパス/名前に変換し、バックアップから可能な100以上のファイルをすべて置き換えましたが、今戻って見てみると、4または5 .NET関連のファイルは、「使用中」であるために置き換えることができなかったそのようなファイルが1つありました。そのファイル？System.ni.dll !!! これで、バックアップからこのファイルを置き換えることができ、.NETインストールが通常に戻り、プロファイルされているかどうかに関係なくアプリが機能します。

イライラするのは、このインシデントが最初に発生したとき、問題が破損したファイル、特に失敗したメソッドを格納するSystem.dllというファイルに関連することを完全に予想していたことです。そのため、System.dllという名前のすべてのファイルをdiffおよびrediffしました。しかし、当時、System.ni.dllがSystem.dll（またはそのようなもの）のネイティブにコンパイルされたマニフェストであることに気づいていませんでした。そして、私は.NET関連のディレクトリを差分して再差分し、これに気づかなかったので（どうやってそれを見逃したのかわかりません）、そのアプローチをあきらめました。

とにかく...簡単に言えば、私の問題を引き起こしたのは破損したSystem.ni.dllであり、その中の1つ以上のクラスターのコンテンツが0x0に置き換えられ、私が観察した奇妙な問題として現れました。

于 2012-08-25T02:37:12.457 に答える
0

これはタイミングの問題のように聞こえますが、プロファイラーはそれを少し遅くすることで「修正」しました。

多くのプロファイラーはインストルメンテーションを使用します（詳細はこちら）。これにより、アプリケーションの速度がわずかに低下します。どうやらそれは別のスレッドがもう少し多くの仕事をすることができるのに十分に1つのスレッドを遅くして、そのクラッシュを防ぎます。このようなエラーは、多くの場合、開発者のマシンに直接現れることはありませんが、より多くのコアまたはハイパースレッディングを備えたプロセッサで実行されるとすぐに現れます。リリースビルドでのみ発生する場合もあります（またはデバッグビルドではその逆）。同じコードが異なる条件（プロファイラーまたはデバッガー）で異なる結果をもたらす可能性があるため、タイミングの問題を追跡するのは難しい場合があります。

あなたの説明から、私はそれがどのように修正されるかについて大げさな推測をしようとします：

新しいスレッドが開始されたソースを見つけてください。次に、それらが生成された後、System.Threading.Thread.Sleep(500);そこに行を追加してメインスレッドを一時停止し、新しいスレッドを開始する時間を与えます。

ソースコードとクラッシュのいくつかのスタックトレースがなければ、これはかなりの推測です。

于 2012-08-23T22:22:04.197 に答える