19.07.2021
itpro
PowerShell, Windows 10, Windows 11
комментария 3
В Windows 10 (а тем более в Windows 11), приложение Параметры (Settings) начинает играть крайне важную роль в управлении и настройке операционной системы. Классическая панель управления Windows (Control Panel) более не развивается и Microsoft добавляет новый функционал только в новую панель управления Settings. Однако уже несколько раз я сталкивался с ситуацией, когда приложение Параметры не открывается, закрывается после запуска, зависает при открытии некоторых разделов, или выдает ошибку при запуске. Рассмотрим основные способы, которые могут помочь восстановить приложение Settings в Windows 10 и Windows 11.
Ariston AVSL800 не запускается или зависает на полоскании
В моем случае при попытке открыть приложения Параметры Windows из стартового меню открывалось окно Setting с синим фоном:
А если вызвать любой из меню приложения (например, окно настройки параметров дисплея) с помощью команды ms-settings ( ms-settings:display ), или с рабочего стола появлялась ошибка:
ms-settings:display This file does not have a program associated with it for performing this action. Please install a program or, if one is already installed, create an association in the Default Programs control panel.
Сброс настроек приложения Параметры в Windows 10
В самом простом случае при проблемах с приложением Параметры можно сбросить его настройки на стандартные. Найдите с помощью поиска Windows приложение Settings и выберите App settings.
Для сброса настроек приложения Settings нажмите кнопку Reset.
Аналогичный “мягкий сброс” приложения Параметры в Windows 10 можно выполнить из PowerShell:
Get-AppxPackage windows.immersivecontrolpanel | Reset-AppxPackage
Если сброс не помог, убедитесь, что у вашего аккаунта есть NTFS права на чтение/запись файла манифеста приложения Settings (проще всего это сделать через PowerShell):
Компьютер намертво зависает. Все методы решения проблемы!
get-acl C:WindowsImmersiveControlPanelSystemSettings.exe.manifest |fl
По умолчанию права на этот файл есть только у NT SERVICETrustedInstaller .
С помощью утилит takeown и icacls сделайте свою учетку владельцем файла SystemSettings.exe.manifest и предоставьте себе полные права:
takeown /F ‘C:WindowsImmersiveControlPanelSystemSettings.exe.manifest’
icacls ‘C:WindowsImmersiveControlPanelSystemSettings.exe.manifest’ /grant desktop-1foh5a8root:F
Удалите файл (лучше просто переименовать его):
Rename-Item ‘C:WindowsImmersiveControlPanelSystemSettings.exe.manifest’ ‘C:WindowsImmersiveControlPanelSystemSettings.exe.manifest_bak’
Попробуйте еще раз сбросить параметры приложения Settings.
Если приложение Параметры закрывается сразу после щелчка по иконке, проверьте, возможно в настройках групповых политик пользователям запрещено запускать панель управления. В локальном редакторе групповых политик gpedit.msc этот пункт находится в разделе: User Configuration -> Administrative Templates -> Control Panel -> Prohibit access to Control Panel and PC Settings.
Этому пункту соответствует параметр реестра NoControlPan в HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionPoliciesExplorer.
Переустановка приложения Settings в Windows 10
Приложение Параметры (Settings) является встроенным UWP приложением Windows. Это значит, что вы можете обращаться с ним практически так же, как с любым другим APPX приложением Microsoft Store: удалить/установить/восстановить.
Проверьте, что в системе зарегистрирована приложение ImmersiveControlPanel:
Как вы видите, в отличии от других приложений магазина Microsoft оно находится не в ‘C:Program FilesWindowsApps’, а в ‘ C:WindowsImmersiveControlPanel ‘.
Попробуйте переустановить приложение ImmersiveControlPanel с помощью файла манифеста. Используйте такие команды PowerShell:
$manifest = (Get-AppxPackage *immersivecontrolpanel*).InstallLocation + ‘AppxManifest.xml’
Add-AppxPackage -DisableDevelopmentMode -Register $manifest
Если ничего не помогает, переименуйте каталог C:WindowsImmersiveControlPanel и проверьте и исправьте целостность системных файлов и компонентов образа Windows с помощью команд:
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
Данные команды должны пересоздать каталог ImmersiveControlPanel, взяв исходные файлы из хранилища компонентов Windows.
Предыдущая статья Следующая статья 
Источник: winitpro.ru
Зависает процесс
Сегодня мы поговорим о проблеме достаточно широко распространенной. Темой нашего разговора будут ситуации, когда в штатно функционирующей системе внезапно зависает процесс. Данная проблема, как мне кажется, является знакомой для каждого технического специалиста и, в то же время, крайне неудобной, поскольку вероятных проблем зависания может быть множество.
Зависания процесса случаются с завидной регулярностью на широком круге клиентских систем Microsoft, работающих на базе разнообразного аппаратного обеспечения. Никто не застрахован от ошибок, где-то их меньше, где то больше, но присутствуют они абсолютно везде.
В серверных конфигурациях, где набор рабочего ПО жестко ограничен и, как правило, достаточно хорошо оттестирован, ошибки встречаются значительно реже. Противоположностью этого являются клиентские операционные системы, где политики требования к программному обеспечению более мягкие, да и спектр ПО, работающего в системе шире. Зачастую возникновение ошибки в коде программы ведет к сбою, который выражается в «падении» (внезапном закрытии) программы, либо зависании. Ну и самый, пожалуй, неприятный вид проблем, это когда процесс зависает либо падает внезапно и с довольно высокой регулярностью.
Давайте немного отклонимся от основной линии повествования и потеоретизируем на тему зависания процесса. Какова её природа? Почему каким причинам программа может зависнуть:
- Внутренняя причина: Ошибка разработчика/модификатора, допустившего ошибку в коде исполняемого модуля.
- Внешняя причина: Бесконечное ожидание внешнего события, являющееся причиной аппаратного сбоя либо исчерпания ресурсов системы; ошибка стороннего исполняемого модуля, влияющего на
процесс исполнения кода основной программы (вирус/антивирус/другое ПО, имеющее подобный функционал).
Пожалуй что все причины я сейчас перечислить не смогу, да оно и не надо. К чему я завел весь этот разговор? Дело в том, что недавно ко мне прилетела одна интересная заявка. Обращался пользователь, у которого периодически вис редактор Winword.
Вис он абсолютно на разных стадиях, при редактировании файлов, содержащих большой объем, при создании новых файлов, при изменении маленьких файлов. Одним словом, никаких закономерностей в происходящем выявить пользователю не удавалось. Зависает процесс? Давайте принудительно завершим его и продолжим работу 🙂 Да, действительно, процесс можно было просто убить, если бы это была «штучная» проблема, поскольку никто не застрахован от багов, и в пакетах Microsoft они время от времени всплывают в виде редчайших внезапных сбоев фактически «на отлаженных системах». Но неприятная отличительная особенность данного сбоя была в том, что сбой не был «редким», а происходил с завидной регулярностью, фактически уже на протяжении нескольких дней и по несколько в период рабочего времени.
Запустил Монитор ресурсов (resmon), увидел пустую цепочку ожидания. Значит, проблема, с большой вероятностью, все же внутри процесса, поэтому было принято решение впервые провести отладку зависшего процесса.
Настройка инструментов отладки
Установка Debugging Tools for Windows
Перед тем как приступить непосредственно к отладке зависшего процесса, нам потребуется установить инструментарий под названием Debugging Tools for Windows (DTW), который входит в состав Windows SDK. Процесс установки подробно описан в статье Установка Debugging Tools for Windows, Не упускайте из виду тот факт, что необходимо версия разрядности дистрибутива должна соответствовать разрядности Вашей операционной системы. По окончании инсталляции рабочие директории комплекта Debugging Tools for Windows будут следующими:
- Для версии x86: C:Program Files (x86)Debugging Tools for Windows (x86)
- Для версии x64: C:Program FilesDebugging Tools for Windows (x64)
Но не исключено, что пути могут измениться в последующих версиях дистрибутива.
Настройка отладочных символов
Отладочные символы — информация, позволяющая использовать «символические» (понятные человеку) данные о бинарном файле, такие как имена процедур, функций и переменных, используемых в исходном коде программы.
В ситуации с 32-битным кодом я настоятельно рекомендую настраивать отладчик на работу с отладочными символами. В сети встречается мнение, что отладочные символы не нужны для вычисления сбойного драйвера/модуля (процесса, в контексте которого произошел сбой), но применительно к 32-битному коду часто наблюдал ситуацию, когда разбор стека отладчиком заканчивается результатами, далекими от истины. К тому же, при настроенных символах мы получаем дополнительную информацию по сбою и можем детальнее проанализировать, к примеру, стек вызовов момента сбоя на уровне процедур и функций.
Настроить отладчик на работу с отладочным символам можно несколькими способами. Первый, самый простой и традиционный, заключается в указании составного пути к символам в настройках отладчика WinDbg: srv*c:symbols*http://msdl.microsoft.com/download/symbols . Для настройки отладочных символов выберем в меню пункт «File» — «Symbol File Path . » и просто вставим указанное выше значение в поле ввода, затем нажмем клавишу ОК.
Теперь при запуске процесса отладки, отладчик WinDbg сначала произведет поиск символов для модулей, участвующих в процессе отладки, в локальной папке c:symbols , если там символов обнаружено не будет, то WinDbg попытается загрузить их из сети Интернет с сайта http://msdl.microsoft.com/download/symbols и закешировать (сохранить) в ту же папку c:symbols . Отладчик WinDbg загружает символы только по мере необходимости и только к модулям, которые обнаруживаются в процессе анализа дампа. Причем директорию c:symbols руками создавать не требуется, поскольку отладчик создаст её сам на стадии кеширования символов (в случае наличия у него соответствующих разрешений, конечно же).
Для того, чтобы не настраивать путь поиска символов каждый раз после запуска WinDbg, необходимо сохранить рабочее окружение отладчика. Для этого зайдите в меню «File» и выберите пункт «Save Workspace».
Отладка зависшего процесса
Теперь перейдем непосредственно к изучению подвисшего приложения. Отладку я производил непосредственно на клиентской рабочей машине, хотя тут есть некоторые пространство для маневров.
Все дальнейшие действия производятся от имени имени учетной записи с правами локального администратора.
Запускаем отладчик Windbg, либо непосредственным выбором из меню Пуск, либо можно просто ввести слово Windbg в строке поиска.
В интерфейса выбираем меню File , далее пункт Attach to a process (либо просто жмем клавишу F6 ):
В открывшемся списке ищем зависший процесс (в нашем случае это WINWORD.EXE), маркируем его и нажимаем кнопку OK . Происходит подключение отладчика к процессу (WINWORD), после чего в основном окне вывода мы наблюдаем следующее:
Источник: datadump.ru
Исправление зависания Steam при подготовке к запуску в Windows 10
