Windows 7 .NET 3.5.1 - 2.0 が少し破損しています。修復方法は?

Question

Windows 7 に含まれる .NET インストール (3.5 ～ 2.0) がわずかに破損しているように見えるため、Windows を再インストールしたり、バックアップに戻したりせずに修復しようとしています。

すべて正常に動作していたのですが、ハードドライブがいくつかのファイルを破損し始め、チェックディスクで不良クラスタが見つかったため、ドライブを新しいものにイメージしました。新しいドライブで起動するとすぐにすべてが動作しました。を除外する.NET 3.5 から 2.0 内で System.Net.NetworkInformation メソッド (Ping() や IsNetworkAvailable() など) を呼び出すプログラム。これらのメソッドは、呼び出し元のアプリを即座にクラッシュさせます (.NET 4.0 ではこれらの呼び出しは正常に動作します)。これらのメソッドは System.dll 内にあり、winnsi.dll または iphlpapi.dll 内 (まだ見つけていません) にあるネイティブ メソッドを呼び出しているものと思われます。クラッシュの原因となる例外は、ネイティブ メソッドの呼び出しとそれらの間のデータのマーシャリングに関連するとされる Fatal Execution Engine Error であるため、ネイティブ メソッドを呼び出しているものと思われます。

犯人に関する大きな手がかりは、クラッシュするまったく同じアプリケーションをコード プロファイラー (exe を実行し、どのメソッドが最も時間がかかったかの統計をキャプチャする) で起動すると、アプリケーションは正常に動作し、クラッシュはまったく発生しないという事実にあると思われます。プロファイラー内で実行すると動作するのに、プロファイラー外で実行すると動作しないのはなぜでしょうか。これが謎を解く鍵のようです。

• procmon を使用して、クラッシュした実行とプロファイラー実行の成功した実行からのすべてのレジストリ、ファイルシステム、およびネットワーク イベントをキャッチし、2 つの出力を比較しましたが、あまり学習できませんでした (プロファイルされていないアプリがクラッシュする瞬間はわかりますが、それまでは同じように動作し、同じモジュールがロードされます)。唯一の大きな違いは、アプリがクラッシュする直前に、プロファイラーによって実行されたコードが 4 ～ 6 個の新しいスレッドを作成し、直接実行されたコードが 1 ～ 2 個しか作成しないことです。
• 最も関連があると思われるファイル/ディレクトリ (Windows および Program Files の下の .NET のもの) をディスクの問題の前後で比較しましたが、予想外の変化は見られませんでした (明らかなファイル破損はありません)。
• ディスクトラブルの前後でソフトウェアとシステム レジストリ ハイブを比較しましたが、関連性のある変更は見られませんでした。
• 新しいユーザー アカウントを作成し、環境が関連している可能性がある場合は環境変数をクリーンアップしました。変化はありません。
• 「sfc /scannow」を実行しましたが、整合性の問題は見つかりませんでした。
• 破損している可能性のあるものを見逃した場合に備えて、「ngen update」を実行してプリコンパイルされたコードを再生成してみましたが、何も変わりませんでした。

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

ここでゼロから始めて、新しい Windows をインストールし、数十のソフトウェア パッケージを再インストールし、開発関連のカスタマイズなどを数十回思い出そうとするのは絶対にしたくありません。

これらすべてを考慮すると、誰か役に立つアドバイスはありますか? 私は開発者なので、.NET 3.5 - 2.0 が動作している必要があり、それを使用してビルドおよびテストする必要があります。

ありがとう！

クインシー

Answer 1

簡単に答えると、System.ni.dll ファイルが破損していたので、それを交換したらすべて正常になりました。

ドライブ障害によって破損したファイルをリストアップし続けた chkdsk ログを再確認する必要があることを思い出しました。障害発生後、リストアップされたファイル ID をすべてファイル パス/名前に変換し、バックアップから 100 個以上のファイルをすべて置き換えましたが、今戻って確認してみると、4 個または 5 個の .NET 関連ファイルを正常に置き換えた一方で、その時点で「使用中」であったために置き換えることができなかったファイルが 1 つあるというメモが見つかりました。そのファイルとは、System.ni.dll です。このファイルをバックアップから置き換えることができたので、.NET インストールは正常に戻り、プロファイルの有無にかかわらずアプリが動作します。

残念なことに、このインシデントが最初に発生したとき、私は問題が破損したファイル、特に失敗したメソッドが格納されている System.dll というファイルに関係するものだと完全に予想していました。そのため、System.dll という名前のすべてのファイルを比較および再比較しました。しかし、その時点では、System.ni.dll が System.dll (またはそれに類するもの) のネイティブ コンパイルされた表現であることに気付きませんでした。また、.NET 関連のディレクトリを比較および再比較していたため、これに気付かなかったため (なぜ気付かなかったのかわかりません)、そのアプローチをあきらめていました。

とにかく... 長い話を短くすると、私の問題の原因は破損した System.ni.dll であり、その中の 1 つ以上のクラスターの内容が 0x0 に置き換えられ、それがたまたま私が観察した奇妙な問題として現れたのです。