Не найден параметр appid в разделе
Как исправить в Windows ошибку «10016» для APPID
Если вы обнаружите в журнале событий операционной системы Windows постоянно повторяющую «100016» ошибку связанная связанную пользователя «LOCAL SERVICE» примерно такого содержания:
«Параметры разрешений для конкретного приложения не дают разрешения Локально Активация для приложения COM-сервера с CLSID <6B3B8D23-FA8D-40B9-8DBD-B950333E2C52>и APPID <4839DDB7-58C2-48F5-8283-E1D1807D0D7D>пользователю NT AUTHORITY\LOCAL SERVICE с ИД безопасности (S-1-5-19) и адресом LocalHost (с использованием LRPC), выполняемого в контейнере приложения Недоступно с ИД безопасности (Недоступно). Это разрешение безопасности можно изменить с помощью средства администрирования служб компонентов.»,
беспокоиться об этом не стоит, этот никак не влияет на работоспособность компьютера, все можно оставить как есть. Во всяком случае, именно так уверяет Microsoft, да и как показала практика, так оно и есть. Обратите внимание, CLSID обязательно должно быть <6B3B8D23-FA8D-40B9-8DBD-B950333E2C52>, а APPID — <4839DDB7-58C2-48F5-8283-E1D1807D0D7D>.
Если вкратце о проблеме, то системный пользователь LOCAL SERVICE не имеет прав на запуск процесса ShellServiceHost. Если в систему безопасности доступа к компонентам внести соответствующие изменения, ошибка должна исчезнуть.
В 99% случаев все будет серым, вы ничего не сможете ничего изменить, из-за отсутствия необходимых прав доступа. Исправить это можно только изменив в реестре настройки прав доступа к идентификатору приложения APPID, в нашем случае — <4839DDB7-58C2-48F5-8283-E1D1807D0D7D>. Ту у нас есть два пути, сложный для джедаев, где все придется делать руками или более простой, где за нас все сделает утилита в один клик.
Чтоб упростить себе жизнь рекомендую второй вариант Для этого скачиваем приложение RegOwnershipEx с сайта https://winaero.com/ и запускаем. В появившемся окне нажимаем кнопку «Browse…», выбираем раздел «HKEY_CLASEES_ROOT\ AppID\ <4839DDB7-58C2-48F5-8283-E1D1807D0D7D>» и жмем «Take Ownership». Оставляем программу RegOwnershipEx открытой в фоне, которая нам пригодиться, чтоб все вернуть к первоначальному состоянию.
После этого перезапускаем «dcomcnfg», чтоб нужные разделы стали активные. В окне «Безопасность» жмем кнопку «Добавить». В появившемся окне в поле для ввода «Введите имена выбираемых объектов» вписываем «LOCAL SERVICE», без кавычек, и жмем «Проверить имя», после чего кликаем мышью на OK. В следующем окне в таблице «Группы и пользователи:» выбираем «LOCAL SERVICE», где в разделе «Разрешения для группы» отмечаем галочкой все пункты в столбце «Разрешить». После чего со спокойной душой можем нажимать поочередно «ОК», «Применить» и еще раз «ОК».
На последнем шаге нужно вернуть все права доступа к первоначальному состоянию, в программе RegOwnershipEx нажать кнопку «Restore Ownership», если вы её не закрывали. Если закрыли, то запускаем, снова выбираем пункт «HKEY_CLASEES_ROOT\ AppID\ <4839DDB7-58C2-48F5-8283-E1D1807D0D7D>». В появившейся таблице ставим галочку на единственной строке подписанной «HKEY_CLASEES_ROOT\ AppID\ <4839DDB7-58C2-48F5-8283-E1D1807D0D7D>» (если вы конечно не меняли права доступа к другим разделам с помощью Restore Ownership) и жмем «Restore Ownership».
Для параметра «appIdName» предоставляется «недопустимое значение»?
Я работаю над этим приложением в течение нескольких недель, и все было замечательно. Я строил и архивировал и имел мяч. Все сертификаты, профили и идентификаторы имеют (казалось бы) порядок и работоспособность.
Затем несколько дней назад, казалось бы, без каких-либо изменений, которые я могу различить, Xcode сказал, что у меня не было никаких «профилей подготовки с действительным идентификатором подписи», и когда я сказал «исправить проблему», я бы получил это ошибка каждый раз:
Может ли кто-нибудь объяснить, что означает эта ошибка, и как я могу ее исправить? И для бонусных очков, что вызвало это, поэтому я могу избежать этого в будущем?
Я смог заставить его работать. Я пробовал использовать Cirec Beback, но вот более конкретные инструкции:
- Перейдите в Центр разработчиков Apple Developer и войдите в
Перейдите в «Сертификаты, идентификаторы и профили»
В разделе «Приложения iOS» выберите «Профили Provisioning Profiles»
В верхней части, в заголовке «Профили профилей iOS», нажмите кнопку «+»
Выберите «Разработка приложений iOS» и нажмите «Продолжить»
В раскрывающемся списке выберите свой параметр «Xcode: Wildcard AppID» и нажмите «Продолжить»
Выберите пользователя или всех и нажмите «Продолжить»
Выберите все устройства, которые вы хотите, я сделал все и нажмите «Продолжить»
Дайте профилю Provisioning Profile имя и нажмите «Продолжить»
Следующий экран будет иметь инструкции, но в основном он будет иметь ссылку для загрузки, поэтому загрузите профиль подготовки и откройте его. Тогда вам все будет хорошо!
Не найден параметр appid в разделе
Доброго времени суток, уважаемые читатели, сегодня решаем ошибку 10016 параметры разрешений для конкретного приложения не дают разрешения Локально Активация для приложения COM-сервера с CLSID
Ошибка 10016 в windows 10 и Windows Server
На сервере Windows Server 2012 R2 постоянно возникает ошибка 10016.
Параметры разрешений для конкретного приложения не дают разрешения Локально Активация для приложения COM-сервера с CLSID
и APPID
<9CA88EE3-ACB7-47C8-AFC4-AB702511C276>или <316CDED5-E4AE-4B15-9113-7055D84DCC97>или <4839DDB7-58C2-48F5-8283-E1D1807D0D7D>
пользователю NT AUTHORITY\СИСТЕМА с ИД безопасности (S-1-5-18) и адресом LocalHost (с использованием LRPC), выполняемого в контейнере приложения Недоступно с ИД безопасности (Недоступно). Это разрешение безопасности можно изменить с помощью средства администрирования служб компонентов.
Методы решения ошибки 10016
Сначала нужно обновить Windows через центр обновления, и если не поможет, то делаем по очереди предложенные решения:
Как исправить ошибку 10016 через назначение прав в реестре
9. На вкладке Безопасность. В разделе Разрешения на запуск и активацию кнопка Изменить. Для группы СИСТЕМА разрешаем Локальный запуск и Локальная активация. ОК. Если вам runtimebroker не дает отредактировать настройки, то вам нужно дать права на него в реестре Windows
щелкаем по нему правым кликом и выбираем свойства.
Даем права для группы администраторы (Полный доступ)
Если не даст вам поставить, то вам нужно заменить владельца Trustinstaller на себя или группу администраторы. Как только дали права, идем опять в компоненты DCOM и выставляем права, как описывал выше.
10. Перезагружаем сервер, проверяем логи, по сути ошибку 10016 параметры разрешений для конкретного приложения не дают разрешения Локально Активация для приложения COM-сервера с CLSID
Как исправить ошибку 10016 через удаление ключей из ветки OLe
Данный метод подразумевает удаление нескольких ключей реестра, которые отвечают за проверку прав на COM объекты. Нас будет интересовать ветка реестра:
Щелкаем по контейнеру Ole правым кликом и из контекстного меню выберите пункт Экспорт.
Задаем имя экспортируемого ключа. В случае проблем вы всегда сможете его импортировать и вернуть все к исходному состоянию.
Теперь, чтобы исправить ошибку 10016 в Windows 10 или как у меня в Windows Server 2012 R2 или выше, вам необходимо удалить четыре ключа:
теперь находим все эти ключи, щелкаем по ним правым кликом мыши и удаляем со спокойной душей, далее я вам советую перезагрузить вашу систему. В подавляющем количестве случаев ошибка с кодом 10016 у вас больше не появится.
Исправление ошибки 10016 через PowerShell
Если вам не удалось изменить запуск службы для системы, то можно все поправить и избавиться от сообщений «APPID
<9CA88EE3-ACB7-47C8-AFC4-AB702511C276>
пользователю NT AUTHORITY\СИСТЕМА с ИД безопасности (S-1-5-18) и адресом LocalHost (с использованием LRPC), выполняемого в контейнере приложения Недоступно с ИД безопасности (Недоступно)» с помощью скрипта PowerShell. Открываем ссылку с Microsoft
Скачиваем тут сценарий DCOMPermissions.psm1
Кладем данный модуль в нужную вам папку. Далее вы открываете консоль PowerShell и переходите в месторасположение данного модуля, после чего его нужно импортировать:
Если ошибок не вышло, то значит все успешно применено, перезагрузка не потребуется.
Далее вы можете посмотреть примененные разрешения:
Вы увидите права у системы, у нее будет SID S-1-5-10.
Параметры разрешений для конкретного приложения не дают разрешения Локально Активация для приложения COM-сервера
Доброе время суток!
Не могу избавится от ошибки:
Параметры разрешений для конкретного приложения не дают разрешения Локально Активация для приложения COM-сервера с CLSID
<8D8F4F83-3594-4F07-8369-FC3C3CAE4919>
и APPID
пользователю NT AUTHORITY\СИСТЕМА с ИД безопасности (S-1-5-18) и адресом LocalHost (с использованием LRPC), выполняемого в контейнере приложения Недоступно с ИД безопасности (Недоступно). Это разрешение безопасности можно изменить с помощью средства администрирования служб компонентов.
Параметры разрешений для конкретного приложения не дают разрешения Локально Активация для приложения COM-сервера с CLSID
и APPID
<9CA88EE3-ACB7-47C8-AFC4-AB702511C276>
пользователю NT AUTHORITY\СИСТЕМА с ИД безопасности (S-1-5-18) и адресом LocalHost (с использованием LRPC), выполняемого в контейнере приложения Недоступно с ИД безопасности (Недоступно). Это разрешение безопасности можно изменить с помощью средства администрирования служб компонентов.
В настройках DCOM это RuntimeBroker
Сообщение о нарушении
Данная ошибка не вызывает никаких проблем и неполадок в работе системы, поэтому в общем случае ее лучше игнорировать. Если все же у вас есть желание устранить эту ошибку, то ниже изложен порядок действий на примере второй ошибки из вопроса с APPID <9CA88EE3-ACB7-47C8-AFC4-AB702511C276>.
В окне «Свойства: RuntimeBroker» нажмите «Применить» и «OK.
Вернитесь к п. 7 и снимите отметку «Полный доступ» для группы «Администраторы», нажмите «Применить».
Вернитесь к п. 4 и сделайте обратно владельцем «Trustedinstaller», для этого в п. 5 вместо «Администраторы» напечатайте NT SERVICE\TrustedInstaller.
Выполните перезагрузку. Ошибка больше не должна появляться.
Какие приложения установлены на компьюетрах вашей сети?
По ряду причин важно регулярно осуществлять мониторинг приложений, установленных на компьютерах сети. Чтобы выполнить эту задачу можно не тратить средств, а воспользоваться бесплатным сценарием Windows PowerShell Get-InstalledApp.ps1.
Системным администраторам часто приходится определять, какие программы установлены на компьютерах обслуживаемых ими сетей. Существует целый ряд обстоятельств, которые заставляют их регулярно проводить аудит приложений, установленных на корпоративных системах. Бывает, что администратор устанавливает программный пакет, забывает его задокументировать, а позднее оказывается, что в системе безопасности пакета имеются уязвимые места. Иногда пользователи наделяются административными правами, позволяющими им самостоятельно устанавливать программные продукты на свои компьютеры. Существует и такая опасность: пользователь, самовольно присвоивший полномочия администратора, может установить несанкционированное программное обеспечение, открывая тем самым возможность привлечения организации к судебной ответственности.
Независимые провайдеры предлагают средства для мониторинга установленного программного обеспечения, но у небольших предприятий может не оказаться ресурсов для реализации такого решения. В нашей компании не было программного средства аудита, поэтому я написал сценарий Windows PowerShell Get-InstalledApp.ps1 (см. листинг). Перед тем как приступить к описанию процедуры использования этого сценария и механизма его работы, мне бы хотелось остановиться на двух методах обнаружения установленного программного обеспечения с помощью сценария и пояснить, чем меня привлек тот метод, на котором я остановил выбор.
Класс Win32_Product или реестр
В инструментарии управления Windows Management Instrumentation (WMI) имеется класс Win32_Product, который позволяет регистрировать приложения, установленные на компьютере. В среде PowerShell эта возможность реализуется просто. Так, команда
Get-WmiObject Win32_Product
| select name
генерирует список всех приложений, установленных на исследуемом в данный момент компьютере. Однако надо сказать, что классу Win32_Product присущ ряд ограничений.
Из-за перечисленных проблем целесообразность применения класса WMI Win32_Product снижается. Однако имеется альтернативный метод получения информации об установленных приложениях — непосредственно из реестра. Данные об установленных на компьютере приложениях содержатся в разделе реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ Windows\CurrentVersion\Uninstall. В каждом подразделе раздела Uninstall представлено установленное приложение, а значения в каждом подразделе отображают информацию о соответствующем приложении, как показано на экране. Таким образом, чтобы получить список приложений, можно «прочесать» раздел Uninstall и считать данные каждого подраздела, входящего в раздел Uninstall.
Провайдер реестра PowerShell дает возможность выполнять команду Get-ChildItem для получения списка имен приложений, установленных на исследуемом компьютере:
Get-ChildItem HKLM:\SOFTWARE\
Microsoft\Windows\CurrentVersion\
Uninstall |
ForEach-object <(Get-ItemProperty
Microsoft.PowerShell.Core\Registry::$_).
DisplayName>
Однако в среде PowerShell 1.0 команда Get-ChildItem не обеспечивает доступ к провайдеру реестра на удаленном компьютере, поэтому для достижения цели администратору приходится задействовать StdRegProv, класс управления реестром инструментария WMI. Класс StdRegProv предусматривает возможность использования полезного набора методов, облегчающих считывание реестра вне зависимости от того, с какой системой осуществляется взаимодействие, локальной или удаленной. Дополнительную информацию о классе StdRegProv можно найти на странице StdRegProv Class на сайте MSDN (http://msdn.microsoft.com/en-us/library/aa393664.aspx).
Как работать со сценарием Get-InstalledApp.ps1
Сценарий Get-InstalledApp.ps1 считывает информацию об установленных приложениях из реестра, после чего возвращает либо список всех установленных приложений, либо список приложений, отвечающих заданным критериям. В сценарии используется следующий синтаксис командной строки:
Get-InstalledApp [-computername]
[-appID] [-appname]
[-publisher] [-version] [-matchall]
Сценарий Get-InstalledApp.ps1 возвращает объекты, содержащие свойства ComputerName, AppID, AppName, Publisher и Version, поэтому вы можете использовать команды PowerShell и форматировать выходные данные в соответствии со своими потребностями. Так, команда
Get-InstalledApp | Select-Object AppName,
Version |
Sort-Object AppName
выводит список приложений и версию каждого приложения, отсортированные по именам приложений. Чтобы с помощью значений, разделенных запятыми, создать отчет по всем программным продуктам, установленным на всех компьютерах, которые перечислены в файле Computers.txt, нужно использовать команду
Get-InstalledApp (Get-Content
Computers.txt)
-appID » <7131646D-CD3C-40F4-97B9-
CD9E4E6262EF>» |
Select-Object ComputerName
Внутренние механизмы сценария Get-InstalledApp.ps1
Теперь, когда вы знаете, как пользоваться сценарием Get-InstalledApp.ps1, давайте посмотрим, каким образом он функционирует. Сначала с помощью команды param сценарий объявляет параметры командной строки; затем он создает две глобальные переменные для использования в дальнейшем при работе с классом StdRegProv. После этого сценарий объявляет функцию usage и главную функцию. Последняя строка сценария вызывает главную функцию.
предписывает главной функции заполнить хеш-таблицу с помощью ключа AppName, который имеет значение Windows Support Tools.
Затем функция main выясняет, является ли пустым параметр computername. Если параметр пуст, функция использует имя локального компьютера, которое она получает из переменной среды COMPUTERNAME. Если же параметр не является пустым, функция перебирает массив имен компьютеров с помощью цикла foreach. Цикл выполняется только раз, если аргумент computername параметра представляет собой имя одного компьютера.
После этого функция main использует метод EnumKey класса StdRegProv для перечисления подразделов раздела Uninstall. Результат применения метода EnumKey — массив имен подразделов — хранится в свойстве sNames. Далее функция перебирает массив имен подразделов с помощью другого цикла foreach.