我的 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 或其他東西中的本機方法（我還沒有找到）；我假設它呼叫本機方法，因為導致崩潰的異常是致命執行引擎錯誤，人們提到的通常與呼叫本機方法和在它們之間編組資料有關。
關於罪魁禍首的一個巨大線索可能是這樣一個事實：當我透過程式碼分析器（它執行exe 並捕獲耗時最長的方法的統計數據）啟動完全相同的崩潰應用程式時，應用程式運作良好，根本沒有崩潰！怎麼可能在探查器內運行它有效而在外部運行它不起作用？這似乎是解開謎團的關鍵。
- 我已經使用procmon 來捕獲崩潰執行和探查器運行成功執行中的所有註冊表、檔案系統和網路事件，並比較了兩個輸出，但沒有學到太多東西（我看到了非分析應用程式的時刻）崩潰，但直到那時它們的行為都是相同的，加載相同的模組，）。唯一大的區別似乎是，在應用程式崩潰之前，探查器執行的程式碼創建了 4-6 個新線程，而直接執行的程式碼僅創建 1-2 個。
- 我已經比較了看起來最相關的檔案/目錄（Windows 和程式檔案下的 .NET 內容）磁碟前和磁碟後故障，並且沒有看到任何我沒有預料到的變更（沒有明顯的檔案損壞）。
- 我對磁碟故障前後的軟體和系統註冊表配置單元進行了比較，沒有發現任何相關的變化。
- 我創建了一個新的用戶帳戶並清理了所有環境變量，以防環境相關。不用找了。
- 我執行了“sfc /scannow”，沒有發現完整性問題。
- 我嘗試“ngen update”來重新生成預先編譯的程式碼，以防我錯過了可能損壞的東西並且沒有任何改變。
我假設我需要修復我的 .NET 安裝，但由於 Windows 7 包含 .NET 3.5 - 2.0，因此您不能只重新執行 .NET 安裝程式來重做它。我無法存取 Windows 磁碟來嘗試重新安裝 Windows（電腦有恢復分割區，但無法使用）；此外，該驅動器使用全碟加密解決方案，重新安裝會很困難。
我絕對不想在這裡從頭開始安裝一個全新的 Windows，重新安裝數十個軟體包，嘗試並記住數十個與開發相關的自訂/等等。
鑑於這一切...有人有任何有用的建議嗎？我需要 .NET 3.5 - 2.0 工作，因為我是一名開發人員，需要對其進行建置和測試。
謝謝！
昆西
答案1
簡而言之，我的 System.ni.dll 檔案已損壞，我替換了它，一切正常。
我記得我應該重新檢查 chkdsk 日誌，我一直列出因驅動器故障而損壞的檔案。失敗後，我已將所有列出的文件ID 轉換為文件路徑/名稱，並替換了所有100 多個可以從備份中找到的文件，但是當我現在回去查看時，我發現了一條註釋，雖然我替換了4 個或5 .NET 相關文件成功，有一個這樣的文件我無法替換，因為它當時「正在使用」。那個文件？系統.ni.dll！ ！我現在可以從備份中替換此文件，瞧我的 .NET 安裝恢復正常，無論是否配置文件，應用程式都可以正常工作。
令人沮喪的是，當這個事件第一次發生時，我完全預期問題與損壞的檔案有關，特別是與包含失敗方法的名為 System.dll 的檔案有關。因此，我對所有名為 System.dll 的檔案進行了比較和重新比較。但當時我沒有意識到 System.ni.dll 是 System.dll（或類似的東西）的本機編譯表現。因為我已經對 .NET 相關目錄進行了比較和重新比較，但沒有註意到這一點（不知道我是如何錯過的），所以我放棄了這種方法。
不管怎樣......長話短說，這是一個損壞的System.ni.dll導致了我的問題，其中一個或多個簇的內容被0x0替換，它恰好表現為我觀察到的奇怪問題。