Моя установка Windows 7, включающая .NET (с 3.5 по 2.0), выглядит очень слегка и особенно поврежденной, и я пытаюсь исправить это, не переустанавливая Windows и не пытаясь вернуться к резервным копиям.
Все работало, а потом мой жесткий диск начал портить несколько файлов, и checkdisk обнаружил плохие кластеры, поэтому я создал образ диска на новом. Как только я загрузился на новом диске, все заработалокромепрограммы, которые вызывают методы System.Net.NetworkInformation в .NET 3.5 до 2.0 (например, Ping() и IsNetworkAvailable()), которые немедленно приводят к сбою приложения, в котором происходят вызовы (эти вызовы в .NET 4.0 работают нормально). Эти методы находятся внутри System.dll, и я предполагаю, что они вызывают собственные методы, которые, как я полагаю, находятся внутри winnsi.dll или iphlpapi.dll или чего-то еще (я пока не нашел этого); я предполагаю, что он вызывает собственные методы, потому что исключение, вызывающее сбой, — это Fatal Execution Engine Error, о котором люди говорят, что оно обычно связано с вызовом собственных методов и маршалированием данных между ними.
Огромная подсказка о виновнике, вероятно, находится в том факте, что когда я запускаю то же самое аварийное приложение через профилировщик кода (который запускает exe и собирает статистику о том, какие методы заняли больше всего времени), приложение работает нормально, без сбоев! Как запуск его в профилировщике может работать, а запуск извне — нет? Кажется, это ключ к тайне.
- Я использовал procmon для перехвата всех событий реестра, файловой системы и сети из аварийного выполнения и успешного выполнения с помощью профилировщика и сравнил два вывода, но не узнал многого (я вижу момент, в который непрофилированное приложение аварийно завершает работу, но до этого момента они ведут себя одинаково, загружают одни и те же модули, ). Единственное большое различие, похоже, заключается в том, что в момент перед аварийным завершением приложения код, выполняемый профилировщиком, создает 4-6 новых потоков, а напрямую выполняемый код создает только 1-2.
- Я сравнил файлы/каталоги, которые показались мне наиболее важными (содержимое .NET в Windows и Program Files) до и после возникновения проблем с диском и не увидел никаких изменений там, где я их не ожидал (никаких явных повреждений файлов).
- Я сравнил разделы реестра программного обеспечения и системы до и после возникновения проблем с диском и не увидел никаких существенных изменений.
- Я создал новую учетную запись пользователя и очистил все переменные среды на случай, если среда была связана. Никаких изменений.
- Я выполнил «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, я продолжал перечислять файлы, которые были повреждены сбоем диска. После сбоя я превратил все перечисленные идентификаторы файлов в пути/имена файлов и заменил все 100+ файлов, которые мог, из резервной копии, но, конечно же, когда я вернулся и посмотрел, я нашел заметку о том, что хотя я успешно заменил 4 или 5 файлов, связанных с .NET, был один такой файл, который я не смог заменить, потому что он был «использован» в то время. Этот файл? System.ni.dll!!! Теперь я смог заменить этот файл из резервной копии, и вуаля, моя установка .NET вернулась в нормальное состояние, приложения работают независимо от того, профилированы они или нет.
Раздражает то, что когда этот инцидент впервые произошел, я полностью ожидал, что проблема будет связана с поврежденным файлом, а именно с файлом System.dll, в котором хранились методы, которые дали сбой. Поэтому я сравнил и переделал все файлы с именем System.dll. Но в то время я не осознавал, что System.ni.dll был нативным скомпилированным проявлением System.dll (или чем-то в этом роде). И поскольку я сравнил и переделал каталоги, связанные с .NET, и не заметил этого (не представляю, как я это пропустил), я отказался от этого подхода.
В любом случае... короче говоря, именно поврежденный System.ni.dll стал причиной моих проблем, содержимое одного или нескольких кластеров в нем было заменено на 0x0, и так уж получилось, что это проявилось в виде странной проблемы, которую я наблюдал.