App uri handlers registration verifier что это

Средняя оценка пользователей

Обзор файла

✻ Фрагменты данных файлов предоставлены участником Exiftool (Phil Harvey) и распространяются под лицензией Perl Artistic.

Что такое сообщения об ошибках AppHostRegistrationVerifier.exe?

AppHostRegistrationVerifier.exe — ошибки выполнения

Ошибки выполнения — это ошибки Windows, возникающие во время «выполнения». Термин «выполнение» говорит сам за себя; имеется в виду, что данные ошибки EXE возникают в момент, когда происходит попытка загрузки файла AppHostRegistrationVerifier.exe — либо при запуске приложения Windows, либо, в некоторых случаях, во время его работы. Ошибки выполнения являются наиболее распространенной разновидностью ошибки EXE, которая встречается при использовании приложения Windows.

В большинстве случаев ошибки выполнения AppHostRegistrationVerifier.exe, возникающие во время работы программы, приводят к ненормальному завершению ее работы. Большинство сообщений об ошибках AppHostRegistrationVerifier.exe означают, что либо приложению Windows не удалось найти этот файл при запуске, либо файл поврежден, что приводит к преждевременному прерыванию процесса запуска. Как правило, Windows не сможет запускаться без разрешения этих ошибок.

К числу наиболее распространенных ошибок AppHostRegistrationVerifier.exe относятся:

Не удается запустить программу из-за отсутствия AppHostRegistrationVerifier.exe на компьютере. Попробуйте переустановить программу, чтобы устранить эту проблему.

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

Поиск причины ошибки AppHostRegistrationVerifier.exe является ключом к правильному разрешению таких ошибок. Несмотря на то что большинство этих ошибок EXE, влияющих на AppHostRegistrationVerifier.exe, происходят во время запуска, иногда ошибка выполнения возникает при использовании Microsoft® Windows® Operating System. Причиной этого может быть недостаточное качество программного кода со стороны Microsoft Corporation, конфликты с другими приложениями, сторонние плагины или поврежденное и устаревшее оборудование. Кроме того, эти типы ошибок AppHostRegistrationVerifier.exe могут возникать в тех случаях, если файл был случайно перемещен, удален или поврежден вредоносным программным обеспечением. Таким образом, крайне важно, чтобы антивирус постоянно поддерживался в актуальном состоянии и регулярно проводил сканирование системы.

Как исправить ошибки AppHostRegistrationVerifier.exe — 3-шаговое руководство (время выполнения:

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

Шаг 1. Восстановите компьютер до последней точки восстановления, «моментального снимка» или образа резервной копии, которые предшествуют появлению ошибки.

Чтобы начать восстановление системы (Windows XP, Vista, 7, 8 и 10):

Если на этапе 1 не удается устранить ошибку AppHostRegistrationVerifier.exe, перейдите к шагу 2 ниже.

Шаг 2. Запустите средство проверки системных файлов (System File Checker), чтобы восстановить поврежденный или отсутствующий файл AppHostRegistrationVerifier.exe.

Средство проверки системных файлов (System File Checker) — это утилита, входящая в состав каждой версии Windows, которая позволяет искать и восстанавливать поврежденные системные файлы. Воспользуйтесь средством SFC для исправления отсутствующих или поврежденных файлов AppHostRegistrationVerifier.exe (Windows XP, Vista, 7, 8 и 10):

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

Если на этапе 2 также не удается устранить ошибку AppHostRegistrationVerifier.exe, перейдите к шагу 3 ниже.

Шаг 3. Выполните обновление Windows.

Когда первые два шага не устранили проблему, целесообразно запустить Центр обновления Windows. Во многих случаях возникновение сообщений об ошибках AppHostRegistrationVerifier.exe может быть вызвано устаревшей операционной системой Windows. Чтобы запустить Центр обновления Windows, выполните следующие простые шаги:

Если Центр обновления Windows не смог устранить сообщение об ошибке AppHostRegistrationVerifier.exe, перейдите к следующему шагу. Обратите внимание, что этот последний шаг рекомендуется только для продвинутых пользователей ПК.

Если эти шаги не принесут результата: скачайте и замените файл AppHostRegistrationVerifier.exe (внимание: для опытных пользователей)

Если этот последний шаг оказался безрезультативным и ошибка по-прежнему не устранена, единственно возможным вариантом остается выполнение чистой установки Windows 10.

Источник

Добавление поддержки приложений для веб-сайтов, использующих обработчики URI приложений

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

Для включения привязки приложения к веб-страницам необходимо выполнить следующие требования.

начиная с обновления «создатели Windows 10» поддерживаемые ссылки, которые были выбраны в Microsoft Edge будет запускать соответствующее приложение. Поддерживаемые ссылки, которые были выбраны в других браузерах (например, Internet Explorer и т. д.), будут работать в режиме обзора.

Регистрация для обработки ссылок вида http и https в манифесте приложения

Ваше приложение должно распознавать URI для веб-сайтов, которые оно будет обрабатывать. Для этого добавьте регистрацию расширения Windows.appUriHandler в файл манифеста вашего приложения Package.appxmanifest.

Например, если адрес вашего сайта — msn.com, следует внести следующую запись в манифест приложения:

Приведенное выше объявления регистрирует ваше приложение для обработки ссылок, относящихся к указанному узлу. Если у вашего сайта несколько адресов (например, m.example.com, www.example.com и example.com), добавьте отдельную запись в разделе для каждого адреса.

Связывание приложения и веб-сайта в JSON-файле

Для обеспечения возможности открытия расположенного на сайте содержимого вашим приложением добавьте имя семейства пакетов вашего приложения в JSON-файл, расположенный в корневом каталоге вашего веб-сервера или в известном каталоге в домене. Это указывает, что ваш сайт дает согласие на открытие содержимого в перечисленных приложениях. Имя семейства пакетов можно найти в разделе Packages в конструкторе манифеста приложения.

Windows установит https-соединение с вашим сайтом и будет искать соответствующий JSON-файл на вашем сервере.

подстановочные знаки;

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

Несколько приложений

Если вы хотите привязать к своему сайту два приложения, укажите оба имени семейства пакетов приложения в вашем JSON-файле windows-app-web-link. Возможна поддержка обоих приложений. Пользователю будет предлагаться выбрать способ открытия ссылки по умолчанию, если установлены оба приложения. если вы хотите изменить ссылку по умолчанию позже, они смогут изменить их в Параметры приложений для веб-сайтов. Разработчики также могут изменить файл JSON в любое время, и изменения могут вступить в силу в тот же день, но не позднее чем через 8 дней после обновления.

Для обеспечения наилучшего взаимодействия пользователя с приложением используйте пути исключений, чтобы предотвратить обращение к доступному только через Интернет содержимому в поддерживаемых путях в файле JSON.

Пути исключений проверяются в первую очередь, и, если обнаруживается соответствие, эта страница будет открыта в браузере, а не в заданном приложении. В приведенном выше примере «/Невс/*» включает все страницы по этому пути, а «/Невс *» (без прямой косой черты «Новости») включает в себя любые пути в разделе «Новости *», такие как «невслокал/», «невсинтернатионал/» и т. д.

Обработка ссылок на активацию для привязки ссылки к содержимому

Перейдите к файлу App.xaml.cs в вашем проекте Visual Studio и добавьте обработку связанного содержимого в разделе OnActivated(). В следующем примере страница, открываемая в приложении, зависит от URI:

Тестирование: локальное средство проверки

Вы можете тестировать конфигурацию своего приложения и веб-сайта путем запуска средства проверки регистрации хоста приложения, расположенного в папке:

%WINDIR%\system32\AppHostRegistrationVerifier.exe

Проверяйте конфигурацию своего приложения и веб-сайта путем запуска этого средства со следующими параметрами:

AppHostRegistrationVerifier.exehostname packagefamilyname filepath

Если средство ничего не возвращает, проверки будут работать для этого файла при отправке. Если возникает код ошибки, функция не будет работать.

Можно использовать следующий раздел реестра для принудительной проверки соответствия путей для неопубликованных приложений в рамках локальной проверки.

KeyName: ForceValidation значение: 1

Тестирование: проверка в Интернете

Закройте свое приложение, чтобы убедиться, что приложение запускается, когда вы нажимаете на ссылку. Затем скопируйте адрес одного из поддерживаемых путей на вашем веб-сайте. Например, если адрес веб-сайта — «msn.com», а один из путей поддержки — «path1», можно использовать http://msn.com/path1

Убедитесь, что ваше приложение закрыто. Нажмите клавишу Windows + R, чтобы открыть диалоговое окно Выполнить, и вставьте ссылку в этом окне. Вместо браузера должно запуститься ваше приложение.

Кроме того, можно протестировать приложение, запустив его из другого приложения с помощью API LaunchUriAsync. Можно также использовать этот API для тестирования на телефонах.

Если вы хотите отслеживать логику активации протокола, установите точку останова в обработчике событий OnActivated.

Источник

Application Verifier для программиста: тестирование Windows-приложений

Возможно в Вашем проекте и не пишут try < /* code */ >catch (. ) < >для того чтобы избежать исключений при работе с памятью, умеют закрывать хендлы и знают о виртуализации Windows Vista, а программы никогда не падают по непонятным и редко повторяемым причинам.

Тогда Вам повезло, можете переходить к следующему топику.

Но иногда происходят, казалось бы, странные вещи. Программа «падает» на ровном месте, память куда-то утекает, а еще один раз вам звонили с жалобой на странное поведение программы, работающей на сервере 24/7, но вы конечно «завернули» их проблему, убедив, что она аппаратно-зависимая, и ладно. Всё-таки разработка программ под Windows дело нередко хитрое, и от ошибок по невнимательности или из-за незнания архитектуры никто не застрахован. Я не буду учить, как этих ошибок не допускать — сам не знаю. Но вот одно средство для эффективной отладки могу посоветовать.

Речь пойдет о Microsoft Application Verifier. Но это не отладчик. Напротив, без отладчика, сама по себе, штука относительно бесполезная. А вот в совокупности с ним позволяет детектировать ряд важных платформо-зависимых проблем. Кроме того, не удастся получить сертификат «Сompatible with windows 7» без прохождения тестирования с использованием AppVerifier (собственно для “Vista Certified” так же, но об этом, видимо, говорить не принято). А этот сертификат — для пользователя некоторая гарантия, что получившая его программа, может лучше и не сделает, но хотя бы не навредит. Ладно, «вода» закончилась, приступим к делу.

Способ применения

Скачать и установить AppVerifier для Хаброчеловека, уверен, не сложность. Запустим (из под real-администратора, под Vista+ по-другому и не выйдет) его графическую оболочку:

Слева список приложений для тестирования; справа – список секций на проверку для выбранного приложения. В MSDN утверждается, что AppVerifier предназначен для тестирования программ на C++, но в целом применим для любого native кода.

Графическая оболочка не производит никаких тестов, только дает возможность выбора нужных пунктов. Сами проверки реализуются благодаря так называемым «слоям», динамически подключаемым библиотекам vfbasics, vfcompat, vfLuaPriv, vfprint (на них можно полюбоваться в папке system32 ). При запуске тестируемого приложения они подключаются к нему и перехватывают вызов системных функций, таких как HeapAlloc, GetTickCount, CloseHandle и многих других. Перехватчик производит ряд дополнительных проверок, затем вызывает оригинальную функцию, и поэтому, за исключением нескольких рассматриваемых далее случаев, это не скажется на работе тестируемого приложения. Разве что будет заметна некоторая потеря производительности. Субъективно в худшем случае программа «замедлится» в пять раз, а нужны ли какие-нибудь конкретные цифры или нет – оставлю на ваше усмотрение.

Здесь есть важная особенность: несмотря на то, что мы при добавлении выбираем файл тестируемого приложения, проверки привязываются только к его имени без пути. С одной стороны, можно не беспокоиться в какой конфигурации (и в какую папку) собирать проект (обычно папки для Debug и Release разные), но с другой – можно забыть об установленных проверках, и запуская программу с рабочего стола, удивляться, что она «не работает».

Про смысл тест-пунктов поговорим чуть позже, а сейчас добавим, к примеру notepad.exe и установим все галки. Запустим блокнот, добавим пару строчек, попробуем сохранить. О-па, неудача:

Не единственный исход ситуации, возможно, вы получите другое окно предупреждения, или вообще обойдется без него. Что же случилось? Обратимся снова к графической надстройке AppVerifier. На сей раз выберем пункт Logs из главного меню, увидим список лог-файлов ассоциированных с тестируемыми приложениями. По логу на запуск.

Физически эти лог файлы находятся в папке AppVerifierLogs в корне пользовательского профайла. Прочитать их голыми руками будет трудно (бинарный формат), поэтому тыкаем кнопочку “View” для соответствующего лога. Произойдет его дамп в xml и открытие дефолтной программы просмотра для xml:

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

Тут и краткое описание проблемы, и stack trace. И от меня подсказка, как искать ошибки, а не предупреждения. Кстати сказать, если ошибки присутствуют, то программа не получает сертификации на совместимость с Vista/Win7. Постойте, но это же блокнот?! Ну да, только тссс.

Лечение больного

Теперь запускаем отладчик. Пусть это будет отладчик, встроенный в студию, или бесплатный WinDbg из состава Debugging Tools for Windows (он конечно более навороченный, но сейчас это не имеет значения).

А вот и наш больной:

int _tmain( int argc, _TCHAR* argv[])
<
int *p = new int ();
delete p;
*p = 0; // p = 0 will be OK, but *p = 0 is error!
>

Потенциальную опасность этого фрагмента легко оценить, если бы строки с delete и перезаписью памяти были растянуты по времени. Но ни в дебажной, ни в релизной сборке такая проблема не детектируется (Visual Studio, конфигурация по умолчанию).

Теперь добавляем программу на тестирование группы Basics в Application Verifier. И запускаем её из под отладчика (из студии по F5, например). AppVerifier заговорил с нами голосом студии:

А в Debug Output показывается соответствующее структурное исключение:

=======================================
VERIFIER STOP 00000013: pid 0xB54: First chance access violation for current stack trace.

02B59FF8 : Invalid address causing the exception.
0082142F : Code address executing the invalid access.
0013F670 : Exception record.
0013F68C : Context record.

Оно рассказывает, что за исключение (00000013), с каким адресом памяти (02B59FF8) и по какому адресу кода (0082142F) произошло. Счастливчикам, скачавшим Windows Debug Symbols покажут и место в исходном коде, где произошла проблема и Stack Trace, который привел к исключению.

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

Детектируемые проблемы

Давайте теперь разберемся, какие проблемы позволит выявить нам AppVerifier. Все опции тестирования разделены на группы. Исключая группу «Low Resource Simulation» и тестов «TimeRollOver» и «HighVersionLie» проверки не меняют поведения приложения (в случае, если не будет обнаружено ошибок).

1. Искажающие проверки

1.1. Low Resource Simulation

Вот она причина падения блокнота. Тесты этой группы позволяют смоделировать поведение системы при нехвате ресурсов. Приложению запросто могут отказать (по датчику случайных чисел) в выделении памяти, создании файла, Event’а, окна, записи в реестр. Обычно есть некоторое «спокойное» время около 2-5 секунд, когда приложению разрешается пользоваться ресурсами в полную силу; сделано это, чтобы приложение вообще смогло запуститься (это придумали не так давно, раньше было грустнее). Нормальным поведением программы является стабильность; показ предупреждающих диалогов, но не «падения». Так что в коде нужно бы предусматривать данные ситуации.

1.2. TimeRollOver в группе Misc

DWORD time_end = GetTickCount() + 1000; // 1s timelimit
do < action(); >while (GetTickCount()

И это не единственный случай, что Вы скажете про следующий фрагмент?

Для диагностики подобных проблем проверка TimeRollOver «прогоняет» значение функции GetTickCount() быстрее. Полный цикл до обнуления значения проходит за 5 минут.

1.3. HighVersionLie в группе Compatibility

OSVERSIONINFO osvi;
ZeroMemory(&osvi, sizeof (OSVERSIONINFO));
osvi.dwOSVersionInfoSize = sizeof (OSVERSIONINFO);
GetVersionEx(&osvi);

BOOL bIsWindowsXP_or_Later = (osvi.dwMajorVersion >= 5) && (osvi.dwMinorVersion >= 1);
if (!bIsWindowsXP_or_Later)
printf( «Windows XP or later required.\n» );

В данном фрагменте допущена явная ошибка; с целью отсечь Windows 2000 (5.0) вводится дополнительная проверка на minor версию XP (5.1), но код также отбрасывает и Windows Vista (6.0). На Windows 7 (6.1) работать будет. Неужели это и есть причина плохой совместимости с Windows Vista? Microsoft утверждает, что 70% несовместимых с Vista программ не работают в том числе и из-за этой проблемы.

Но диагностика такой ситуации на компьютере разработчика затруднительна — у него одна, фиксированная версия ОС. Можно воспользоваться виртуальной машиной с другой версией ОС, а можно просто ткнуть галку HighVersionLie. Тогда значение GetVersionEx будет модифицировано (обычно по правилу dwMajorVersion += 3; dwMinorVersion = 0 ).

2. Немодифицирующие проверки

2.1. Memory в группе Basics

Проверка корректности вызовов HeapAlloc, GlobalAlloc и других API Windows Heap Manager. За утечками памяти не следит, но это можно решить другими способами.

2.2. TLS в группе Basics

Следит за корректностью вызовов Thread Local Storage API.

2.3. Exceptions в группе Basics

Следит за уместностью перехвата исключений, в частности попытки «заглушить» исключения Access Violation, «демаскирует» исключения в заглушках вида try < >catch (. ) < >.

2.4. Handles в группе Basics

Следит за допустимостью операций над хендлами, корректностью хендлов и их временем жизни. Чуть подробнее на английском.

2.5. Locks в группе Basics

Проверяет корректность использования критических секций, не допускает сброс критической секции из другого потока относительно установки критической секции.

2.6. DirtyStacks в группе Misc

Периодически заполняет неиспользуемую часть стека паттерном 0xCD, что позволяет обнаруживать неинициализированные переменные или параметры функций.

2.7. DangerousAPIs в группе Misc

2.8. LuaPriv

Limited-user-account privileges test. Проверяет, нужны ли программе административные привилегии, не выполняет ли программа действий, которые допустимы только для real-администратора.

Состоит из двух частей: предсказывающей (перечисляет все действия программы, которые может выполнить только администратор) и диагностической (отказывает программе в административных действиях с ошибкой ACCESS_DENIED ). Таким образом, программисту не обязательно тестировать программу отдельно логинясь гостем. Также проверяет ряд особенностей связанных с виртуализацией под Windows Vista и старше.

Заключение

AppVerifier — интересный инструмент, позволяющий выявить и решить ряд «плавающих» и «скрытых» (а иногда и специально спрятанных) проблем. Пользоваться им в целом не сложно, при определнных навыках — удобно. А если вы хотите получить сертификат «Windows compatible», то знакомства с ним не избежать. Лично мне помог уже на двух проектах, надеюсь будет полезен и Вам.

Источник