Загрузчик клянётся, что DLL закреплена, но память с её кодом исчезла

Падение, которое оказалось четырьмя падениями в одном плаще

Расследование Реймонда Чена начинается с переполнения стека, которое дампы повесили на shell32.dll: рекурсивная петля из RtlLookupFunctionEntry и KiUserExceptionDispatch повторяется сотни раз, пока стек не кончается. Исходное исключение приводит к combase!CoTaskMemFree и строке, которая превращает рядовой баг в загадку: «Память, содержащая функцию CoTaskMemFree, освобождена».

Загрузчик по-прежнему числил combase.dll загруженной со счётчиком 0xFFFFFFFF — закреплённой, не подлежащей выгрузке. Таблица страниц с этим не соглашалась. Кто-то вызвал VirtualFree на памяти под модулем, который загрузчик считал постоянным, поэтому обычный учёт через FreeLibrary так и не отработал. При завершении процесса shell32 первой обратилась в мёртвый модуль — так она и оказалась с орудием убийства в руках.

Чтобы оценить масштаб, Чен собрал 100 свежих падений этой программы в сводную таблицу. Сигнатуры разлетелись: 11 переполнений стека в shell32, 23 нарушения доступа в неизвестном компоненте, ещё переполнения в ctxapclient64. Он называет это разбрызгиванием по корзинам — одна первопричина раскидывает падения по множеству разных корзин. В сумме 46% падений восходят к одной и той же самовольной принудительной выгрузке. Первая часть кончается без названного виновника: «Хорошая новость для команды shell32: они ни при чём, они жертва. Плохая: мы не знаем, кто виновник».

Тред спорит, кому достаётся Чен, а не о том, что он нашёл

Те в треде, кто сам выпускал код на C++, узнали эту картину раньше технической развязки.

«Хорошая новость для команды shell32: они ни при чём, они жертва. Плохая: мы не знаем, кто виновник. История разработки софта во все времена». — бывший программист на C++ и руководитель проектов

Один читатель прикинул, что разбрызгивание по корзинам означает для разбора инцидентов: один дефект раздувается в четыре непохожих друг на друга отчёта о падении.

«Это случай разбрызгивания по корзинам, когда одна базовая причина порождает большое число разных типов падений». — комментатор, который сам пересчитал распределение

Но громче всего звучал не баг. Звучала зависть к доступу. Инженер, который заводит баги Windows из виртуализированных стендов, спросил то, о чём думало большинство:

«Какая политика поддержки MSFT нужна, чтобы легендарный Реймонд Чен взглянул на проблему? …Заставить их вообще обратить внимание — это борьба в гору». — разработчик, который сообщает о багах Windows под виртуализацией

Одна деталь успокоила скептиков, а не наоборот: Чен получил эти 100 дампов потому, что сторонний конвейер отчётов о падениях реально доставил Microsoft пригодную телеметрию, как заметил читатель, считавший это показухой. Нерешённое — не механизм. Даже доказав невиновность shell32, дампы не говорят, какой модуль вызвал VirtualFree на combase. Первая часть опознаёт труп и снимает обвинение с не того подозреваемого; настоящего убийцу оставили на продолжение, которое один читатель уже откопал в треде.