Поделиться через

Устранение неполадок при запуске PowerShell

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

  1. Создание процесса
  2. Инициализация состояния сеанса PowerShell
  3. Обработка профилей

К наиболее распространенным проблемам относятся:

  • Длительное время запуска или низкая производительность
  • Errors
  • Сбои

Шаги последовательности запуска

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

Шаг 1. Создание процесса

Создание процесса состоит из нескольких шагов.

  1. Создайте оконный хост

    В Windows хостом может выступать Windows Terminal, Windows Console Host, Visual Studio Code или любое другое приложение-хост. Проблемы, возникающие здесь, обычно не связаны с PowerShell, но и крайне редкими.

  2. Запустите процесс узла

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

  3. Подготовка .NET

    PowerShell основан на .NET, и он должен быть полностью загружен. В зависимости от того, какую версию PowerShell вы пытаетесь запустить, вы получите полную, интегрированную с Windows .NET Framework с Windows PowerShell 5.1 или более новой .NET, включенной в PowerShell 7.

    При первом запуске PowerShell, PowerShell и .NET выполняют задачи оптимизации. Эта задача оптимизации выполняется только один раз, во время первого запуска после установки, обновления или если кэш пуст. Запуск займет больше времени во время этой первой оптимизации. Сбой во время оптимизации может создать поврежденный кэш. Поврежденный кэш PowerShell может вызвать проблемы с обнаружением команд и загрузкой модулей.

Шаг 2. Инициализация SessionState в PowerShell

Загрузка двоичных файлов PowerShell и инициализация обработчика включает обработку конфигурации PowerShell и некоторые кэшированные данные.

  1. Файлы конфигурации процесса: powershell.config.json и файлы конфигурации PSSession, используемые JEA и другими сценариями удаленного взаимодействия. Эти файлы могут содержать параметры, которые могут повлиять на языковой режим, доступные команды и модули, а также некоторые параметры политики.
  2. Проверьте групповые политики и политики безопасности Windows. Групповые политики Windows могут переопределить параметры в элементе powershell.config.json. Политики безопасности могут включать такие функции, как WDAC (управление приложениями Защитника Windows), которые также могут ограничивать доступный языковой режим.
  3. Загрузите модули по умолчанию (Microsoft.PowerShell.Core и PSReadLine) и все модули и сборки, определенные в конфигурации PSSession.

Дополнительные сведения о функциях безопасности PowerShell см. в следующих статьях:

Шаг 3. Обработка профилей

Наконец, PowerShell запускает доступные файлы профиля. Скрипты профиля выполняются в следующем порядке:

  1. Все узлы всех пользователей
  2. Текущий хост всех пользователей
  3. Все узлы текущего пользователя
  4. Текущий хост Текущий пользователь

Замечание

Скрипты профилей не выполняются для удаленных сеансов.

Дополнительные сведения о профилях см. в about_Profiles.

Сузьте область проблемы

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

Попробуйте запустить PowerShell с отключенным профилем:

# PS 5.1:
powershell -NoProfile

# PS 7.*:
pwsh -NoProfile

Затем следует проверить, не связана ли проблема с конкретной версией. Попробуйте запустить профиль в Windows PowerShell 5.1 и PowerShell 7. Windows PowerShell и PowerShell 7 хранят профиль в разных расположениях. Ваш профиль может не совпадать с обеими версиями. Сравните файлы, чтобы понять различия. Вы можете попробовать установить профиль PowerShell в Windows PowerShell 5.1. Однако помните, что некоторые команды и модули PowerShell 7 несовместимы с Windows PowerShell 5.1.

Вы можете протестировать профиль PowerShell 7 в Windows PowerShell 5.1 без перезаписи существующего профиля.

  1. Запустите Windows PowerShell 5.1 с отключенным профилем.

  2. Вручную добавьте в сеанс Windows PowerShell 5.1 файл профиля PowerShell 7 с использованием команды dot-source.

    . $env:USERPROFILE\Documents\PowerShell\Microsoft.PowerShell_profile.ps1

  3. Обратите внимание, возникает ли проблема.

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

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

Устранение распространенных проблем с окружающей средой

Сбои во время запуска

Если консоль PowerShell завершает работу во время запуска, особенно рано и без обратной связи, может возникнуть поврежденный кэш процессов. Это редкое условие, которое можно устранить путем очистки кэша. Существует два расположения кэша, которые можно очистить:

  • Кэш пользователей: $env:LOCALAPPDATA\Microsoft\Windows\Caches
  • Системный кэш: $env:windir\System32\Config\SystemProfile\AppData\Local\Microsoft\Windows\Caches

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

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

  • Windows PowerShell: $env:windir\System32\Config\SystemProfile\AppData\Local\Microsoft\Windows\PowerShell
  • PowerShell 7: $env:LOCALAPPDATA\Microsoft\PowerShell

Удалите только следующие шаблоны файлов:

  • ModuleAnalysisCache-*
  • StartupProfileData-*

Кэшированные данные повторно создаются при следующем запуске PowerShell.

Если проблема сохраняется в Windows PowerShell 5.1, может потребоваться восстановить установку .NET Framework. Дополнительные сведения см. в разделе "Восстановление платформы .NET Framework".

Устранение распространенных проблем с профилем

В этом разделе описываются некоторые распространенные проблемы, которые могут возникнуть во время запуска PowerShell и способы их устранения.

На выполнение профиля уходит слишком много времени.

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

  • Определение места задержки

    Если для области AllUsers существуют скрипты профилей, возможно, вы не сможете изменить эти файлы. Обратитесь к системным администратором, чтобы просмотреть эти файлы. Для скриптов профиля области CurrentUser измените эти файлы, добавив сообщения с указанием времени, чтобы помочь вам определить причину задержки. Например, можно добавить следующую строку в различные точки сценария профиля.

    Write-Host "$(Get-Date -Format 'HH:mm:ss.fff') | Profile: Step X"

  • Сокращение зависимостей

    Уменьшите количество модулей, которые необходимо загрузить для выполнения профиля. Запустите Get-Module после запуска профиля, чтобы просмотреть модули, загруженные во время запуска. По умолчанию PowerShell загружает модули Microsoft.PowerShell.Core и PSReadLine. Все дополнительные модули были загружены вашими скриптами профиля.

    Модули можно загружать явным образом с использованием Import-Module или неявным образом с помощью команд, определенных в этих модулях. Рассмотрите необходимость команды или модуля, загруженного во время запуска.

  • Избегайте установки модулей в перенаправленной папке

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

    У вас есть несколько вариантов устранения этой проблемы:

    • Не перенаправляйте Documents папку, но это может быть не нужно
    • Modules Настройте папку в OneDrive, чтобы всегда храниться на диске. Это предотвращает ошибки и время задержки загрузки.
    • Установите модули в области AllUsers , которая находится за пределами папки профиля пользователя.

  • Измерение фактической производительности

    Если вы не знаете, сколько времени занимает выполнение вашего профиля, вы не можете определить, слишком ли оно долго. Командлет Measure-Command может показать, сколько времени занимает выполнение команды или блока скриптов.

    Стив Ли, менеджер по разработке PowerShell, написал запись в блоге, в которой описывается, как измерять производительность вашего профиля. В ней содержатся инструкции по созданию базовых показателей производительности, получения подробных сведений о времени и способах оптимизации профиля. См. статью "Оптимизация $Profile".

PowerShell 7 запускается медленно в изолированной сети

В этом сценарии компьютер Windows находится в сети, которая не подключена к Интернету. Для интерактивных сеансов PowerShell PowerShell автоматически загружает модуль PSReadLine. PSReadLine — это подписанный модуль. PowerShell должен проверить цифровую подпись модуля. Эта проверка может привести к задержкам в отключенной среде. Чтобы проверить эту теорию, запустите PowerShell 7 в неинтерактивном режиме:

pwsh.exe -noninteractive

Если PowerShell запускается быстро в неинтерактивном режиме, проблема, скорее всего, вызвана проверкой списка отзыва сертификатов (CRL). В процессе проверки цифровой подписи среда выполнения .NET проверяет список отзыва сертификатов (CRL), чтобы убедиться, что сертификат подписи по-прежнему действителен. В изолированной среде ваш компьютер не может получить доступ к списку отзыва сертификатов в Интернете. Время ожидания по умолчанию для проверок CRL составляет 15 секунд. Это означает, что каждый раз, когда PowerShell загружает подписанный модуль, время ожидания может занять до 15 секунд.

Существует три возможных обходных решения для этой проблемы:

  • Исключение брандмауэра или прокси-сервера

    Разрешение прямого доступа к Интернету для проверки списка отзыва сертификатов (CRL) предотвращает проблему. В среде, где вы можете управлять доступом к Интернету, вы можете настроить брандмауэр или прокси-сервер, чтобы разрешить доступ к URL-адресам CRL. Это самое простое решение с наименьшим воздействием. В журналах брандмауэра должен отображаться URL-адрес, к которому powerShell пыталась получить доступ.

  • Сократите время ожидания CRL

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

  • Отключение проверки CRL

    Параметры проверки списка отзыва сертификатов управляются групповой политикой. Дополнительные сведения см. в разделе "Управление доверенными издателями".

    Предупреждение

    Тем не менее, вы можете отключить проверку CRL (списка отзыва сертификатов), но это не рекомендуется. Отключение проверки отзыва сертификатов не позволяет фактически отозвать скомпрометированные сертификаты.

ОШИБКА: Невозможно выполнить команду dot-source, так как она была определена в другом языковом режиме.

PowerShell работает с системами управления приложениями, такими как AppLocker и управление приложениями в Защитнике Windows (WDAC), автоматически выполняя работу в режиме ConstrainedLanguage . Режим ConstrainedLanguage ограничивает некоторые функции, которые потенциально опасны. Однако иногда требуется режим FullLanguage для использования определенных команд или функций. Скрипты могут выполняться в режиме FullLanguage, когда политика им доверяет. Доверие можно указать с помощью подписывания файлов или других механизмов политики, настроенных в AppLocker или WDAC.

При запуске сеанса PowerShell, управляемого под управлением приложения, вы получите следующую ошибку:

Cannot dot-source this command because it was defined in a different language mode. To invoke this
command without importing its contents, omit the '.' operator.

Под управлением приложения PowerShell работает в режиме ConstrainedLanguage . Эта ошибка возникает, когда скрипт профиля исключен или подписан на выполнение в режиме FullLanguage . Если PowerShell работает в режиме ConstrainedLanguage, он не может выполнять (dot-source) код, которому доверено выполнение в режиме FullLanguage.

Чтобы устранить проблему, необходимо удалить исключение или подпись из скрипта профиля. Если вам нужен код, который должен выполняться в режиме FullLanguage во время профиля, переместите его в другой файл скрипта, который освобождён от ограничений или подписан. Вызовите (не точечный источник) этот файл скрипта из профиля.

Дополнительные сведения об этой проблеме см. в режиме ограниченного языка PowerShell и операторе Dot-Source.

Дополнительные материалы

  • Last updated on