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을 사용하여 충돌 실행 및 프로파일러 실행 성공 실행에서 모든 레지스트리, 파일 시스템 및 네트워크 이벤트를 포착하고 두 출력을 비교했지만 많은 것을 배우지 못했습니다(프로파일링되지 않은 앱이 실행되는 순간을 봅니다). 충돌이 발생하지만 그때까지는 동일하게 작동하고 동일한 모듈을 로드했습니다.) 유일한 큰 차이점은 앱이 충돌하기 전 프로파일러 실행 코드가 4~6개의 새 스레드를 생성하고 직접 실행된 코드는 1~2개만 생성한다는 것입니다.
- 가장 관련성이 높은 것으로 보이는 파일/디렉터리(Windows 및 프로그램 파일 아래의 .NET 항목)를 디스크 전후 문제로 비교했는데 예상하지 못한 부분(명백한 파일 손상 없음)에는 변경 사항이 없었습니다.
- 디스크 문제 전후의 소프트웨어 및 시스템 레지스트리 하이브를 비교해 보았지만 관련성이 있어 보이는 변경 사항은 없었습니다.
- 환경이 관련된 경우 새 사용자 계정을 만들고 모든 환경 변수를 정리했습니다. 변경 없음.
- "sfc /scannow"를 실행했는데 무결성 문제가 발견되지 않았습니다.
- 손상될 수 있는 부분을 놓쳤고 변경된 사항이 없는 경우를 대비하여 미리 컴파일된 코드를 재생성하기 위해 "ngen 업데이트"를 시도했습니다.
.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 관련 파일이 성공했습니다. 당시 "사용 중"이었기 때문에 교체할 수 없는 파일이 하나 있었습니다. 그 파일? System.ni.dll!!! 이제 백업에서 이 파일을 교체할 수 있었고 .NET 설치가 정상으로 돌아왔습니다. 앱은 프로파일링 여부에 관계없이 작동합니다.
실망스러운 점은 이 사건이 처음 발생했을 때 문제가 손상된 파일, 특히 실패한 메서드가 포함된 System.dll이라는 파일과 관련이 있을 것이라고 완전히 예상했다는 것입니다. 그래서 저는 System.dll이라는 이름의 모든 파일을 비교하고 다시 비교했습니다. 그러나 그 당시에는 System.ni.dll이 System.dll(또는 그와 유사한 것)의 기본 컴파일 표현이라는 사실을 깨닫지 못했습니다. 그리고 .NET 관련 디렉토리를 비교하고 다시 비교했지만 이를 알아차리지 못했기 때문에(어떻게 놓쳤는지는 모르겠습니다) 그 접근 방식을 포기했습니다.
어쨌든... 간단히 말해서, 문제를 일으킨 것은 손상된 System.ni.dll이었습니다. 그 안에 있는 하나 이상의 클러스터의 내용이 0x0으로 바뀌었고 제가 관찰한 이상한 문제가 나타났습니다.