Рэймонд Чен — опытный инженер Microsoft, который десятилетиями участвовал в разработке Windows. Здесь, на Neowin, мы обычно освещаем его интригующие истории, связанные с миром Microsoft и Windows, например, объяснения того, почему ошибка в операционной системе не всегда является виной Редмонда, способы, которыми Windows 95 предотвращала хаос от внешних установщиков, «сетевая» природа WinHelp и многое другое.
Недавно Чен рассказал довольно интригующую историю, в которой его коллега расследовал таинственный рост числа сбоев Проводника (File Explorer). Естественно, при установке ОС на миллиарды разнородных конечных точек обычным подозреваемым был какой-то ошибочный код в самой Windows.
Однако при изучении дампов сбоев было обнаружено, что сбой происходит в 32-разрядном Проводнике при установке 64-разрядной Windows. Возможно, не все знают, но Microsoft поставляется с 32-разрядной версией Проводника в 64-разрядной Windows по соображениям совместимости. Обычно ее нельзя запустить обычным взаимодействием с пользователем, и она используется устаревшими 32-битными приложениями. Исполняемый файл 32-разрядного Проводника обычно можно найти в каталоге C:/Windows/SysWOW64.
Когда Чен заметил, что сбоит 32-разрядный Проводник, он решил, что это вряд ли вызвано действиями пользователя. Вместо этого было гораздо более вероятно, что стороннее 32-разрядное приложение взаимодействует с Windows нестандартным образом.
В ходе дальнейшего расследования выяснилось, что код стороннего деинсталлятора выполнял цикл, в котором он безуспешно пытался выполнить некоторые файловые операции. Это не редкость, поскольку деинсталляторы обычно стремятся очистить файлы приложений в процессе своей работы. Однако автор кода использовал неправильный соглашение о вызовах функций для извлечения параметров из стека.
Поскольку операция постоянно завершалась неудачей и повторялась, она продолжала извлекать параметры из стека до тех пор, пока указатель стека фактически не сместился в вызывающий код, который выполнялся. Это означало, что стек был исчерпан до такой степени, что вызвал повреждение данных, что и привело к сбою Проводника.
Если вы хотите лучше понять технические детали, ознакомьтесь со структурами данных «стек» в информатике на Википедии здесь или на любом другом предпочитаемом вами академическом сайте.
Хотя Чен не раскрыл подробностей о том, деинсталлятор какого приложения вызвал проблему и работала ли Microsoft с разработчиком над ее устранением, этот инцидент подчеркивает, что сбой компонента Windows не всегда означает вину Microsoft или операционной системы. Но с другой стороны, иногда это действительно так.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Usama Jawad
