Compartir a través de

Solución de problemas de inicio de PowerShell

A veces, PowerShell puede tener problemas antes de que esté listo para usarse. Los problemas de inicio pueden ser difíciles de solucionar, especialmente cuando desea usar PowerShell para ayudar. Hay tres fases principales de inicio:

  1. Creación de procesos
  2. Inicialización de SessionState de PowerShell
  3. Procesamiento de perfiles

Los problemas más comunes son:

  • Tiempo de inicio largo o rendimiento lento
  • Errors
  • Accidentes

Los pasos de la secuencia de inicio

Es útil comprender los pasos que PowerShell pasa durante el inicio. De este modo, puede restringir dónde está ocurriendo el problema.

Paso 1: Creación de procesos

La creación del proceso tiene algunos pasos:

  1. Creación de una ventana host

    En Windows, el host puede ser Windows Terminal, Windows Console Host, Visual Studio Code o cualquier otra aplicación anfitriona. Los problemas que se producen aquí normalmente no están relacionados con PowerShell, pero también son extremadamente raros.

  2. Iniciar el proceso de host del proceso

    Los problemas que se producen aquí suelen deberse a un ejecutable dañado o a un problema en el sistema operativo.

  3. Preparación de .NET

    PowerShell se basa en .NET y necesita cargarse por completo. En función de la versión de PowerShell que intente iniciar, obtendrá la versión completa de .NET Framework integrada en Windows con Windows PowerShell 5.1 o la versión más reciente de .NET incluida en PowerShell 7.

    Durante el primer inicio de PowerShell, PowerShell y .NET ejecutan tareas de optimización. Esta tarea de optimización solo se ejecuta una vez, durante el primer inicio después de la instalación, actualización o si la memoria caché está vacía. El inicio tardará más tiempo durante esta primera optimización. El error durante la optimización puede crear una caché dañada. Una caché de PowerShell dañada puede provocar problemas con la detección de comandos y la carga de módulos.

Paso 2: Inicialización de SessionState de PowerShell

Cargar los archivos binarios de PowerShell e inicializar el motor implica procesar la configuración de PowerShell y algunos datos almacenados en caché.

  1. Archivos de configuración de procesos: powershell.config.json y archivos de configuración de PSSession usados por JEA y otros escenarios de comunicación remota. Estos archivos pueden contener configuraciones que pueden afectar al modo de idioma, los comandos y módulos disponibles y algunas opciones de configuración de directiva.
  2. Compruebe las directivas de grupo y las directivas de seguridad de Windows. Las directivas de grupo de Windows pueden invalidar la configuración en el powershell.config.json. Las directivas de seguridad pueden habilitar características como WDAC (Control de aplicaciones de Windows Defender), que también pueden restringir el modo de idioma disponible.
  3. Cargue los módulos predeterminados (Microsoft.PowerShell.Core y PSReadLine) y los módulos y ensamblados definidos en la configuración de PSSession.

Para más información sobre las características de seguridad de PowerShell, consulte los siguientes artículos:

Paso 3: Procesamiento de perfiles

Por último, PowerShell ejecuta los archivos de perfil disponibles. Los scripts de perfil se ejecutan en el orden siguiente:

  1. Todos los Hosts Todos los Usuarios
  2. Host actual todos los usuarios
  3. Todos los hosts usuario actual
  4. Host actual Usuario actual

Nota:

Los scripts de perfil no se ejecutan para sesiones remotas.

Para obtener más información sobre los perfiles, vea about_Profiles.

Restringir el ámbito del problema

Resulta útil quitar variables y restringir el ámbito específico de dónde se produce el problema. La variable más fácil de eliminar es el perfil. El perfil suele contener código personalizado, especialmente en los scripts de perfil específicos del usuario.

Pruebe a ejecutar PowerShell con el perfil deshabilitado:

# PS 5.1:
powershell -NoProfile

# PS 7.*:
pwsh -NoProfile

A continuación, debería ver si el problema es específico de la versión. Pruebe a ejecutar el perfil en Windows PowerShell 5.1 y PowerShell 7. Windows PowerShell y PowerShell 7 almacenan el perfil en diferentes ubicaciones. Es posible que el perfil no sea el mismo para ambas versiones. Compare los archivos para comprender las diferencias. Puede intentar instalar el perfil de PowerShell en Windows PowerShell 5.1. Sin embargo, tenga en cuenta que algunos comandos y módulos de PowerShell 7 no son compatibles con Windows PowerShell 5.1.

Puede probar el perfil de PowerShell 7 en Windows PowerShell 5.1 sin sobrescribir el perfil existente.

  1. Inicie Windows PowerShell 5.1 con el perfil deshabilitado.

  2. Origen manual del archivo de perfil de PowerShell 7 en la sesión de Windows PowerShell 5.1.

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

  3. Observe si se produce el problema.

Si el problema persiste, entonces sabrás que es un problema ambiental fuera del perfil.

Pruebe a ejecutar el perfil en otro dispositivo. Si el perfil funciona correctamente en otro dispositivo, sabrá que el problema es específico del dispositivo original.

Solución de problemas comunes del entorno

Fallos al inicio

Si la consola de PowerShell se bloquea durante el inicio, especialmente temprano y sin comentarios, podría tener una caché de procesos dañada. Se trata de una condición poco frecuente que se puede resolver borrando la memoria caché. Hay dos ubicaciones de caché que se pueden borrar:

  • Caché de usuarios: $env:LOCALAPPDATA\Microsoft\Windows\Caches
  • Caché del sistema: $env:windir\System32\Config\SystemProfile\AppData\Local\Microsoft\Windows\Caches

Elimine primero el contenido de la carpeta de caché de usuarios y vuelva a intentar iniciar PowerShell. Si el problema persiste, elimine el contenido de la memoria caché del sistema e inténtelo de nuevo.

También puede que tenga que eliminar la memoria caché de análisis de PowerShell. Puede encontrar los archivos de caché en las siguientes ubicaciones:

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

Elimine solo los siguientes patrones de archivo:

  • ModuleAnalysisCache-*
  • StartupProfileData-*

Los datos almacenados en caché se vuelven a crear la próxima vez que inicie PowerShell.

Si el problema persiste en Windows PowerShell 5.1, es posible que tenga que reparar la instalación de .NET Framework. Para obtener más información, consulte Reparación de .NET Framework.

Soluciones a problemas comunes del perfil

En esta sección se describen algunos problemas comunes que pueden producirse durante el inicio de PowerShell y cómo solucionarlos.

El perfil tarda demasiado tiempo en ejecutarse

En primer lugar, debe definir lo que es "demasiado largo". PowerShell solo hace lo que los scripts le indican que haga. Compruebe todas las rutas de acceso del perfil. Es posible que se ejecuten varios scripts de perfil. Revise el código para entender que está intentando hacerlo.

  • Determinar dónde se produce el retraso

    Si hay scripts de perfil para el ámbito AllUsers , es posible que no pueda editar esos archivos. Trabaje con el administrador del sistema para revisar esos archivos. Para los scripts del perfil de ámbito CurrentUser, edite esos archivos para agregar mensajes de temporización que le ayuden a encontrar dónde se produce el retraso. Por ejemplo, puede agregar la siguiente línea en varios puntos del script de perfil.

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

  • Reducción de dependencias

    Reduzca el número de módulos que deben cargarse para ejecutar el perfil. Ejecute Get-Module después de que se ejecute el perfil para comprobar qué módulos se cargaron durante el inicio. De forma predeterminada, PowerShell carga los módulos Microsoft.PowerShell.Core y PSReadLine. Cualquier módulo adicional fue cargado por tus scripts de perfil.

    Los módulos se pueden cargar explícitamente mediante Import-Module o implícitamente mediante comandos definidos en esos módulos. Considere si necesita un comando o un módulo cargado durante el inicio.

  • Evitar la instalación de módulos en una carpeta redirigida

    En muchas situaciones en Windows, la Documents carpeta se puede redirigir a un recurso compartido de archivos de red o a OneDrive. El acceso a archivos de red puede ser lento, especialmente si la red está congesada o el servidor está bajo mucha carga. Dependiendo de cómo se configura OneDrive, también puede introducir retrasos o provocar errores durante la exectución del perfil.

    Tiene algunas opciones para mitigar este problema:

    • No redirija la carpeta Documents, aunque eso puede no ser lo deseado.
    • Configure la Modules carpeta en OneDrive para que siempre se mantenga en el disco. Esto evita errores y tiempos de carga retrasados.
    • Instale módulos en el ámbito AllUsers , que está fuera de la carpeta de perfiles de usuario.

  • Medición del rendimiento real

    Si no sabe cuánto tiempo tarda su perfil en ejecutarse, no puede evaluar si es demasiado largo. El Measure-Command cmdlet puede mostrar cuánto tiempo tarda un comando o bloque de script en ejecutarse.

    Steve Lee, el Administrador de desarrollo de PowerShell, tiene una entrada de blog que describe cómo medir el rendimiento de su perfil. Incluye instrucciones para establecer una línea base para el rendimiento, cómo obtener información detallada de tiempo y formas de optimizar el perfil. Consulte Optimizando su $Profile.

PowerShell 7 se inicia lentamente en una red aislada

En este escenario, el equipo Windows está en una red que no está conectada a Internet. Para sesiones interactivas de PowerShell, PowerShell carga automáticamente el módulo PSReadLine. PSReadLine es un módulo firmado. PowerShell debe comprobar la firma digital del módulo. Esta comprobación puede provocar retrasos en un entorno desconectado. Para probar esta teoría, inicie PowerShell 7 en modo no interactivo :

pwsh.exe -noninteractive

Si PowerShell se inicia rápidamente en modo no interactivo, es probable que el problema se deba a comprobaciones de lista de revocación de certificados (CRL). Como parte del proceso de comprobación de una firma digital, el entorno de ejecución de .NET comprueba la CRL para asegurarse de que el certificado de firma sigue siendo válido. En un entorno desconectado, el equipo no puede acceder a la CRL en Internet. El tiempo de espera predeterminado para las comprobaciones crL es de 15 segundos. Esto significa que cada vez que PowerShell carga un módulo firmado, puede tardar hasta 15 segundos en expirar.

Hay tres posibles soluciones alternativas para este problema:

  • Exención de firewall o proxy

    Permitir el acceso directo a Internet para la comprobación de CRL evita el problema. En un entorno en el que puede controlar el acceso a Internet, puede configurar el firewall o el proxy para permitir el acceso a las direcciones URL de CRL. Esta es la solución más sencilla con el menor impacto. Los registros de firewall deben mostrar la dirección URL a la que PowerShell intentó llegar.

  • Reducir el tiempo de espera de CRL

    Es posible reducir el tiempo de espera de búsqueda de CRL, pero, al hacerlo, se corre el riesgo de que se produzcan errores en otras búsquedas, que no se pueden completar en el tiempo especificado. Para obtener más información sobre cómo cambiar el tiempo de espera, consulte Administración de la recuperación de red y validación de rutas y acceso.

  • Eliminación de la comprobación de CRL

    La configuración de comprobación de CRL se administra mediante la directiva de grupo. Para obtener más información, consulte Administrar publicadores de confianza.

    Advertencia

    Es posible deshabilitar la comprobación de CRL; sin embargo, no se recomienda. Deshabilitar la comprobación de CRL impide que pueda revocar realmente los certificados comprometidos.

ERROR: No se puede dot-source este comando porque se definió en un modo de lenguaje diferente

PowerShell funciona con sistemas de control de aplicaciones, como AppLocker y Control de aplicaciones de Windows Defender (WDAC), mediante la ejecución automática en modo ConstrainedLanguage . El modo RestrictedLanguage restringe algunas características potencialmente peligrosas. Sin embargo, hay ocasiones en las que se necesita el modo FullLanguage para usar determinados comandos o características. Los scripts se pueden ejecutar en modo FullLanguage cuando son de confianza para la directiva. La confianza se puede indicar a través de la firma de archivos u otros mecanismos de directiva configurados en AppLocker o WDAC.

Al iniciar una sesión de PowerShell que se administra bajo el control de la aplicación, obtendrá el siguiente error:

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.

En el control de aplicaciones, PowerShell se ejecuta en modo ConstrainedLanguage . Este error se produce cuando tu script de perfil está exento o firmado para ejecutarse en el modo FullLanguage. Cuando PowerShell se ejecuta en modo ConstrainedLanguage , no se puede ejecutar código fuente de confianza para ejecutarse en modo FullLanguage .

Para resolver el problema, debe quitar la exención o firma del script de perfil. Si necesita código que se debe ejecutar en modo FullLanguage durante el uso de su perfil, muévalo a otro archivo de script exento o firmado. Llame a ese archivo de script desde el perfil sin utilizar la técnica de "dot-sourcing".

Para obtener más información sobre este problema, vea Modo de lenguaje restringido de PowerShell y el operador Dot-Source.

Lectura adicional

  • Last updated on