Ошибки Net Framework

Метки:  , , , , , , , , , , , , ,

Данная статья создавалась как попытка продолжить изучение не достаточно хорошо знакомой для меня темы восстановления работоспособности .Net Framework в системах Windows, а так же поиска проблем ошибок в Net Framework приложениях.

.NET Framework - программная платформа, основой которой является общеязыковая среда исполнения (Common Language Runtime, CLR) байт-кода "промежуточного языка высокоуровневого ассемблера". Из определения "общеязыковая" следует, что она предназначается для выполнения кода модулей, написанных на множестве языков программирования. Получила дальнейшее развитие в виде .NET Core, изначально ориентированную на кроссплатформенную разработку.

Основная концепция создания .Net Framework заключалась в обеспечении максимально-возможной свободы разработки, обусловленной возможностью создавать приложения с использованием различных языков программирования, способных исполняться на широком спектре устройств, работающих на разных операционных системах [мультиязычность и кроссплатформенность]. Программа для платформы .NET Framework, в начале исполнения переводится компилятором в единый для .NET промежуточный байт-код "высокоуровневого ассемблера" виртуальной машины .NET (Common Intermediate Language, CIL, ранее Microsoft Intermediate Language, MSIL), называемый в контексте .NET сборкой (assembly). Далее получившийся код либо исполняется виртуальной машиной Common Language Runtime (общеязыковая среда выполнения, CLR), либо транслируется утилитой NGen.exe в исполняемый код для определенного целевого процессора. И на финальном этапе, встроенный в виртуальную машину CLR компилятор "на лету" (в режиме реального времени) преобразует промежуточный байт-код в машинные коды целевого процессора [для непосредственного исполнения кода процессором].

В некотором смысле .Net Framework это система в системе. Она обеспечивает множество собственных механизмов: управление виртуальной памятью, система безопасности, загрузчик модулей, механизм исключений (обработки ошибок),модель многопоточности, изолированная среда выполнения приложений и многое другое. Тем самым .Net Framework как бы создает еще один уровень абстракции.

больше деталей по поиску причин ошибок .Net Framework

Восстановление хранилища компонентов при помощи DISM

Метки:  ,
DISM (Deployment Image Servicing and Management, Обслуживание и управление образами развертывания) — многофункциональный сервисный инструмент [командной строки], предназначающийся для обслуживания образов Windows®, [подготовки] образов среды предустановки Windows (Windows PE), а так же включающий функции автономного обслуживания текущей инсталляции. Пришел на смену своему предшественнику Pkgmgr.exe.

В данном материале речь пойдет о применении средства DISM исключительно для восстановления хранилища компонентов, поскольку данная утилита является основным (рекомендованным Microsoft) автоматизированным механизмом восстановления целостности компонентной модели Windows.

Это сервисная статья, кто вышел на неё напрямую, просьба, для начала, ознакомиться с главным хабом по восстановлению.

Материал данной статьи описывает процесс восстановления хранилища компонентов при помощи dism.

Узнать подробности о восстановлении хранилища компонентов при помощи DISM

Восстановление хранилища компонентов при помощи SFCFix

Метки:  ,

В стремлении исправить проблемы, возникающие то и дело в компонентной модели Windows, сообщество технических специалистов иногда выдает собственные (самописные) решения по восстановлению хранилища компонентов. Сегодня мы поговорим об одном из таких средств под названием SFCFix, то есть рассмотрим очередной неофициальный способ восстановления хранилища компонентов при помощи SFCFix. По собственному ощущению, утилита SFCFix чем то напоминает средство SURT, однако приближено к клиент-серверной модели реализаций dism, характерных для последних версий операционных систем (Windows 10+). Есть и своя специфика: утилита SFCFix проверяет лог-файл %Windir%\Logs\CBS\CBS.log, находит все записи о поврежденных/отсутствующих файлах, которые до неё были сделаны разнообразными сервисными утилитами проверки (sfc) и которые не были восстановлены/исправлены, и затем, на основании базы хешей файлов и некоторых других алгоритмов находит необходимые для восстановления/замены файлы, пытаясь произвести их восстановление.

Более информации о восстановлении хранилища компонентов при помощи SFCFix

Пролог и эпилог функции

Метки:  , ,

Одной из основ исследования структуры исполняемых образов программ (реверсивная инженерия), является изучение пролога и эпилога функции. Обычно об этих понятиях мало кто задумывается, до той самой поры, пока не начинают изучать строение исходного кода на уровне машинных (процессорных) команд, иными словами - в дизассемблированном виде. Очевидно, что знакомый с одноименными терминами мира искусства, дальновидный читатель сразу же догадается что пролог это ни что иное как своеобразное "предисловие", некая вводная часть, вступление, а эпилог - это нечто завершающее, "послесловие", заключительная часть. Проводя аналогию, логично было бы предположить, что механизмы эти призваны выполнять некие предваряющие и завершающие действия по отношению к какой-либо сущности, а именно к функциям. И все же не совсем понятно, как именно термины пролога и эпилога относятся к функциям/процедурам из мира вычислительной техники? Довольно нетривиальной задачей является попытка интуитивного сопоставления терминов из мира искусства с областью программирования. К тому же, у данной области имеется множество особенностей, которые мы сегодня и попытаемся понять.

Продолжить изучать пролог и эпилог

STOP 0x0000006B

Метки:  , , , ,

Статья дополняет серию материалов, освещающих методы устранения проблем, приводящих к возникновению критической системной ошибки (BSOD). В материалах раздела рассматриваются ситуации, с которыми я сталкивался лично (в своей практике) и с которыми мне удалось разобраться. STOP-ошибка (STOP error), контроль дефекта (BugCheck) или в простонародье BSOD - фатальный системный сбой операционной системы Windows, являющийся причиной полного прекращения функционирования основных компонентов ядра операционной системы, влекущий за собой потерю динамических не сохраненных пользовательских данных и приводящий к появлению на экране монитора синего экрана смерти (BSOD). Числовое обозначение STOP-ошибки - идентификатор, характеризующий "природу" фатальной системной ошибки, используется при диагностике причины возникшей неполадки. В данной статье речь пойдет о сбое с идентификатором STOP 0000006B.

Подробнее о сбое STOP 0x0000006B

Восстановление хранилища компонентов при помощи средства проверки готовности системы к обновлению (SURT)

Метки:  , , , , , ,

Сегодня вашему вниманию предоставляется еще одно пополнение цикла статей о методах восстановления хранилища компонентов Windows. Помимо изобретения широкой общественностью бесчисленного множества "наколеночных" методик восстановления работоспособности компонентной модели, сами разработчики из Microsoft предлагают вполне официальные методы. В данной публикации мы рассмотрим один из подобных методов, который заключается в восстановлении хранилища компонентов при помощи средства проверки готовности системы к обновлению или, иными словами восстановлении хранилища компонентов при помощи SURT. Фактически описываемым методом предусматривается проверка каталогов/файлов компонентной модели при помощи специализированного пакета и попытка устранения найденных ошибок.

Метод подходит только для операционной системы Windows 7. Для более новых ОС (Windows 8+) средство SURT не требуется, поскольку весь функционал интегрирован в систему и доступен через API стека обслуживания, из скриптов Powershell и сервисной утилиты dism.exe. Это подтверждают высказывания некоторых сотрудников Microsoft: Instead of needing to download and run a separate tool, the diagnostic and repair functionality in the System Update Readiness Tool is now built into Windows in Windows 8 and Windows Server 2012.

больше о восстановлении хранилища компонентов при помощи средства SURT

Восстановление компонента прямой заменой файлов

Метки:  , , ,

В данной статье описан метод ручного восстановления хранилища компонентов Windows. Подобные описанному в данном посте методу восстановления работоспособности компонентной модели рождаются вовсе не от хорошей жизни, появляются они под воздействием многочисленных проблем с компонентной моделью операционной системы. Во многих случаях официальные подходы к восстановлению хранилища компонентов не помогают, помимо этого отсутствует какая бы то ни было внятная официальная документация, из чего складывается недопонимание структуры и принципов работы компонентной модели. При подобном отношении со стороны разработчиков абсолютно любые средства вернуть компонентную модель в работоспособное состояние приемлемы!! Как показывает практика, при всех стараниях разработчиков из Microsoft предоставить возможность конечному пользователю системы устранять возникающие проблемы в автоматическом режиме (при помощи специальных утилит), никогда полностью не будут исключены ситуации, в которых эти самые автоматизированные средства будут давать сбои. Причина тут кроется в симбиозе старых механизмов операционной системы и необходимостью постоянного внедрения новых (не оттестированных) технологий, должным образом не заботясь о приведении в надлежащее состояние всех связанных (участвующих) компонентов, что, в свою очередь, порождает огромное количество проблем.
В данной публикации речь пойдет о восстановлении компонента прямой заменой файлов. Фактически методом предусматривается прямая ручная замена поврежденных [кривых, неправильно функционирующих] файлов, являющихся причиной возникновения ошибок, а так же частей реестра. По этой методике, исправные файлы и соответствующие ключи реестра копируются с работоспособной станции-донора. Слабое место метода в том, что для реализации требуется наличие находящейся на том же уровне обновлений нормально функционирующей операционной системы той же версии/ревизии.
В процессе повествования постараемся описать общую методику, тем не менее, в статье будут присутствовать частные случаи из практики.

далее про восстановление компонента методом прямой замены файлов

Ошибка обновления 0x80092004

Метки:  , , , ,

Настало радостное мгновение и корпорация Microsoft в очередной раз порадовала своих поклонников заплатками для систем Windows 7 и Windows Server 2008R2. При этом, все бы замечательно, если бы обновления устанавливались безотказно всегда и везде. Тем не менее, памятуя о том, что подсистема обслуживания на основе компонентов находится в перманентной бэте, процесс установки любого обновления от Microsoft представляет собой эксперимент с непрогнозируемым результатом. Так вышло и в ситуации, послужившей основой данной статьи: под руку попалась система, на которой установка обновлений KB4512486, KB4516033, KB4520003, KB4525233, KB4523206 и KB4525235 завершается с ошибкой 0x80092004. Ошибку можно лицезреть в Центре обновления Windows в следующем виде:

wsus 80092004

больше информации по ошибке 80092004

Зависает на classpnp.sys

Метки:  , , , , , , , , , ,

Данный материал представляет собой своего рода исследование, попытку разобраться в одной, набившей уже оскомину, загадке этапа загрузки операционной системы Windows. Многие специалисты согласятся со мной, что на практике довольно часто приходится наблюдать сбой при котором станция, загружаясь в безопасном режиме, отображает на экране монитора список загруженных драйверов (последним из которых часто выводится classpnp.sys) и сообщение "Подождите, пожалуйста...", после чего благополучно подвисает:

classpnp.sys

читать далее по теме зависает на classpnp.sys

Debugger can't get KD version information

Метки:  , ,

Иногда приходится наблюдать инциденты, когда при запуске отладчика WinDbg в режиме локальной отладки ядра (local kernel debugging), возникает следующая ошибка: Debugger can't get KD version information, Win32 error 0n5.

cant get kd version

Ошибка возникает не смотря даже на то, что отладчик WinDbg запускается из-под учетной записи с правами локального администратора, с использованием механизма эскалации (повышения) привилегий (Запуск от имени администратора). Ошибка указывает на то, что отладчик не может получить (Win32 error 0n5, символическое имя ERROR_ACCESS_DENIED) информации о версии отладки ядра. Описанную ошибку можно наблюдать в версиях Windows, начиная с Vista. Существует несколько причин возникновения ошибки Debugger can't get KD version information, Win32 error 0n5, описанием которых мы сегодня и займемся.

подробнее об ошибке debugger cant get kd version information