Compartilhar via

Solucionar problemas de inicialização do PowerShell

Às vezes, o PowerShell pode ter problemas antes mesmo de estar pronto para uso. Problemas de inicialização podem ser difíceis de solucionar, especialmente quando você deseja usar o PowerShell para ajudar. Há três fases principais de inicialização:

  1. Criação de processo
  2. Inicialização de SessionState do PowerShell
  3. Processamento de perfil

Os problemas mais comuns incluem:

  • Tempo de inicialização longo ou desempenho lento
  • Errors
  • Falhas

As etapas da sequência de inicialização

É útil entender as etapas pelas quais o PowerShell passa durante a inicialização. Dessa forma, você pode restringir onde o problema está acontecendo.

Etapa 1: Criação do processo

A criação do processo tem algumas etapas:

  1. Criar uma janela host

    No Windows, o Host pode ser o Terminal do Windows, o Host do Console do Windows, o Visual Studio Code ou qualquer outro aplicativo de hospedagem. Problemas que ocorrem aqui geralmente não estão relacionados ao PowerShell, mas também extremamente raros.

  2. Iniciar o processo de hospedagem

    Os problemas que ocorrem aqui geralmente são causados por um executável corrompido ou por um problema no sistema operacional.

  3. Preparar .NET

    O PowerShell é baseado em .NET e precisa ser totalmente carregado. Dependendo de qual versão do PowerShell você está tentando iniciar, você obtém o .NET Framework completo integrado ao Windows com o Windows PowerShell 5.1 ou o .NET mais recente incluído no PowerShell 7.

    Durante a primeira inicialização do PowerShell, o PowerShell e o .NET executam tarefas de otimização. Essa tarefa de otimização só é executada uma vez, durante a primeira inicialização após a instalação, atualização ou se o cache estiver vazio. A inicialização levará mais tempo durante essa otimização inicial. A falha durante a otimização pode criar um cache corrompido. Um cache corrompido do PowerShell pode causar problemas com a descoberta de comandos e o carregamento do módulo.

Etapa 2: inicialização de SessionState do PowerShell

Carregar os binários do PowerShell e inicializar o mecanismo envolve o processamento da configuração do PowerShell e alguns dados armazenados em cache.

  1. Arquivos de configuração de processo: powershell.config.json e arquivos de configuração do PSSession usados pelo JEA e outros cenários de comunicação remota. Esses arquivos podem conter configurações que podem afetar o modo de idioma, comandos e módulos disponíveis e algumas configurações de política.
  2. Verifique as políticas de grupo e as políticas de segurança do Windows. As Políticas de Grupo do Windows podem substituir as configurações no powershell.config.json. As Políticas de Segurança podem habilitar recursos como o WDAC (Controle de Aplicativos do Windows Defender), que também pode restringir o modo de idioma disponível.
  3. Carregue os módulos padrão (Microsoft.PowerShell.Core e PSReadLine) e todos os módulos e assemblies definidos na configuração de PSSession.

Para obter mais informações sobre os recursos de segurança do PowerShell, consulte os seguintes artigos:

Etapa 3: Processamento de perfil

Por fim, o PowerShell executa os arquivos de perfil disponíveis. Os scripts de perfil são executados na seguinte ordem:

  1. Todos os Hosts Todos os Usuários
  2. Host Atual - Todos os Usuários
  3. Todos os hosts do usuário atual
  4. Host Atual Usuário Atual

Observação

Scripts de perfil não são executados em sessões remotas.

Para obter mais informações sobre perfis, consulte about_Profiles.

Restringir o escopo do problema

É útil remover variáveis e restringir o escopo específico de onde o problema acontece. A variável mais fácil de eliminar é o perfil. O perfil geralmente contém código personalizado, especialmente nos scripts de perfil específicos do usuário.

Tente executar o PowerShell com o perfil desabilitado:

# PS 5.1:
powershell -NoProfile

# PS 7.*:
pwsh -NoProfile

Em seguida, você deverá ver se o problema é específico da versão. Tente executar seu perfil no Windows PowerShell 5.1 e no PowerShell 7. O Windows PowerShell e o PowerShell 7 armazenam o perfil em locais diferentes. Seu perfil pode não ser o mesmo para ambas as versões. Compare os arquivos para entender as diferenças. Você pode tentar instalar seu perfil do PowerShell no Windows PowerShell 5.1. No entanto, lembre-se de que alguns comandos e módulos do PowerShell 7 não são compatíveis com o Windows PowerShell 5.1.

Você pode testar seu perfil do PowerShell 7 no Windows PowerShell 5.1 sem substituir seu perfil existente.

  1. Inicie o Windows PowerShell 5.1 com o perfil desabilitado.

  2. Faça a dot-source manualmente do seu arquivo de perfil do PowerShell 7 na sessão do Windows PowerShell 5.1.

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

  3. Verifique se o problema ocorre.

Se o problema persistir, você saberá que o problema é uma questão ambiental fora do perfil.

Tente executar o perfil em um dispositivo diferente. Se o perfil funcionar corretamente em outro dispositivo, você saberá que o problema é específico do dispositivo original.

Solucionar problemas ambientais comuns

Falhas durante a inicialização

Se o console do PowerShell falhar durante a inicialização, especialmente no início e sem comentários, você poderá ter um cache de processo corrompido. Essa é uma condição rara que você pode resolver limpando o cache. Há dois locais de cache que podem ser limpos:

  • Cache do Usuário: $env:LOCALAPPDATA\Microsoft\Windows\Caches
  • Cache do Sistema: $env:windir\System32\Config\SystemProfile\AppData\Local\Microsoft\Windows\Caches

Exclua primeiro o conteúdo da pasta de cache do usuário e tente iniciar o PowerShell novamente. Se o problema persistir, exclua o conteúdo do cache do sistema e tente novamente.

Talvez você também precise excluir o cache de análise do PowerShell. Você pode encontrar os arquivos de cache nos seguintes locais:

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

Exclua apenas os seguintes padrões de arquivo:

  • ModuleAnalysisCache-*
  • StartupProfileData-*

Os dados armazenados em cache serão recriados na próxima vez que você iniciar o PowerShell.

Se o problema persistir no Windows PowerShell 5.1, talvez seja necessário reparar a instalação do .NET Framework. Para obter mais informações, consulte Reparar o .NET Framework.

Solucionar problemas comuns de perfil

Esta seção descreve alguns problemas comuns que podem ocorrer durante a inicialização do PowerShell e como solucioná-los.

O perfil demora muito tempo para ser executado

Primeiro você deve definir o que é "muito longo". O PowerShell só está fazendo o que os scripts dizem para ele fazer. Verifique todos os caminhos de perfil. Pode haver vários scripts de perfil sendo executados. Examine o código para entender que ele está tentando fazer.

  • Determinar onde o atraso ocorre

    Se houver scripts de perfil para o escopo AllUsers, talvez você não consiga editar esses arquivos. Trabalhe com o administrador do sistema para examinar esses arquivos. Para os scripts de perfil de escopo do CurrentUser, edite esses arquivos para adicionar mensagens de temporização para ajudar a identificar onde ocorre o atraso. Por exemplo, você pode adicionar a linha a seguir em vários pontos no script de perfil.

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

  • Reduzir dependências

    Reduza o número de módulos que precisam ser carregados para executar seu perfil. Execute Get-Module após a execução dos perfis para ver os módulos que foram carregados durante a inicialização. Por padrão, o PowerShell carrega os módulos Microsoft.PowerShell.Core e PSReadLine. Quaisquer módulos adicionais terão sido carregados pelos seus scripts de perfil.

    Os módulos podem ser carregados explicitamente usando Import-Module ou implicitamente usando comandos definidos nesses módulos. Considere se você precisa de um comando ou de um módulo carregado durante a inicialização.

  • Evite instalar módulos em uma pasta redirecionada

    Em muitas situações no Windows, sua Documents pasta pode ser redirecionada para um compartilhamento de arquivos de rede ou para o OneDrive. O acesso a arquivos de rede pode ser lento, especialmente se a rede estiver congestionada ou se o servidor estiver sob carga pesada. Dependendo de como o OneDrive está configurado, ele também pode introduzir atrasos ou causar erros durante a exectução do perfil.

    Você tem algumas opções para atenuar esse problema:

    • Não redirecione sua Documents pasta, mas isso pode não ser desejado
    • Configure sua Modules pasta no OneDrive para sempre ser mantida em disco. Isso evita erros e tempos de carregamento atrasados.
    • Instale módulos no escopo AllUsers, que está fora da pasta de perfil do usuário.

  • Medir o desempenho real

    Se você não souber quanto tempo seu perfil leva para ser executado, não conseguirá determinar se é muito longo. O Measure-Command cmdlet pode mostrar quanto tempo um comando ou bloco de script leva para ser executado.

    Steve Lee, o Gerenciador de Desenvolvimento do PowerShell, tem uma postagem no blog que descreve como medir o desempenho do seu perfil. Ele inclui instruções para estabelecer uma linha de base para o desempenho, como obter informações detalhadas de tempo e maneiras de otimizar seu perfil. Consulte Otimize seu $Profile.

O PowerShell 7 é iniciado lentamente em uma rede isolada

Nesse cenário, seu computador Windows está em uma rede que não está conectada à Internet. Para sessões interativas do PowerShell, o PowerShell carrega o módulo PSReadLine automaticamente. PSReadLine é um módulo assinado. O PowerShell deve verificar a assinatura digital do módulo. Essa verificação pode causar atrasos em um ambiente desconectado. Para testar essa teoria, inicie o PowerShell 7 no modo não interativo :

pwsh.exe -noninteractive

Se o PowerShell for iniciado rapidamente no modo não interativo, o problema provavelmente será causado por verificações de CRL (Lista de Revogação de Certificados). Como parte do processo de verificação de uma assinatura digital, o runtime do .NET verifica a CRL para garantir que o certificado de assinatura ainda seja válido. Em um ambiente desconectado, o computador não pode acessar a CRL na Internet. O tempo limite padrão para verificações de CRL é de 15 segundos. Isso significa que, toda vez que o PowerShell carrega um módulo assinado, pode levar até 15 segundos para expirar.

Há três soluções alternativas possíveis para esse problema:

  • Isenção de firewall ou proxy

    Permitir acesso direto à Internet para verificação de CRL impede o problema. Em um ambiente em que você pode controlar o acesso à Internet, você pode configurar seu firewall ou proxy para permitir o acesso às URLs de CRL. Essa é a solução mais fácil com o menor impacto. Os logs de firewall devem mostrar a URL que o PowerShell tentou acessar.

  • Reduzir o tempo limite de CRL

    É possível reduzir o tempo limite de pesquisa de CRL, mas isso corre o risco de que outras pesquisas falhem, que não podem ser concluídas no tempo especificado. Para obter detalhes sobre como alterar o tempo limite, consulte Gerenciar a Recuperação de Rede e a Validação de Caminho.

  • Remover verificação de CRL

    As configurações de verificação de CRL são gerenciadas pela Política de Grupo. Para obter mais informações, consulte Gerenciar Editores Confiáveis.

    Aviso

    É possível desabilitar a verificação de CRL; entretanto, não é recomendável. Desabilitar a verificação de CRL impede que você realmente revogue certificados comprometidos.

ERRO: Não é possível fazer o dot-source desse comando porque ele foi definido em um modo de idioma diferente

O PowerShell funciona com sistemas de controle de aplicativos, como AppLocker e WDAC (Windows Defender Application Control), executando automaticamente no modo ConstrainedLanguage . O modo ConstrainedLanguage restringe alguns recursos que são potencialmente perigosos. No entanto, há momentos em que você precisa do modo FullLanguage para usar determinados comandos ou recursos. Os scripts podem ser executados no modo FullLanguage quando são confiáveis pela política. A confiança pode ser indicada por meio da assinatura de arquivo ou de outros mecanismos de política configurados no AppLocker ou no WDAC.

Ao iniciar uma sessão do PowerShell gerenciada sob controle de aplicativo, você recebe o seguinte erro:

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.

No controle do aplicativo, o PowerShell está em execução no modo ConstrainedLanguage . Esse erro ocorre quando o seu script de perfil é isento ou está assinado para ser executado no modo FullLanguage. Quando o PowerShell está em execução no modo ConstrainedLanguage, ele não pode ponto-fontear código confiável para execução no modo FullLanguage.

Para resolver o problema, você deve remover a isenção ou a assinatura do script de perfil. Se você precisar de código que deve ser executado no modo FullLanguage durante seu perfil, mova-o para outro arquivo de script isento ou assinado. Chame (não faça dot-source) esse arquivo de script de dentro do seu perfil do PowerShell.

Para obter mais informações sobre esse problema, consulte o modo de linguagem restrita do PowerShell e o operador Dot-Source.

Leitura adicional

  • Last updated on