Интеграция с оболочкой Windows ── контекстное меню, сопоставление файлов и изменения в Windows 11

Мне написали: «Перешли на ПК с Windows 11 — и контекстное меню приложения, которое вы нам когда-то делали, пропало». Если разобраться, оно не пропало. Щёлкните файл правой кнопкой и внизу меню выберите «Показать дополнительные параметры» — знакомое меню появится как раньше. Пункты вашего приложения просто спрятали на один щелчок глубже. С мест говорят: «лишний щелчок» и «стало больше обращений, что пункт не находят».

Это не сбой и не ошибка настройки, а изменение в Windows 11. Контекстное меню Проводника стало двухуровневым: новое и старое. Условия, при которых пункт попадает в новое меню, совсем другие, чем раньше.

При этом основа — сопоставление файлов и расширения оболочки — по-прежнему старый мир COM и реестра. Ключ расширения указывает на ProgID, verb у ProgID хранит командную строку, а более сложное расширение работает как внутрипроцессный COM-сервер (DLL), загружаемый в Проводник. Эта схема не менялась больше двадцати лет. Без знания и неизменной основы, и меню, которое Windows 11 разделила на два уровня, не отличить «меню нет», «оно спрятано» и «оно показывается дважды».

Статья для системных администраторов малых и средних компаний и для разработчиков Windows, которые сопровождают бизнес-приложения. В одной картине: трёхступенчатая схема сопоставления файлов, на что смотреть в классических расширениях оболочки, как попасть в новое контекстное меню Windows 11, а также регистрация, очистка и диагностика со стороны установщика.

1. Сначала выводы

• Основа контекстного меню и сопоставления файлов — трёхступенчатая схема реестра «ключ расширения → ProgID → verb». Ключ расширения — указатель на ProgID, ProgID — сущность, а shell\<verb>\command под ним хранит командную строку.¹
• HKEY_CLASSES_ROOT (HKCR) — не отдельный куст, а объединённое представление HKLM\Software\Classes и HKCU\Software\Classes. Регистрацию для всех пользователей пишите в HKLM, для одного пользователя — в HKCU, а HKCR считайте только для чтения.²
• Приложение по умолчанию (то, что открывается двойным щелчком) выбирает пользователь; программа забрать его не может. ОС защищает выбор пользователя; установщик может зарегистрироваться как кандидат.³
• Классическое расширение оболочки — внутрипроцессная COM DLL, загружаемая в Проводник. Сбой или задержка расширения бьют по Проводнику целиком (и по другим приложениям, которые пользуются оболочкой); в 64-разрядной среде нужна 64-разрядная DLL; реализация на управляемом коде не поддерживается.⁴⁵
• В Windows 11 контекстное меню разделено на два уровня. В новое меню попадают только команды, зарегистрированные через IExplorerCommand плюс удостоверение пакета; классические расширения IContextMenu отодвинуты в старое меню под «Показать дополнительные параметры» (Shift+F10).⁶⁷
• Официальный путь поместить свою команду в новое меню — зарегистрировать нативную DLL, реализующую IExplorerCommand, в манифесте MSIX (desktop4:FileExplorerContextMenus). Приложение, которое нельзя упаковать в MSIX, может получить только удостоверение через sparse package (MSIX с внешним расположением).⁷⁸
• Если нужно только «открыть этим приложением», по-прежнему хватает сопоставления и статического verb. DLL расширения оболочки не нужна, и сама Microsoft прямо говорит: «выберите самый простой метод, который закрывает требования (статический verb)».⁹
• После регистрации или изменения уведомите через SHChangeNotify(SHCNE_ASSOCCHANGED); при удалении удалите ProgID, но не удаляйте значение по умолчанию ключа расширения — так сказано в официальном руководстве. В интеграцию с оболочкой входит и то, как вы чистите регистрацию.¹¹⁰

Одной фразой: мир сопоставлений и verb не изменился; изменился только показ меню — в Windows 11 он стал двухуровневым. Дальше идём от основы.

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 16, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Как устроено сопоставление файлов ── трёхступенчатая схема ключ расширения → ProgID → verb

2.1. Читаем трёхступенчатую схему на одном примере

Что происходит при двойном щелчке по файлу данного расширения, решают три уровня ключей реестра.¹

HKEY_CLASSES_ROOT
   .kmrpt                                  ← (1) Ключ расширения
      (Default) = KomuraSoft.Report.1      ←     Указатель, который только именует ProgID
      OpenWithProgids
         KomuraSoft.Report.1               ←     Кандидат в «Открыть с помощью»
   KomuraSoft.Report.1                     ← (2) ProgID (сущность сопоставления)
      (Default) = Документ Komura Report
      DefaultIcon
         (Default) = "C:\Program Files\KomuraSoft\Report.exe",0
      shell                                ← (3) Список verb (глаголов)
         open
            command
               (Default) = "C:\Program Files\KomuraSoft\Report.exe" "%1"

• (1) Ключ расширения (.kmrpt) только указывает на имя ProgID как значение по умолчанию. Писать команду прямо сюда — ошибка.
• (2) ProgID (KomuraSoft.Report.1) — сущность сопоставления; в нём отображаемое имя, значок и список verb.
• (3) Verb — действие вроде «открыть» или «печать», а значение по умолчанию shell\open\command — реально запускаемая командная строка.

Благодаря этому разделению несколько расширений (например .kmrpt и .kmrpt-file) можно направить на один ProgID, а при обновлении приложения — подменить ProgID.

flowchart TB
    accTitle: Трёхступенчатая схема сопоставления файлов
    accDescr: Ключ расширения — указатель, чьё значение по умолчанию именует ProgID; ProgID — сущность с отображаемым именем, значком и списком verb; значение по умолчанию command под verb — реально запускаемая командная строка
    ext["Ключ расширения .kmrpt"] -->|значение по умолчанию указывает на ProgID| pid["ProgID KomuraSoft.Report.1"]
    pid --> vb["verb (open и другие под shell)"]
    vb --> cmd["значение по умолчанию command"]
    cmd --> exe["Запускается Report.exe"]
    pid -.-> attr["Также хранит отображаемое имя и DefaultIcon"]

Рис. 1: Ключ расширения — указатель, ProgID — сущность, а command у verb — реально запускаемая командная строка.

2.2. HKCR — «объединённое представление»: куда пишете, меняет смысл

Пример выше показан под HKEY_CLASSES_ROOT (HKCR), но HKCR — не физическое место хранения, а объединённое представление HKLM\Software\Classes и HKCU\Software\Classes. Если один и тот же ключ есть в обоих, побеждает сторона HKCU.²

flowchart TB
    accTitle: HKCR — объединённое представление
    accDescr: HKCR — это Classes из HKLM и HKCU, наложенные друг на друга; если один и тот же ключ есть в обоих, побеждает HKCU; регистрацию пишите явно в HKLM или HKCU и считайте HKCR только для чтения
    hklm["HKLM\Software\Classes (все пользователи)"] --> hkcr["HKCR (объединённое представление)"]
    hkcu["HKCU\Software\Classes (на пользователя)"] --> hkcr
    hkcu -.-> win["Если ключ один и тот же, побеждает HKCU"]
    hkcr -.-> ro["Считайте только для чтения (для проверки)"]

Рис. 2: HKCR — вид Classes из HKLM и HKCU, наложенных вместе; место записи всегда указывайте явно — одну из двух сторон.

На практике безопасное правило — всегда писать регистрацию явно в HKLM или HKCU и считать HKCR только для чтения (для проверки). Стоит разобрать и связь с перенаправлением реестра WOW64. Данные сопоставления прямо под HKLM\Software\Classes вроде ключей расширения и ProgID общие между 32- и 64-разрядными представлениями реестра начиная с Windows 7, поэтому 32-разрядный установщик, который их пишет, не уходит на сторону Wow6432Node. Некоторые подразделы COM-регистрации вроде Classes\CLSID, напротив, перенаправляются, и при регистрации расширения оболочки (внутрипроцессный COM) важно, куда именно пишете — в 32- или 64-разрядное представление. Подробности — в «Ловушки перенаправления реестра 32/64 бит и виртуализации — Wow6432Node и «значения, которое записали, нет»».

2.3. Регистрация на стороне приложения ── App Paths, Applications, RegisteredApplications

Есть и три вида регистрации на стороне приложения, в паре со стороной файла (расширение и ProgID).¹¹

• App Paths (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths): регистрация, которая позволяет ShellExecuteEx запускать программу только по имени исполняемого файла. Microsoft рекомендует этот путь, потому что не нужно засорять переменную среды PATH.
• Applications (HKCR\Applications\<приложение.exe>): задаёт способ открытия по умолчанию, когда произвольный файл передают через «Открыть с помощью», и отображаемое имя приложения (FriendlyAppName).
• RegisteredApplications + Capabilities: объявляет расширения и типы MIME, которые приложение умеет обрабатывать, — это регистрация, из-за которой оно появляется кандидатом на странице Параметры приложений по умолчанию Windows.

Большинство обращений «наше приложение не появляется в списке приложений по умолчанию» — случаи, когда ProgID зарегистрировали, а эту регистрацию Capabilities пропустили.

flowchart TB
    accTitle: Три вида регистрации на стороне приложения
    accDescr: Регистрация на стороне приложения бывает трёх видов — App Paths, Applications и RegisteredApplications — отвечающих соответственно за запуск только по имени файла, способ открытия по умолчанию в «Открыть с помощью» и появление на странице приложений по умолчанию
    app["Регистрация на стороне приложения"] --> ap["App Paths"]
    app --> apps["Applications"]
    app --> ra["RegisteredApplications"]
    ap --> r1["Запуск только по имени файла"]
    apps --> r2["По умолчанию в Открыть с помощью"]
    ra --> r3["Появляется на странице приложений по умолчанию"]
    r3 -.-> cap["Нужно объявление Capabilities"]

Рис. 3: Регистрация на стороне приложения бывает трёх видов, и чтобы появиться кандидатом приложений по умолчанию, нужна регистрация Capabilities.

2.4. Приложение по умолчанию принадлежит пользователю ── защита UserChoice

Запись ProgID как значения по умолчанию ключа расширения сама по себе не делает его приложением по умолчанию. Результат явного выбора пользователя в «Открыть с помощью» и подобном хранится в HKCU\...\Explorer\FileExts\<расширение>\UserChoice, и при разрешении сопоставления предпочитается эта сторона.

И важный момент: Windows не поддерживает программную смену приложения по умолчанию. Настройки приложения по умолчанию рассчитаны на пользователя через системный интерфейс Параметры; данные UserChoice обфусцированы, а драйвер-фильтр (UCPD.sys) блокирует запись из приложений. В управляемой среде официальное средство — групповая политика / политика MDM.³

То, что использовали инструменты вроде SetUserFTA, которые «имитируют хеш и переписывают», — обратная сторона этой защиты. В установщик своего приложения нужно класть не захват значения по умолчанию, а три вещи: (a) правильная регистрация ProgID и verb, (b) добавление себя в OpenWithProgIds и (c) при необходимости направление на страницу Параметры.

flowchart TB
    accTitle: Разрешение приложения по умолчанию и защита UserChoice
    accDescr: Результат явного выбора пользователя хранится в UserChoice и предпочитается при разрешении сопоставления; UCPD.sys блокирует перезапись из приложений, поэтому установщик может зарегистрироваться как кандидат и направить на страницу Параметры
    uc["UserChoice (выбор пользователя)"] -->|предпочитается| res["Разрешение сопоставления"]
    ext["Значение по умолчанию ключа расширения"] --> res
    wr["Перезапись из приложения"] -.->|UCPD.sys блокирует| uc
    res ~~~ inst["Работа установщика"]
    inst --> a1["Зарегистрировать ProgID и verb"]
    inst --> a2["Добавить в OpenWithProgIds"]
    inst --> a3["Направить на страницу Параметры"]

Рис. 4: При разрешении сопоставления предпочтение у выбора пользователя (UserChoice), и ОС защищает его от перезаписи приложениями.

3. Verb кроме «Открыть» ── print, edit, runas, свои verb

Verb — не только open. Среди стандартных verb, смысл которых знает ОС, рядом с open есть edit, print, play и preview; стандартный verb автоматически получает отображаемое имя по языку ОС. Verb по умолчанию при двойном щелчке определяется в порядке: значение по умолчанию ключа shell → первый verb в реестре → open → openwith.¹²

flowchart TB
    accTitle: Порядок, в котором определяется verb по умолчанию
    accDescr: Verb по умолчанию при двойном щелчке — первый найденный в порядке значение по умолчанию ключа shell, первый verb в реестре, open, openwith
    s1["значение по умолчанию ключа shell"] -->|если нет| s2["Первый verb в реестре"]
    s2 -->|если нет| s3["open"]
    s3 -->|если нет| s4["openwith"]

Рис. 5: Verb по умолчанию при двойном щелчке — первый найденный в этом порядке.

Когда хотите добавить своё действие, зарегистрируйте свой verb.

KomuraSoft.Report.1
   shell
      open
         command
            (Default) = "C:\Program Files\KomuraSoft\Report.exe" "%1"
      print
         command
            (Default) = "C:\Program Files\KomuraSoft\Report.exe" /print "%1"
      verify                          ← свой verb
         (Default) = Проверить отчёт (&V)   ← отображаемое имя в меню
         command
            (Default) = "C:\Program Files\KomuraSoft\Report.exe" /verify "%1"

Три мелких факта, которые полезно знать.

• Зарегистрируйте verb с именем runas — и определите запуск с повышением прав, эквивалентный «Запуск от имени администратора»; его же используют API семейства ShellExecute, когда указывают runas.
• Положите на ключ verb пустое значение с именем Extended — и он станет расширенным verb, который показывается только при Shift+правый щелчок. Удобно прятать опасную редко используемую операцию.¹²
• У части сопоставлений старых приложений ещё есть конфигурация, которая отправляет документ в уже запущенный процесс через DDE (ключ ddeexec), но запуск verb через DDE уже устаревшее наследие (Deprecated). Писать это заново незачем.¹²

Ещё одна частая ошибка — кавычки в командной строке. Если элемент командной строки может содержать пробел, его нужно обернуть в кавычки. Это относится и к пути EXE вроде C:\Program Files\..., и %1 (путь выбранного файла) всегда пишите как "%1". Нельзя гарантировать, что путь файла пользователя не содержит пробела. My Program.exe без кавычек толкуется как «запустить My с аргументом Program.exe».¹³

flowchart TB
    accTitle: Ошибка с кавычками в командной строке
    accDescr: Команда без кавычек режется по пробелу и ошибочно толкуется как запуск My с аргументом Program.exe, поэтому путь EXE, который может содержать пробел, и %1, обозначающий путь выбранного файла, всегда нужно оборачивать в кавычки
    c1["Команда без кавычек"] -->|режется по пробелу| bad["Ошибочно толкуется как запуск другого EXE"]
    c2["Команда в кавычках"] --> good["Запускается как задумано"]
    c2 -.-> q1["Оберните путь EXE в кавычки"]
    q1 -.-> q2["Всегда оборачивайте и %1 в кавычки"]

Рис. 6: Команда без кавычек ошибочно режется по пробелу, поэтому путь EXE и %1 всегда оборачивайте в кавычки.

Механизм только реестра до этой точки (статический verb) можно реализовать, не написав ни одной DLL, и он не рискует сделать Проводник нестабильным. Сама Microsoft неоднократно говорит: «прежде чем писать расширение оболочки, подумайте, хватит ли самого простого статического verb, который закрывает требования».⁹

4. Классические расширения оболочки ── DLL, которая работает внутри Проводника

4.1. Виды расширений оболочки

Требования, которые статический verb не закрывает — «менять меню динамически в зависимости от выбора», «подменить значок или страницу свойств» — закрывают обработчики расширения оболочки. Основные виды таковы.⁴

Всё это реализовано как классы COM и зарегистрировано в реестре по CLSID. Сама идея COM разобрана в «Что такое COM / ActiveX / OCX — различия и связь».

4.2. Что значит быть внутрипроцессным COM-сервером

Суть классического расширения оболочки в том, что это внутрипроцессный COM-сервер (DLL), загружаемый в Проводник (или в любое приложение, открывшее общее диалоговое окно файлов). Все ограничения следуют отсюда.⁴

• Если расширение падает, Проводник падает вместе с ним. Если оно зависает, правый щелчок замирает на несколько секунд. Ущерб не ограничивается Проводником: он достигает каждого приложения, показавшего диалог открытия файла.
• Построение меню идёт на потоке UI, поэтому нельзя делать медленную работу вроде доступа к сети или файлового ввода-вывода в момент показа меню.
• Модель потоков регистрируйте как правило Apartment.

flowchart TB
    accTitle: Как сбой внутрипроцессного расширения бьёт по хосту
    accDescr: DLL расширения оболочки загружается не только в Проводник, но и в процесс любого приложения, открывшего диалог файлов, поэтому сбой или зависание расширения распространяются на весь процесс-хост
    dll["DLL расширения оболочки"] -->|загружается внутри процесса| exp["Проводник"]
    dll -->|загружается внутри процесса| any["Любое приложение, открывающее диалог"]
    exp --> dmg["Сбой или зависание распространяются"]
    any --> dmg
    dmg -.-> rule["Не делать медленную работу при показе"]

Рис. 7: DLL расширения работает внутри процесса-хоста, поэтому сбой или зависание бьют по хосту целиком.

Разбирая обращение вроде «Проводник зависает, когда открываю определённую папку» или «правый щелчок занимает пять секунд», нередко выясняется, что причина — стороннее расширение оболочки, а не ваше приложение. Как локализовать причину — в главе 8.

4.3. Совпадение разрядности ── в 64-разрядной среде нужна 64-разрядная DLL

Внутрипроцессная DLL должна совпадать по разрядности с процессом, который её загружает. Проводник в 64-разрядной Windows — 64-разрядный процесс, поэтому DLL расширения оболочки, собранная только как 32-разрядная, вообще не загружается и в меню не появляется. Ошибки тоже нет, поэтому это типичная причина «зарегистрировал, а не появляется». Сочетание 32-разрядного тела приложения с 64-разрядной DLL расширения оболочки законно, но нужно следить за тем, что COM-регистрация делится по разрядности (Wow6432Node). Запуск из command у verb — отдельный процесс EXE, поэтому этому ограничению не подлежит (оставить 32-разрядный EXE нормально).

flowchart TB
    accTitle: Совпадение разрядности DLL расширения оболочки
    accDescr: Единственная DLL расширения оболочки, которую 64-разрядный Проводник может загрузить, — 64-разрядная; только 32-разрядная DLL не появляется в меню и не даёт ошибки; EXE, запускаемый из command у verb, — отдельный процесс и ограничению не подлежит
    exp["64-разрядный Проводник"] -->|может загрузить| d64["64-разрядная DLL расширения оболочки"]
    exp -.->|не может загрузить| d32["Только 32-разрядная DLL"]
    d32 -.-> sym["Не появляется в меню, без ошибки"]
    exe["EXE, запускаемый из verb"] -->|отдельный процесс| ok32["Можно оставить 32-разрядным"]

Рис. 8: В 64-разрядный Проводник загружается только 64-разрядная DLL; EXE, запускаемый из verb, этому ограничению не подлежит.

4.4. Почему нельзя писать на управляемом коде

Меня часто спрашивают «можно ли писать расширение оболочки на C#», но Microsoft прямо заявляет: писать внутрипроцессное расширение оболочки на управляемом коде (.NET) не рекомендуется и находится вне поддержки.⁵

Причина — природа расширения, загружаемого в произвольный процесс. Конфликт версий CLR (особенно ниже .NET Framework 4), повторный вход CLR в цикл сообщений в ожидании блокировки и недетерминированное время жизни объектов из-за сборки мусора, которое конфликтует с контрактом счётчика ссылок COM, — структурные причины нестабильности хоста. Часть пунктов смягчена в .NET Framework 4 и новее и в современном .NET, но официальная позиция не изменилась.

Практическое правило простое. Внутрипроцессное расширение пишите на нативном C++. Если нужен управляемый код, сделайте обычный EXE, запускаемый из command у verb, или внепроцессное расширение, работающее в отдельном процессе (обработчик предпросмотра и подобное).⁵

flowchart TB
    accTitle: Решение, допустим ли управляемый код
    accDescr: Внутрипроцессное расширение, работающее внутри Проводника, по правилу пишут на нативном C++; если нужен управляемый код, сделайте обычный EXE, запускаемый из command у verb, или внепроцессное расширение в отдельном процессе
    q1{"Работает внутри процесса?"} -->|да| cpp["Пишите на нативном C++"]
    q1 -->|нет| mg["Управляемый код допустим"]
    cpp -.-> why["Конфликт CLR и повторный вход делают хост нестабильным"]
    mg --> e1["EXE, запускаемый из verb"]
    mg --> e2["Внепроцессный предпросмотр"]

Рис. 9: Внутрипроцессное расширение по правилу — нативный C++; управляемый код ограничен конфигурацией, которая работает в отдельном процессе.

5. Новое контекстное меню Windows 11 ── меню, разделённое на два уровня

5.1. Что произошло

Windows 11 обновила контекстное меню Проводника. Вырезать, копировать и подобное стали рядом значков сверху; «Открыть» и «Открыть с помощью» сгруппировали сверху; команды, которые добавляет приложение, группируются под стандартными командами оболочки. Когда одно приложение добавляет несколько команд, их собирают во всплывающее меню (подменю, flyout) с именем приложения.⁶

И решающий момент таков. Классические расширения оболочки на IContextMenu не удалили; их отодвинули в старое меню, которое открывается «Показать дополнительные параметры» (Shift+F10) и загружает меню Windows 10 как есть.⁶ За «меню спрятали» в том начальном обращении как раз и стоит это разделение на два уровня.

flowchart TB
    accTitle: Контекстное меню, которое Windows 11 разделила на два уровня
    accDescr: Сначала при правом щелчке открывается новое меню; там появляются только команды, зарегистрированные через IExplorerCommand и удостоверение пакета; классические расширения IContextMenu отодвинуты в старое меню, открываемое «Показать дополнительные параметры»
    rc["Правый щелчок по файлу"] --> newm["Новое меню (Windows 11)"]
    newm --> newi["Команды IExplorerCommand + удостоверение"]
    newm -->|Показать дополнительные параметры Shift+F10| oldm["Старое меню (меню Windows 10)"]
    oldm --> oldi["Классические расширения IContextMenu"]
    newi -.-> fly["Несколько команд собирают во всплывающее меню"]

Рис. 10: В новое меню попадают только команды IExplorerCommand + удостоверение; классические расширения отодвинуты в старое меню.

5.2. Официальный путь в новое меню ── IExplorerCommand + регистрация в манифесте

Есть один способ поместить свою команду в новое меню. Подготовьте нативную DLL, реализующую интерфейс IExplorerCommand, и объявите COM-сервер и расширение контекстного меню в манифесте пакета MSIX.⁷

<!-- Манифест пакета (фрагмент) -->
<com:Extension Category="windows.comServer">
  <com:ComServer>
    <com:SurrogateServer DisplayName="Komura commands">
      <com:Class Id="01234567-89AB-CDEF-0123-456789ABCDEF"
                 Path="KomuraCommand.dll" ThreadingModel="STA" />
    </com:SurrogateServer>
  </com:ComServer>
</com:Extension>
<desktop4:Extension Category="windows.fileExplorerContextMenus">
  <desktop4:FileExplorerContextMenus>
    <desktop5:ItemType Type=".kmrpt">
      <desktop5:Verb Id="VerifyReport"
                     Clsid="01234567-89AB-CDEF-0123-456789ABCDEF" />
    </desktop5:ItemType>
  </desktop4:FileExplorerContextMenus>
</desktop4:Extension>

Type у ItemType может задавать конкретное расширение, или * (все файлы), Directory (папки) или Directory\Background (фон папки). Согласуйте DLL с архитектурой Проводника (64 бит / ARM64).⁷

Сам IExplorerCommand — интерфейс со времён Windows 7; вы реализуете заголовок (GetTitle), значок (GetIcon), состояние включено / отключено / скрыто (GetState) и выполнение (Invoke). Методы вызываются с потока UI, поэтому доступ к сетевым ресурсам запрещён, а методы построения меню должны возвращаться быстро. Тяжёлую работу делайте после Invoke.¹⁴⁷

flowchart TB
    accTitle: Структура манифеста регистрации в новом меню
    accDescr: Объявление COM-сервера в манифесте MSIX сопоставляет CLSID с DLL, а объявление расширения контекстного меню связывает цель и реализацию через ItemType и Verb, поэтому своя команда появляется в новом меню
    man["Манифест MSIX"] --> com["Объявление COM-сервера"]
    man --> ctx["Объявление расширения меню"]
    com -->|сопоставляет CLSID с DLL| impl["DLL реализации IExplorerCommand"]
    ctx -->|задаёт через ItemType и Verb| impl
    impl --> shown["Команда появляется в новом меню"]
    ctx -.-> tgt["Цель — расширение, все файлы и подобное"]

Рис. 11: Два объявления в манифесте связывают DLL реализации с целью, и команда появляется в новом меню.

5.3. Вариант для неупакованного приложения ── получить только удостоверение через sparse package

Выход, когда «наше приложение можно распространять только как MSI; MSIX невозможен», — sparse package (MSIX с внешним расположением). Вы подписываете небольшой MSIX, в котором есть только манифест, без тела приложения, и регистрируете его в конце существующего установщика. Тогда приложение получает удостоверение пакета, и регистрация в манифесте выше (то есть появление в новом меню) становится возможной. Доступно начиная с Windows 10 версии 2004; пакету нужна подпись сертификатом, которому доверяют на целевой машине.⁸

flowchart TB
    accTitle: Как получить удостоверение через sparse package
    accDescr: После того как существующий установщик разместил тело приложения, регистрация sparse package только с манифестом и внешним расположением даёт приложению удостоверение пакета и делает возможной регистрацию манифеста нового меню
    inst["Существующий установщик"] --> files["Разместить тело приложения"]
    sp["Sparse package"] -.-> only["Только манифест, без тела"]
    files --> reg["Зарегистрировать с внешним расположением"]
    sp --> reg
    reg --> id["Получить удостоверение пакета"]
    id --> ok["Регистрация в новом меню становится возможной"]
    sp -.-> sign["Нужна доверенная подпись"]

Рис. 12: Зарегистрируйте sparse package без тела с внешним расположением — и приложение получит удостоверение пакета.

Главное преимущество — не нужно менять установщик; это практичный ответ для приложения, у которого уже есть актив установщика MSI/EXE. Сравнение с полным переходом на MSIX см. также в «Как выбрать способ распространения Windows-приложения — MSI/MSIX/ClickOnce/xcopy/свой updater».

5.4. Как verb сопоставления выглядят в новом меню

Это легко понять неправильно: сопоставления глав 2 и 3 (ProgID и verb) в новом меню по-прежнему работают. Verb по умолчанию при двойном щелчке, «Открыть» и кандидаты «Открыть с помощью» разрешаются из сопоставления и показываются вверху нового меню. Поэтому если нужно только «открывать этим приложением», Windows 11 не требует дополнительной работы. С другой стороны, сопоставление — не универсальное расширение меню, поэтому произвольную свою команду в первый уровень нового меню ставят через IExplorerCommand плюс удостоверение — таково разделение ролей.⁷

flowchart TB
    accTitle: Разделение ролей между сопоставлениями и новым меню
    accDescr: Сопоставление ProgID и verb в новом меню по-прежнему используется, чтобы разрешить verb по умолчанию, Открыть и Открыть с помощью, и показывается вверху; произвольную свою команду в первый уровень нового меню ставят через IExplorerCommand и удостоверение
    assoc["Сопоставление (ProgID + verb)"] --> sol["Разрешить verb по умолчанию и Открыть"]
    sol --> top["Верх нового меню"]
    assoc -.-> keep["В Windows 11 дополнительной работы не нужно"]
    cmd["Произвольная своя команда"] --> need["IExplorerCommand + удостоверение"]
    need --> first["Первый уровень нового меню"]

Рис. 13: Сопоставления по-прежнему отвечают за разрешение семейства «Открыть» в новом меню; только своя команда требует IExplorerCommand плюс удостоверение.

6. Практическая таблица решения ── какой из трёх вариантов взять

Сводим сказанное в практический выбор из трёх.

Два пункта суждения. Первое: не тащите (b) или (c) под требование, которое закрывает (a). В момент, когда пишете расширение оболочки, вы берёте ответственность за стабильность Проводника. Второе: (c) лишь «не сломано»; как пользовательский опыт оно остаётся на шаг хуже. Чем чаще команда используется в повседневной работе, тем больше отдача от перехода на (b).

flowchart TB
    accTitle: Как выбирать среди трёх вариантов
    accDescr: Если нужен только запуск двойным щелчком или Открыть, хватит сопоставления и статического verb; чтобы поместить свою команду в новое меню, используйте IExplorerCommand и регистрацию в манифесте MSIX; если нельзя стать MSIX, выдайте удостоверение через sparse package; существующее классическое расширение IContextMenu пока оставьте на стороне старого меню
    q1{"Хватит Открыть?"} -->|да| pa["Сопоставление + статический verb"]
    q1 -->|нет| q2{"Своя команда в новом меню?"}
    q2 -->|да| q3{"Можете стать MSIX?"}
    q3 -->|да| pb1["IExplorerCommand+MSIX"]
    q3 -->|нет| pb2["Удостоверение через sparse package"]
    q2 -->|нет| pc["Пока оставить классическое"]
    pc -.-> old["Только сторона старого меню"]
    pa -.-> dllfree["Нет DLL, малый риск"]

Рис. 14: Выбирайте среди статического verb, IExplorerCommand плюс удостоверение и сохранения классического — по требованию.

7. Развёртывание и регистрация на практике ── установщик, sparse package, очистка

7.1. HKLM или HKCU

Согласуйте с формой установщика. Для всех пользователей (размещено под Program Files, права администратора) — HKLM\Software\Classes; установка на пользователя (без повышения) — HKCU\Software\Classes. Смешаете — получите обращение «у A открывается, у B нет». Для расширения оболочки с регистрацией CLSID Reg-Free COM — убирающий саму регистрацию в реестре — годится для COM внутри приложения, но неприменим к расширению оболочки, которое загружает Проводник, поэтому нужна прямая регистрация («Что такое Reg-Free COM — как использовать COM без регистрации»).

7.2. После изменения уведомите ── SHChangeNotify

После регистрации, изменения или удаления сопоставления уведомите о событии SHCNE_ASSOCCHANGED через SHChangeNotify. Пропустите это — и Проводник может не заметить изменение до перезагрузки.¹¹⁰

// Вызвать один раз после смены сопоставлений, например из пользовательского действия установщика
SHChangeNotify(SHCNE_ASSOCCHANGED, SHCNF_IDLIST, nullptr, nullptr);

7.3. Регистрация и снятие sparse package

Регистрация и снятие sparse package — работа установщика. Регистрируйте после размещения файлов; снимайте до удаления файлов.⁸

# При установке: после размещения файлов зарегистрировать папку установки как внешнее расположение
Add-AppxPackage -Path "C:\Program Files\KomuraSoft\KomuraReport.identity.msix" `
                -ExternalLocation "C:\Program Files\KomuraSoft"

# При удалении: снять регистрацию пакета до удаления файлов
Remove-AppxPackage <полное имя пакета>

На что смотреть: Add-AppxPackage регистрирует для пользователя, который его выполнил. Если вызвать из пользовательского действия MSI на всю машину под LocalSystem, удостоверение не выдаётся установившему пользователю, поэтому настраивают выполнение под олицетворением пользователя. Даже тогда регистрация под олицетворением — только для пользователя, выполнившего эту установку. На ПК с несколькими пользователями у других и у созданных позже пользователей нет удостоверения пакета, и команда не появляется в новом меню. Чтобы каждый пользователь мог пользоваться, дайте механизм вроде проверки своей регистрации пакета при первом запуске и регистрации, если её нет (регистрация на пользователя), и включите снятие у каждого пользователя с регистрацией в план удаления. Чтобы регистрация манифеста вступила в силу, может понадобиться перезапуск Проводника (или выход из системы).⁷

flowchart TB
    accTitle: Порядок регистрации и снятия sparse package
    accDescr: При установке регистрируйте sparse package после размещения файлов; при удалении снимайте регистрацию до удаления файлов; следите за тем, что регистрация действует только для пользователя, который её выполнил
    i1["Установка"] --> i2["Разместить файлы"]
    i2 --> i3["Зарегистрировать sparse package"]
    u1["Удаление"] --> u2["Снять регистрацию пакета"]
    u2 --> u3["Удалить файлы"]
    i3 -.-> pu["Регистрация действует только для текущего пользователя"]

Рис. 15: Регистрируйте после размещения файлов, снимайте до удаления и следите за тем, что регистрация — на текущего пользователя.

7.4. Очистка при удалении ── что удалять и что оставлять

У очистки при удалении есть ясная линия официального руководства.¹

• Удалять: весь свой ключ ProgID, регистрацию Capabilities/RegisteredApplications, регистрацию CLSID расширения оболочки, sparse package (Remove-AppxPackage).
• Оставлять: значение по умолчанию ключа расширения (.kmrpt). Официальная рекомендация — не удалять его, даже если оно всё ещё указывает на свой ProgID. После установки трудно судить, не забрало ли другое приложение значение по умолчанию, а Windows просто игнорирует незарегистрированный ProgID значения по умолчанию, так что оставлять его не вредно.
• Вызовите SHChangeNotify(SHCNE_ASSOCCHANGED) и в конце очистки.

Большинство проблем «удалили, а в меню ещё остатки» — пробел в этой очистке.

flowchart TB
    accTitle: Как чистить регистрацию при удалении
    accDescr: При удалении удаляете свой ключ ProgID, регистрацию CLSID и sparse package; оставляете значение по умолчанию ключа расширения, потому что незарегистрированный ProgID игнорируется; в конце очистки уведомляете об изменении через SHChangeNotify
    un["Удаление"] --> del["Удалить"]
    un --> keep["Оставить"]
    del --> d1["Регистрация ProgID и CLSID"]
    del --> d2["Sparse package"]
    keep --> k1["Значение по умолчанию ключа расширения"]
    k1 -.-> why["Незарегистрированный ProgID игнорируется"]
    d1 --> fin["В конце уведомить через SHChangeNotify"]
    k1 --> fin

Рис. 16: Удалите свою регистрацию, оставьте значение по умолчанию ключа расширения и в конце очистки уведомите об изменении.

8. Диагностика ── нет, дубль, тяжело

8.1. Не появляется в меню

Локализуйте в таком порядке.

1. Какое меню смотрите: регистрация в классическом стиле появляется только на стороне старого меню под Shift+F10. Сначала проверьте оба.
2. Разрядность: только 32-разрядная DLL расширения оболочки не загружается в 64-разрядный Проводник (раздел 4.3).
3. Место регистрации: HKLM/HKCU, путаница Wow6432Node. Подтвердите фактический ключ через reg query.
4. Регистрация пакета: для нового меню подтвердите наличие через Get-AppxPackage, доверие сертификата подписи и путь -ExternalLocation, затем перезапустите Проводник.⁷
5. Пропущенное уведомление: если забыли SHChangeNotify, это видно по тому, помогает ли перезапуск Проводника.

flowchart TB
    accTitle: Порядок диагностики, когда не появляется в меню
    accDescr: Начните с подтверждения, какое меню смотрите, затем проверьте разрядность DLL, место регистрации в реестре, регистрацию пакета и подпись, и пропущенный SHChangeNotify, в этом порядке
    c1["Подтвердить, какое меню, старое или новое"] --> c2["Подтвердить разрядность DLL"]
    c2 --> c3["Подтвердить место регистрации HKLM и HKCU"]
    c3 --> c4["Подтвердить регистрацию пакета и подпись"]
    c4 --> c5["Распознать пропущенное уведомление перезапуском"]

Рис. 17: Когда «не появляется», проверяйте в порядке меню, которое смотрите, разрядность, место регистрации, регистрация пакета, пропущенное уведомление.

8.2. Появляется дважды или не исчезает

Типичные причины — одновременно живут классическая регистрация в реестре и регистрация в манифесте, пробел в очистке при удалении (раздел 7.4) или остатки ProgID старой версии. Если дважды только в старом меню — думайте об остатках; если на старом и новом — о сосуществовании двух регистраций.

flowchart TB
    accTitle: Диагностика двойного отображения
    accDescr: Дважды только в старом меню указывает на остатки вроде пробела в очистке или старого ProgID; дважды на старом и новом указывает на сосуществование классической регистрации в реестре и регистрации в манифесте
    q{"Где появляется дважды?"} -->|только старое меню| zan["Остатки"]
    q -->|старое и новое| hei["Сосуществование"]
    zan -.-> z1["Пробел в очистке или оставленный старый ProgID"]
    hei -.-> h1["Классическая регистрация в реестре сосуществует с новой"]

Рис. 18: Дважды только в старом меню указывает на остатки; дважды на старом и новом — на сосуществование.

8.3. Проводник тяжёлый или падает

Когда правый щелчок медленный или определённая папка падает, сначала составьте опись установленных расширений оболочки. Перечислите расширения не от Microsoft инструментом вроде ShellExView от NirSoft, временно отключите подозрительные и найдите виновную DLL методом половинного деления. При сбое подсказкой служит и «Faulting module» в Просмотре событий. Если причиной было своё расширение, подозревайте синхронный ввод-вывод или доступ к сети на пути построения меню (разделы 4.2 и 5.2).

flowchart TB
    accTitle: Поиск виновной DLL, когда тяжело или падает
    accDescr: Перечислите расширения оболочки не от Microsoft в ShellExView, временно отключите подозрительные и найдите виновную DLL методом половинного деления; при сбое подсказкой служит и faulting module в Просмотре событий
    s1["Опись расширений оболочки"] --> s2["Перечислить не от Microsoft"]
    s2 --> s3["Временно отключить и половинное деление"]
    s3 --> s4["Найти виновную DLL"]
    crash["При сбое"] -.-> ev["Проверить faulting module"]
    ev -.-> s4

Рис. 19: Временно отключите расширения не от Microsoft и ищите половинным делением; при сбое используйте и Просмотр событий.

8.4. Для проверки удобна Windows Sandbox

Проверка интеграции с оболочкой строится на подтверждении «установить в чистой среде → поработать → удалить → остатков ноль». Здесь удобна Windows Sandbox (Pro/Enterprise/Education): каждый запуск за несколько секунд поднимает совершенно новую одноразовую Windows, поэтому тесты регистрации и очистки установщика можно прогонять сколько угодно. Закроете — всё исчезнет, поэтому подходит и для расследования остаточного реестра.¹⁵

9. Итог

• Сопоставление файлов — трёхступенчатая схема «ключ расширения → ProgID → verb», а HKCR — объединённое представление Classes из HKLM/HKCU. Место записи указывайте явно и всегда оборачивайте %1 в кавычки.
• Приложение по умолчанию выбирает пользователь, из программы его не сменить. Работа установщика — правильно зарегистрироваться как кандидат.
• Классическое расширение оболочки — внутрипроцессная COM DLL, загружаемая в Проводник. Сбой или задержка бьют по целому; нужны 64 бита; управляемый код не поддерживается; правило — реализация на нативном C++.
• В Windows 11 контекстное меню разделено на два уровня. Чтобы поместить свою команду в новое меню, нужны IExplorerCommand плюс манифест MSIX; классический IContextMenu отодвинут на сторону «Показать дополнительные параметры».
• Для приложения, которое нельзя упаковать в MSIX, получить удостоверение через sparse package (MSIX с внешним расположением) — практичный ответ.
• Если нужно только «открыть этим приложением», сопоставления и статического verb по-прежнему достаточно. Начинать с самого простого средства — и официальная рекомендация.
• После регистрации, изменения или удаления уведомите через SHChangeNotify; при удалении удалите ProgID, но оставьте значение по умолчанию ключа расширения. Для проверки удобна Windows Sandbox.

Если замена ПК на Windows 11 заставила заметить, что «меню спрятали», сначала подтвердите, какой это из (a), (b) и (c) в таблице решения главы 6. Масштаб работы должно быть видно на месте.

Похожие статьи

• Что такое COM / ActiveX / OCX — различия и связь
• Что такое Reg-Free COM — как использовать COM без регистрации
• Ловушки перенаправления реестра 32/64 бит и виртуализации — Wow6432Node и «значения, которое записали, нет»
• Как выбрать способ распространения Windows-приложения — MSI/MSIX/ClickOnce/xcopy/свой updater
• Обратная совместимость интерфейсов DLL и COM — таблица: какие изменения ломают вызывающую сторону
• Как работает совместимость приложений Windows — продлеваем жизнь старым приложениям режимом совместимости, шимами и Compatibility Administrator

Смежные области консультирования

Компания KomuraSoft LLC занимается проектированием и реализацией сопоставления файлов, контекстных меню и расширений оболочки для бизнес-приложений; поддержкой нового контекстного меню Windows 11 (переход на IExplorerCommand, внедрение sparse package); проверкой регистрации и очистки существующего установщика; и расследованием причины, когда Проводник тяжёлый или падает. Можно начать с решения, что делать с «меню, спрятанным под Показать дополнительные параметры».

• Разработка приложений для Windows
• Использование и перенос существующих активов
• Технические консультации и ревью дизайна
• Связаться с нами

Справочные ссылки

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Почему в Windows 11 пункт контекстного меню нашего приложения виден только в «Показать дополнительные параметры»?

Потому что в Windows 11 контекстное меню Проводника разделено на два уровня — новое и старое. В новое меню попадают только команды, которые реализуют интерфейс IExplorerCommand и зарегистрированы в манифесте пакета MSIX (то есть имеют удостоверение пакета). Классические расширения оболочки на IContextMenu отодвинуты в старое меню, которое открывается через «Показать дополнительные параметры» (Shift+F10). Само расширение не сломано и пока продолжает работать, но чтобы пункт появился в новом меню, нужна миграция на IExplorerCommand и либо упаковка в MSIX, либо выдача удостоверения через sparse package.

Может ли установщик назначить наше приложение приложением по умолчанию для файла (тем, что открывается двойным щелчком)?

Нет. Приложение по умолчанию выбирает пользователь, и Windows не поддерживает смену приложения по умолчанию ниоткуда, кроме системного интерфейса Параметры. Данные UserChoice, в которых хранится выбор каждого пользователя, обфусцированы, а драйвер-фильтр (UCPD.sys) дополнительно блокирует запись из приложений. Установщик может зарегистрировать ProgID и verb, добавить себя в OpenWithProgIds, чтобы появиться кандидатом в «Открыть с помощью», и направить пользователя на страницу приложений по умолчанию. Правильная реализация — не забирать значение по умолчанию, а подготовиться к тому, чтобы вас выбрали.

Можно ли писать расширение оболочки на управляемом коде, например на C#?

Microsoft прямо заявляет: внутрипроцессное расширение оболочки (обработчик контекстного меню, обработчик значков и подобное) на управляемом коде не рекомендуется и не поддерживается. Расширение загружается в Проводник и в процесс любого приложения, открывшего общее диалоговое окно файлов, поэтому конфликт версий CLR, повторный вход и недетерминированное время жизни объектов делают хост нестабильным. Правило — реализация на нативном C++. Обычный EXE, который запускается из command у verb, или внепроцессное расширение вроде обработчика предпросмотра, работающее в отдельном процессе, на управляемом коде допустимы.

Что такое sparse package (MSIX с внешним расположением)?

Небольшой пакет MSIX, в котором нет файлов приложения, только манифест (сведения об удостоверении). Для приложения, установленного обычным установщиком (MSI, Inno Setup и подобными), его регистрируют через Add-AppxPackage с -ExternalLocation, указывая папку установки. Приложение получает удостоверение пакета и может пользоваться функциями, которые его требуют: регистрацией в новом контекстном меню Windows 11 и всплывающими уведомлениями. Доступно начиная с Windows 10 версии 2004; пакету нужна подпись кода сертификатом, которому доверяет целевая машина. Это практичный вариант, когда нужна поддержка нового меню без перевода всей поставки на MSIX.

Что делать, если пункт контекстного меню появляется дважды или не исчезает?

Сначала локализуйте причину: пункт виден в новом меню или в старом («Показать дополнительные параметры»). Типичное дублирование — одновременно живут классическая регистрация в реестре и регистрация в манифесте MSIX либо после удаления осталась регистрация ProgID или CLSID расширения. После смены сопоставления подозревайте также пропущенный SHChangeNotify(SHCNE_ASSOCCHANGED); сразу после регистрации пакета — что Проводник не перезапустили. Если это не помогает, временно отключите расширения не от Microsoft в ShellExView и найдите виновную DLL методом половинного деления.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.