Image file execution options ошибка

What is Image File Execution Options (IFEO)

Image File Execution Options refers to a new technology adopted by OSO virus for anti-virus software. Its effect is similar to file association. Through this technology, anti-virus software can also be put to death. It usually manifests as a normal program placed anywhere or after the system is repaired, there will be redirection or inoperability problems.
Let’s assume a scenario to better understand Image File Execution Options. Suppose your child is addicted to games and leads to a decline in academic performance. You might think that if the game program does not run, it will be great. Then, we can use Image File Execution Options technology to disable game software.

Before performing the following test, please make sure that your computer does not have antivirus software installed, because this technology is usually used by Trojan, so antivirus software will prohibit such operations.
Let’s take the Notepad program as an example.

1. Open the Registry Editor

Using the combine keys Win+R to open the Run window, enter regedit, and click OK to open the Registry Editor.

2. Locate IFEO in Registry Editor

On the left side of the Registry Editor, navigate to the following registry key.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options

3. Create a new registry key for Notepad

Right-click on the Image File Execution Options and select New -> Key, create a New Key#1.
Rename the newly created file New Key#1 to notepad.exe.

4. Set the debugger value for Notepad

Selected the newly key notepad.exe, right-click on the right window and select New -> String value, create a New Value#1. Change the name of New Value#1 to Debugger.
Double-click Debugger to pop up a dialog box, enter ntsd -d in the Value Data text box, and click OK. Then the Image File Execution Options is done.

5. Check and confirm the test

Now, let’s try to open a text document and you will see this error message.

In fact, ntsd -d can also be replaced with other executable programs name, for example, WiseCare365.exe. Then Wise Care 365 will be opened when you try to open a text file.

6. Some notes for Image File Execution Options

If you do not have anti-virus software, but still cannot create a new key, then you need to set the permissions of the Image File Execution Options.
This method is more powerful. If you use this method on someone else’s computer, it may cause someone to reinstall the system. So, be careful when using it!

How to fix Image File Execution Options issue

As mentioned before, Trojan program usually uses image file execution options (IFEO) to change system settings. There is a problem: How to remove the incorrect Image File Execution Options?
The answer is to delete the “Debugger” or fix the wrong associated program. If you can open the Registry Editor, navigate to the following registry key, then delete the Debugger in the incorrect registry key.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options

Of course, the registry cleaner in Wise Care 365and Wise Registry Cleaner can also remove image file execution options. The specific operations are as follows:

[Reference]
https://docs.microsoft.com/en-us/previous-versions/windows/desktop/xperf/image-file-execution-options

---

---

---

---

---

---

---

---

Adobe не поддерживает наличие нескольких версий Acrobat или Reader на одном и том же компьютере. Поскольку Acrobat и Reader работают со многими продуктами, установка нескольких версий на один компьютер может привести к конфликтам и ошибкам программного обеспечения. Кроме того, компания Adobe не рекомендует устанавливать на один компьютер и Acrobat, и Reader. Для выполнения этих действий требуются права администратора. Для получения подробной информации о правах администратора см. Документацию Windows или обратитесь в компанию Microsoft.

В следующей демонстрации показано, как удалить Acrobat или Reader в Windows XP.

Примечание. Выберите текущую учетную запись администратора, если группа «Администраторы» недоступна.

Если в Acrobat по-прежнему отображается сообщение об ошибке, можно просмотреть разрешения для указанного раздела реестра. По мере необходимости можно переименовать раздел, чтобы воссоздать его в программе установки и сбросить настройки разрешений, если раздел поврежден. Если не удается изменить права доступа или переименовать раздел, обратитесь в службу технической поддержки компании Microsoft или свяжитесь с поставщиком аппаратного обеспечения для получения помощи.  

Используйте последнюю версию антивирусного программного обеспечения, например McAfee VirusScan, чтобы проверить систему на наличие вирусов. Убедитесь, что антивирусная программа использует новейшие определения вирусов. Инструкции приведены в документации для антивирусного программного обеспечения.

Для получения дополнительной информации или помощи в отключении Spy Sweeper свяжитесь с Webroot Corporation. Служба Технической поддержки Adobe не поддерживает сторонние приложения.

Узнайте о том, не возникали ли похожие проблемы у других пользователей, посетив форум пользователей Adobe по Acrobat или Reader или Форум, посвященный внедрению и установке на веб-сайте AcrobatUsers.com. Если вы не нашли свою проблему, опубликуйте ее на форумах для интерактивного устранения неполадок. При размещении информации на форуме необходимо указать используемую операционную систему и версию продукта. 

Время на прочтение
14 мин

Количество просмотров 48K

Если вы много занимаетесь отладкой приложений под Windows — вы, возможно, слышали о таком замечательном механизме, как Image File Execution Options (IFEO). Одна из предоставляемых им возможностей позволяет отлаживать приложение в условиях, более приближенных к боевым. Записав в нужное место в реестре специальный ключик, мы можем вместо программы автоматически запускать её отладчик, позволяя ему делать свои отладочные дела. Однако кто сказал, что этот механизм (фактически — перехвата запуска чего угодно) можно использовать только в подобных целях? Эта статья вовсе не об использовании вещей по назначению.

Под катом рассказ о том, как я попытался выжать побольше из этого механизма в своих добрых целях, и какие подводные камни мне встретились на пути. А у меня тут хорошие, отборные камни.

Вообще говоря, идея эта не нова. Я знаю как минимум три программы, которые используют этот механизм для не-отладочных целей: широко известные Process Explorer и Process Hacker — для замены стандартного диспетчера задач; и AkelPad — для замены блокнота. Но я решил пойти немного дальше.

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

Что можно полезного сделать, обладая такими возможностями? Первое, что пришло мне в голову: спросить пользователя — а действительно ли он хочет, чтобы этот процесс запускался? Быстро разобравшись, как прописать себя в IFEO я смастерил крохотную утилиту с диалоговым окошком и кнопками Да/Нет, которая запускает перехваченную программу только при согласии пользователя. Сразу после запуска я осознал всю глубину своей наивности. Уже догадываетесь, что произошло при выборе «Да»? Конечно же, я снова запустил себя и получил новое окно с запросом подтверждения, и здесь можно продолжать до бесконечности. Перехват сработал отлично.

Не уверен, насколько полезным оказался бы этот механизм, если бы не было возможность его обойти: отладчику-то нужно запустить отлаживаемый процесс. Так что в Image File Execution Options есть одно исключение. Начнём с того, что в пользовательском режиме есть всего два метода запуска процессов: CreateProcess и ShellExecuteEx. Да и то, второй, в конце концов, тоже вызывает CreateProcess, но об этом позже. Так вот, исключение же это заключается в том, что запуски процессов с флагом DEBUG_PROCESS не перехватывается. Это и решает проблему с отладчиками, но, в моём случае, это также означает, что на IFEO нельзя полагаться полностью. И тем не менее, я не знаю ни одной программы (кроме отладчиков, разумеется), которые пользовались бы этим флагом. Нельзя просто поставить этот флаг и наслаждаться: понадобится дополнительный код, чтобы всё заработало.

Регистрация файла в IFEO

Если вы проследите с помощью Process Monitor’а за тем, что происходит при вызове функции CreateProcess — вы, вероятно, найдёте много чего интересного. Помимо коррекции ошибок в имени файла, о которой мы поговорим чуть позже, вы обнаружите обращение в реестр за настройками IFEO. Как это выглядит:

Если этот ключ будет найден, то также будет проверено наличие определённых полей, в том числе строкового поля Debugger. Оно-то нам и нужно. В нём хранится путь к отладчику, или, в нашем случае, к программе, запускаемой вместо данной.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution
Options\YourExecutable.exe]
"Debugger" = "C:\Path-to-debugger\Debugger.exe"

Стоит заметить, что здесь есть свои ограничения:

• Проверяется исключительно имя исполняемого файла. Это значит — никаких масок. Нельзя просто взять, и перехватить вызов *.exe.
• Действие для всех программ с одинаковым именем исполняемого файла будет одинаковым. До тех пор, пока мы не воспользуемся ключом UseFilter. Тогда, да, можно назначать конкретный отладчик для конкретного исполняемого файла, основываясь на его полном пути. Опять же — без масок.

Назначение стандартных действий

Изначальный смысл этой затеи для меня был в том, что, узнав про IFEO, я решил написать программу, которая предлагала бы пользователю набор типичных действий (реализованных в виде маленьких утилит), назначаемых для других программ. Это было ещё до того, как я решил написать статью, осознав, сколько тут занятных вещей можно рассказать. А потому, используем эти утилиты в качестве наглядного и практического примера для повествования. Итак, на что хватило моего воображения:

• Ask.exe — оповещает пользователя о попытке запуска и спрашивает разрешения;
• Deny.exe — отказывает в запуске. При этом может как оповещать пользователя, так и делать это молча. Очень удобно, если надо запретить винде запускать какую-нибудь телеметрию
• Elevate.exe — всегда запрашивает UAC для повышения прав до Администратора;
• Drop.exe — понижает привилегии процесса. Это просто венец творения. По смыслу аналогичен утилитам DropMyRights и PsExec с флагом -ℓ. Но в сочетании с IFEO — гораздо эффективнее;
• PowerRequest.exe — не даёт компьютеру заснуть / погасить экран до тех пор, пока программа не завершится.

Для регистрации этих действий было написано две версии представленной на скриншоте программы: GUI и консольная. Здесь и рассказывать не о чем. Просто читаем/пишем в реестр.

Как можно догадаться из заголовка, самое интересное — это как подменить чужую программу во время исполнения, и при этом ничего не сломать. Но сперва несколько очевидных, хотя и необходимых вещей. Если уж и запускать перехваченный процесс, то надо как можно лучше воспроизвести те же условия, при которых запустили нас самих. А это значит:

• Точно такая-же структура STARTUPINFO, установка флага bInheritHandles, и такая же рабочая директория;
• Ожидание завершения запускаемого процесса для получения его кода возврата и передачи по цепочке;
• И… ещё один трюк, о котором я расскажу чуть позже.

Хорошо. А как мы узнаем, что запускать-то?

Оценим возможности

Пусть в IFEO в качестве отладчика для программы A.exe прописано следующее:

"C:\My-Path\B.exe" /param

Если кто-то попытается создать процесс «C:\Folder\A.exe» с параметром -a то будет создан процесс B.exe cо следующей командной строкой:

"C:\My-Path\B.exe" /param "C:\Folder\A.exe" -a

Поскольку мы сами пишем код для B.exe — мы без проблем разберём командную строку на составляющие части и вполне можем запустить A.exe с теми же параметрами, с каким его хотел запустить этот безымянный кто-то. Здесь-то у нас и появляется полноценная свобода. Хотим — запускаем с другими привилегиями, захотим — сможем и передаваемые параметры поменять.

Любопытно во всём этом вот что: как, по-вашему, реагирует на столь вольное обращение контроль учётных записей? Правильный ответ: а никак. Если в проводнике выбрать «Запуск от имени Администратора» на файле A.exe, то в сообщении UAC будет показываться информация именно о файле A.exe, и именно его цифровая подпись будет определять цвет окна. А то, что вместо него будет запущен B.exe — это дело десятое. Нет, здесь нет особых проблем с безопасностью: запись в IFEO сама требует административных привилегий. Для нас это значит нечто иное: записав наши утилиты в IFEO мы вообще не будем смущать пользователя неверными сообщениями контроля учётных записей. Ведь с его точки зрения — так оно и должно выглядеть.

Как обычно запускают процессы

С появлением контроля учётных записей в Windows Vista запуск процессов стал более сложным. Дело в том, что теперь для запуска некоторых программ вызов CreateProcess может оказаться неудачным по причине недостатка прав. В этом случае GetLastError возвращает ERROR_ELEVATION_REQUIRED. На такой случай в Windows встроено даже специальное исправление проблем с совместимостью, хотя я так и не заметил, чтобы оно хоть что-то исправляло. Современные же программы в ответ на эту ошибку должны вызывать ShellExecuteEx с действием «runas» для запроса повышения привилегий. Это значит, что типичный код создания процесса теперь выглядит так:

if not CreateProcess(…) then
else if GetLastError = ERROR_ELEVATION_REQUIRED then
  ShellExecuteEx(…) // с действием "runas"
else
  // обработка других ошибок

Поскольку наши утилиты должны работать всегда, они не будут требовать повышенных привилегий для запуска, а значит тот процесс, который попытается запустить A.exe (и вместо него запустит наш B.exe) никогда не получит ERROR_ELEVATION_REQUIRED. Вроде бы: и ладно, ничего страшного, мы и сами cможем запросить повышение прав для него, если потребуется. А теперь представим себе, что так и произошло. Вот запустил кто-то A.exe, вместо него запустились мы, а поскольку A.exe требователен к привилегиям — мы не можем запустить его CreateProcess’ом, а потому должны использовать ShellExecuteEx. Уже догадались? ShellExecuteEx же всегда перехватывается IFEO, там нет флага DEBUG_PROCESS, который мог бы нас спасти. В результате мы снова запустим самого себя. Правда, на этот раз у нас уже хватит привилегий использовать CreateProcess для запуска A.exe. И всё это без каких-либо видимых следов со стороны UAC! Можно мозг сломать, не правда ли? Я и сам не до конца привык к концепции «почти всеобъемлющего перехвата своих же действий».

По этой причине в утилите Elevate.exe нельзя обойтись одним лишь ShellExecuteEx’ом — мы просто не сможем обойти IFEO. В случае же Ask.exe это добавляет ещё одну проблему. Вот спросили мы пользователя, подтвердил он запуск. А затем ShellExecuteEx’ом в сочетании с IFEO мы запустили снова себя. Что, опять спрашивать будем? Пришлось добавить подавление вторичного вопроса. А ведь это невозможно сделать простым дописыванием специального параметра: куда бы мы его не дописали, мы же всё равно собираемся запускать A.exe, так что он будет неотличим от его собственных параметров. Это весьма неплохое упражнение для ума — попытаться заранее предугадать все эти сложности.

Отличие CreateProcess от ShellExecuteEx

Вы читали документацию на CreateProcess? Там есть один момент, который многие упускают, потенциально создавая некоторую уязвимость в безопасности своих приложений. Это же относится и к устаревшей функции WinExec, являющейся обёрткой над CreateProcess’ом. Два первых параметра функции определяют, что и с какими аргументами будет запускаться. Это lpApplicationName и lpCommandLine. Вот перевод куска текста из MSDN:

Параметр lpApplicationName может иметь значение NULL. Тогда имя исполняемого файла должно быть первой отделенной пробелом подстрокой в lpCommandLine. Если вы используете длинные имена файлов, которые могут содержать пробелы, воспользуйтесь кавычками для указания, где заканчивается имя файла и начинаются аргументы. В противном случае имя файла является двусмысленным.

Почему люди продолжают забывать ставить кавычки? Так ведь и так работает — в CreateProcess встроен механизм коррекции ошибок. Установим lpApplicationName в NULL и попытаемся запустить программу передав в lpCommandLine имя её исполняемого файла: C:\Program Files\Sub Dir\Program Name. Что будет делать CreateProcess? Искать в строке то, что можно запустить, пока не найдёт, да ещё и подставляя расширение файла:

C:\Program Files\Sub Dir\Program Name
C:\Program.exe Files\Sub Dir\Program Name
C:\Program Files\Sub Dir\Program Name
C:\Program Files\Sub.exe Dir\Program Name
C:\Program Files\Sub Dir\Program Name
C:\Program Files\Sub Dir\Program.exe Name
C:\Program Files\Sub Dir\Program Name

Если хотите поэкспериментировать — создайте файл C:\Program.exe у себя на компьютере и посмотрите, попадётся ли какая из программ на это. У себя я поймал на этом Process Hacker (fix уже есть в ночной сборке), Punto Switcher (надо бы мне им тоже написать), и один из плагинов к Far Manager. Кстати, проводник Windows тоже знает об этой проблеме:

Возвращаясь к вопросу: а что это значит для нас? Из IFEO мы получаем именно lpCommandLine. Да, мы можем просто передать его в CreateProcess — если там и была такая проблема — она останется, здесь мы бессильны. Но также нам может понадобиться передавать его в ShellExecuteEx, а там, упс, такой коррекции ошибок нету. Там отдельно lpFile и отдельно lpParameters. Придётся самостоятельно разбирать строку по пробелам и искать имя первого существующего исполняемого файла также, как это делает CreateProcess. Супер.

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

Понижая привилегии

Принцип «Запускать любую программу с минимальными необходимыми ей правами» здесь, вероятно, знаком всем. Но вот что делать, если автор понравившейся вам программы об этом принципе не слышал — вопрос уже более сложный. Иногда в таких ситуациях спасают механизмы устранения проблем совместимости:

SetEnvironmentVariable('__COMPAT_LAYER', 'RunAsInvoker');

Это заметно снижает число случаев, когда CreateProcess не сможет запустить программу и вернёт ERROR_ELEVATION_REQUIRED. Но это работает не всегда. Например, над этим методом имеют приоритет *.sdb патчи.

Ещё есть специальные утилиты, которые умеют запускать процессы с Elevated-токеном (т.е. как-бы от имени администратора), но при этом вырезают все соответствующие привилегии. Это DropMyRights, написанная Майклом Ховардом из Microsoft, и PsExec из широко известного комплекта Microsoft Sysinternals, запускаемая с ключом -ℓ. Как ни странно, но эти утилиты добиваются своего разными путями.

Мне больше по душе оказался метод, используемый в DropMyRights. Да и исходники у него открытые. Используется там Windows Safer API, который позволяет буквально в несколько строк кода вычислять токен с урезанными привилегиями, который можно сразу использовать в CreateProcessAsUser. Эх, хотел бы я, чтобы все писатели инсталляторов знали, как это просто, и не запускали программы с максимальными правами по окончании установки…

А теперь объединим оба упомянутых подхода, совместив их с IFEO. В результате получаем автоматическое понижение прав и минимум запросов к контролю учётных записей. Не знаю как вам, но мне это очень нравиться. А поскольку повышение прав путём вызова ShellExecuteEx’а перехватывается всегда, то, насколько я понимаю, у программы, находящейся под действием нашей утилиты, нет шансов самостоятельно выбраться до тех пор, пока пользователь не подтвердит UAC для другого исполняемого файла, находящегося в кооперации с ограничиваемым. Но для действительно серьёзных случаев — пользуйтесь песочницами вроде Sandboxie. Или виртуальными машинами, если на то пошло.

Обход IFEO

Возвратимся к основной теме. Я вот всё говорю, мол, запустим процесс с флагом DEBUG_PROCESS и будет нам счастье, на свои грабли сами не попадёмся. Но для того, чтобы всё заработало, необходимо сделать ещё кое-что. С этим флагом мы запустим процесс под отладкой, а значит, нам будут приходить отладочные события. Если их не обработать — процесс так и останется висеть неподвижно. Для их обработки понадобятся всего две функции: WaitForDebugEvent и ContinueDebugEvent.

Однако не все программы нормально относятся к отладчикам, верно? Не то, чтобы я специально делал исключение ради вирусов, но отсоединение отладчика действительно будет лучшей идеей. Мы ведь здесь не ради написания отладчика собрались. А вот тут, неожиданно, наступает сложность: это действие, вероятно, относится к недокументированным возможностям, ибо на MSDN я его не нашёл. А потому будем пользоваться документацией Process Hacker’a. Итак, нам потребуется функция NtRemoveProcessDebug из ntdll.dll. Ей же нужен DebugObjectHandle, который можно получить с помощью NtQueryInformationProcess, запросив у неё ProcessDebugObjectHandle = 30 в качестве ProcessInformationClass. Вот и всё. Хотя… Лучше не делайте так с чужими процессами: их отладчик может в этот момент ждать отладочное событие, а для них самих может быть включён kill-on-close.

UPD.
Я был неправ, и потому пошёл более сложным путём. Документированная функция для этого есть, это DebugActiveProcessStop. Вместе с ней рекомендуется использовать DebugSetProcessKillOnExit.

Стоит заметить, что здесь имеется особенность, связанная с разрядностью операционной системы: 32-битный процесс не может запускать 64-битный процесс с флагом DEBUG_PROCESS. Зато 64-битный может запускать кого угодно.

Ах да, вы ещё помните? Выше я обещал рассказать про ещё один трюк, позволяющий добиться чуть лучшей совместимости при последующем запуске перехватываемых процессов.

Магия контроля учётных записей

Я уже говорил, что контроль учётных записей вообще никак не реагирует на происходящее. И если вы ещё тогда задались вопросом «А почему?», то вам точно сюда.

Как работает UAC и каким образом позволяет повышать привилегии? Хорошо ответ на этот вопрос дан в англоязычной статье Vista UAC: The Definitive Guide. Если коротко: ShellExecuteEx, пробиваясь через дебри вызовов COM, обращается к сервису AppInfo. Тот создаёт процесс consent.exe, который и выводит то окно с предложением подтвердить запуск, и, при необходимости, ввести пароль. Само создание процесса, естественно, происходит уже после всего этого. И используется там самый обычный CreateProcessAsUser. Именно на этом этапе срабатывает IFEO, и, перехватывая создание процесса, запускает нас. Именно поэтому контроль учётных записей ничего об этом не знает.

Самые догадливые уже должны были задаться вопросом: если процесс создаётся кем-то другим, то как получается, что его родительским процессом всё равно оказывается инициатор запроса?

Начиная с Windows Vista в CreateProcess вместо STARTUPINFO можно подсунуть STARTUPINFOEX (если воспользоваться флагом EXTENDED_STARTUPINFO_PRESENT). Он содержит всю ту же информацию + lpAttributeList со списком атрибутов процесса. Этот список атрибутов надо создать, вызвав InitializeProcThreadAttributeList, а затем обновить средствами UpdateProcThreadAttribute. Подменить родительский процесс можно, указав флаг PROC_THREAD_ATTRIBUTE_PARENT_PROCESS и предоставив дескриптор нужного процесса. О чём тут стоит помнить:

• Дескриптор процесса, которого мы делаем новым родителем, должен иметь права PROCESS_CREATE_PROCESS и жить вплоть до вызова DeleteProcThreadAttributeList;
• Следует установить значение поля cb вложенного STARTUPINFO в SizeOf(STARTUPINFOEX).

Готовый пример на C# есть на StackOverflow.

Часто ли вы при анализе, например, подозрительной активности на компьютере исходите из того, кто какой процесс запустил? О, теперь вы точно не станете так делать.

Тут есть некоторые любопытные особенности. Мне вспоминается шутливая фраза из одного мультика, звучит она примерно так: «да что там, даже при моём рождении не присутствовал ни один из моих родителей…». Как ни странно, но здесь возможно нечто подобное. Если между вызовом OpenProcess’a и самим созданием процесса назначаемый родитель будет завершён — не беда. Просто дочерний процесс будет «как бы» создан родителем после своего завершения. Почему бы и нет.

Всё бы хорошо, но этот трюк не сработает с ShellExecuteEx’ом — там всё просто: кто вызвал, тот и родитель. Однако поскольку у нас включён IFEO — финальное слово всегда остаётся за CreateProcess’ом: без него мы не выберемся из перехвата. Так что, пройдясь по цепочке процессов можно найти того, кто всё это затеял изначально, и назначить его родителем. Возможно, результат теперь не так красиво выглядит в Process Explorer’е и Process Hacker’е, зато с точки зрения чужого процесса всё будет в порядке. Ну, за исключением, разве что, «внебрачных» детей, которые появились при запуске и ожидают кода возврата перехваченного процесса. Тут уж ничего не поделать.

На картинке схема того, как я из Far.exe запускаю nsx.exe, на который назначено действие Ask.exe, и которому для запуска требуются повышенные привилегии.

Если честно, я думал, что идея с подменой родительского процесса — просто ещё одна прикольная возможность, не больше. Однако она действительно исправила несколько проблем. Так, тот же Far Manager может создавать второй процесс для выполнения более привилегированных действий, а при наличии перехвата эта функциональность ломалась. Подмена же родителя вновь починила это.

Чего делать не стоит

Я довольно долго не решался проверить это у себя на компьютере, ибо разворачивать виртуальную машину было лень: что будет, если в качестве запускаемой при перехвате программы установить её же саму? К счастью, ничего страшного. Но дальше я решил проявить благоразумие и не стал у себя на компьютере проверять гипотезы вроде «ой, а если попробовать создать цикл A → B → A…». Также, думаю, не стоит пытался устанавливать перехват важных системных процессов (я встроил их список в утилиту регистрации с подтверждением действия). Хотя, мне и любопытно, что произойдёт. Ибо всё, что я запускал от имени SYSTEM перехватывалось. Так что я добавил подавление всех диалоговых окон в нулевой сессии, ну, чтобы не зависеть в подобных случаях от сервиса UI0Detect.

И последнее: я не рекомендовал бы ставить действия на программы, создающие много однотипных процессов. Одно дело — пара дополнительных процессов, другое — целые полчища. Также не стоит трогать группы процессов, активно взаимодействующих друг с другом. И тех, что используют сложные дополнительные защитные механизмы. В общем, вы поняли: на chrome.exe лучше ничего не назначать. Если обнаружите проблемы совместимости: пишите мне или сразу в исходники на Гитхаб. В программу встроен список подобных проблем для предостережения пользователей.

Нерешённые проблемы

В Windows сосуществуют сразу несколько подсистем для исполняемых файлов. Три самых известных это Native (драйвера), Windows CUI (консольные приложения), и Windows GUI (графические приложения). Поскольку драйвера нас сейчас совершенно не интересуют — нам надо разобраться в различиях между вторым и третьим вариантом, и выбрать как компилировать наши утилиты. Вот здесь и начинаются проблемы — как мы хотим: красиво или удобно? Различия между этими подсистемами не столь велики, поскольку консольное приложение может создавать окна, а графическое — консоль. Да и то, GUI даже не всегда означает взаимодействие с пользователем: фоновые сервисы запускаются в svchost.exe, который работает в подсистеме Windows GUI.

Для нас существенным отличием являются начальные условия при запуске. За исключением особых случаев, приложения из консольной подсистемы при старте уже имеют консоль, притом видимую. Даже если первым делом при старте программы мы её спрячем, то она успеет появиться перед исчезновением. Хотим ли мы пугать неискушённого пользователя такими вещами? Наверное, нет. Я надеялся, что в исправлениях совместимости из Application Compatibility Toolkit найдётся что-то, что сможет исправить эту проблему, но, судя по всему, там нет функции «спрятать консоль по умолчанию». А потому, для себя я выбрал графическую подсистему. Всё бы хорошо, но у неё есть заметный минус. Если вы активно пользуетесь приложениями из консольной подсистемы, то сразу обратите внимание: все консольные программы, на которые назначено какое-либо стандартное действие, создают новую консоль, а не пользуются имеющейся. Это не критично, хотя и не всегда приятно. Если вам вдруг захочется сделать другой выбор в этом вопросе, а Delphi под рукой нет — просто пропатчите нужные файлы, отвечающие за стандартные действия: замените 02 на 03 по смещению 0x15C.

Заключение

Я надеюсь, что этот «экскурс в 1001 любопытный факт о работе Windows» оказался действительно любопытным и даже полезным. Я знаю, не все здесь жалуют Delphi, но уж с почти чистым WinApi, холиваров, надеюсь, не возникнет.

Код получившихся программ и бинарники доступны на Гитхабе. Программа тестировалась на Windows 7 и выше, про Windows Vista — без понятия. Ниже — однозначно нет.

P. S. Если у вас сложилось мнение, что в каком-то вопросе я основательно заблуждаюсь — не кидайтесь помидорами сразу, давайте сперва разрешим это недоразумение, и исправим неточности в статье. Спасибо.

When attempting to open the Task Manager in your Windows computer, you may receive the following error:

Windows cannot find ‘C:\Windows\system32\Taskmgr.exe’. Make sure you typed the name correctly, and then try again.

This error occurs no matter which method you use in order to launch Task Manager. Running taskmgr.exe with the full path via Run dialog will also not work.

(Go directly to solution)

Corrupt Taskmgr.exe file? Most likely not!

Obviously, the first thing anyone would do is run the System File Checker (sfc /scannow command) to see if the file Taskmgr.exe has become corrupt. Then you’ll find that the file integrity checks (signature/file size) using sfc /verifyfile and sfc /scanfile would come out just fine. Yet the issue occurs.

So what’s causing the Taskmgr.exe error? The “debugger” registry setting is!

The error occurs due to a “debugger” registry value set for Taskmgr.exe executable. This is either done by malware. Or it could be a legitimate app, a third-party process manager which you may have installed and then removed.

For example, the Process Explorer utility from Microsoft Sysinternals sets the debugger registry value when you enable the setting Replace Task Manager via the Options menu in Process Explorer.

As Process Explorer is a portable application, you can move the executable anywhere. If you had deleted or moved the file to a different folder, the “debugger” registry value would still be pointing to the old folder location. Hence the Taskmgr.exe error.

Malware connection? Could be!

If you’re not using a third-party process manager and yet the error occurs, this could be a handiwork of some malware. Some anti-malware scanners alert you about the presence of the debugger registry value, sensing it as a possible hijack attempt.

Security.HiJack[imageFileExecutionOptions]

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\TASKMGR.EXE

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\TASKMGR.EXE#Debugger

While the Image File Execution Options → Debugger registry value is to give developers the option to debug their software, malware writers make good (bad) use of this key to hijack programs. See Malwarebytes Labs article An Introduction to Image File Execution Options | Malwarebytes Labs for more information.

To fix the error ‘Windows cannot find ‘C:\Windows\system32\Taskmgr.exe’, all you need to do is remove the ‘debugger’, follow these steps:

1. Right-click Start, click Run (WinKey + R)
2. Type Regedit.exe and press ENTER
3. Go to the following registry key:

   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\taskmgr.exe

   Look what the registry value named Debugger is pointing to. This tells you which program has hijacked or replaced Taskmgr.exe. In case of obscure file names appearing as the debugger, it could be malware. Delete the value and run a thorough scan using Malwarebytes Antimalware or any other reputed malware and virus scanner.

4. Right-click the taskmgr.exe key, and choose Delete.
   
5. Exit the Registry Editor.

You should be able to launch Task Manager (Ctrl + Shift + Esc) now.