La consola de PowerShell puede dejar de abrirse en Windows Server 2019 justo cuando más se necesita, cerrándose en un parpadeo y mostrando el temido HRESULT 0x80070005. Este artículo explica paso a paso por qué ocurre y cómo restaurar el motor de automatización sin reinstalar el sistema.

Síntomas observables en el servidor

Al iniciar sesión en una instancia de Windows Server 2019 Datacenter (compilación 17763.5576) y lanzar PowerShell —desde el acceso directo, el menú contextual o una sesión RunAs— la ventana azul aparece unos milisegundos y se esfuma sin registrar nada en el Visor de eventos. Ejecutar powershell.exe desde la consola CMD revela un mensaje adicional:

Starting the CLR failed with HRESULT 80070005

Algunos administradores, al no encontrar log alguno, prueban a eliminar la característica “Windows PowerShell 5.1” desde Agregar o quitar roles y características, pero el asistente muestra que es un componente fundamental que no puede desinstalarse. Tampoco DISM /Online /Cleanup-Image /RestoreHealth ni sfc /scannow parecen surtir efecto: PowerShell sigue sin arrancar.

Interpretación de HRESULT 0x80070005

El valor 0x80070005 equivale al error de Win32 ERRORACCESSDENIED. Cuando lo devuelve el CLR (Common Language Runtime), indica que el cargador no pudo mapear un ensamblado o asignar memoria protegida. Las causas más frecuentes son:

• Permisos restringidos en la rama de registro HKLM\SOFTWARE\Microsoft\.NETFramework o en los archivos de %SystemRoot%\Microsoft.NET.
• Políticas de AppLocker o un antivirus que bloquean just‑in‑time la DLL clr.dll o el proceso powershell.exe.
• Corrupción de bibliotecas del CLR tras una actualización fallida de .NET Framework.
• Variables de entorno COMPlus_* mal establecidas (experimentos de debugging olvidados).

Flujo de diagnóstico recomendado

Antes de avanzar con una reinstalación de software es conveniente agotar las pruebas de diagnóstico, porque la raíz puede ser simplemente un bloqueo antivirus o un permiso cambiado:

Prueba	Comando o acción	Resultado esperado
Ejecución elevada	Clic derecho → Ejecutar como administrador	Si PowerShell abre, era un ACL en perfil de usuario
Integridad de archivos	sfc /scannow	“No se encontraron violaciones de integridad”
Estado de imagen	DISM /Online /Cleanup-Image /RestoreHealth	Restauración completada correctamente
Variables CLR	set COMPlus	No se devuelve ninguna variable inesperada
Permisos en .NET	icacls "%SystemRoot%\Microsoft.NET" /T	Sistema y Administradores con Control total

Razón técnica: dependencia de PowerShell 5.x en .NET Framework

PowerShell 5.1, la versión integrada en Windows Server 2019, se construyó sobre .NET Framework 4.x. Esto significa que cualquier corrupción en el CLR clásico repercute directamente en la capacidad de iniciarse. Por el contrario, la línea moderna PowerShell 7 (anteriormente “PowerShell Core”) emplea .NET Runtime Core (ahora simplementes .NET) y carga sus conjuntos independientes en C:\Program Files\PowerShell\7\, ajenos al CLR afectado.

Solución principal: reinstalar .NET Framework 4.8 Runtime

Reparar la infraestructura CLR suele devolver la funcionalidad sin necesidad de tocar el rol PowerShell. Los pasos se dividen en desinstalar y reinstalar:

Desinstalar completamente la versión actual

1. Abrir Panel de control → Programas y características → Ver actualizaciones instaladas.
2. Ordenar por Nombre y localizar Actualización de .NET Framework 4.x.
3. Desinstalar todas las entradas que incluyan “.NET Framework 4.x” o “KB…. for .NET Framework 4.x”.
4. Reiniciar el servidor cuando lo solicite el asistente.
5. Validar que %SystemRoot%\Microsoft.NET\Framework64\v4.0.30319 quedó con sólo los archivos de sistema base. No bórralos manualmente: basta con la desinstalación controlada.

Instalar .NET Framework 4.8 Runtime

1. Descargar el instalador independiente ndp48-x86-x64-allos-enu.exe desde el portal oficial de Microsoft (sin hipervínculo por política interna).
2. Copiar el ejecutable a una carpeta local del servidor —o a un recurso compartido accesible— y ejecutarlo.
3. Aceptar términos y esperar la recopilación de estado. El instalador reemplazará archivos del CLR y volverá a registrar runtimes y GAC.
4. Al finalizar, pulsar Restart now.
5. Tras el reinicio, abrir una consola cmd y lanzar: powershell -Command "$PSVersionTable" Si el comando devuelve la tabla con CLRVersion 4.0.30319 y PSVersion 5.1.x, el motor está reparado.

Opción provisional: instalar PowerShell 7

Mientras se diagnostica la avería del CLR, puede mantenerse la productividad con PowerShell 7, que no depende de .NET Framework 4.x:

winget install --id Microsoft.PowerShell --source winget

En servidores sin acceso a Store, descargue el MSI de PowerShell 7 desde Microsoft Learn y ejecútelo con msiexec /i PowerShell-7.x.x-win‑x64.msi /quiet /norestart. Tras la instalación:

• Use el comando pwsh (sin “e”) para abrir la nueva consola.
• La versión 7 puede coexistir con 5.1 sin conflictos de perfiles.
• Los módulos de Windows (ActiveDirectory, Hyper‑V, etc.) se importan con compatibilidad implicit remoting:
  Import-Module ActiveDirectory -UseWindowsPowerShell

Control de daño y prevención

Una vez reestablecido PowerShell conviene evitar que el problema resurja:

• Parcheo regular: incluya actualizaciones acumulativas mensuales que traen hotfixes para .NET.
• Antivirus corporativo: agregue excepciones parapowershell.exe, pwsh.exe, clr.dll y la carpeta %windir%\Microsoft.NET.
• Copia de seguridad de ACL: exporte permisos del registro y del directorio .NET antes de aplicar plantillas GPO agresivas.
• Supervisión proactiva: habilite Fusion Log sólo cuando diagnostique; mantenerlo indefinidamente degrada rendimiento y llena disco.

Cómo usar Fusion Log y ProcMon para aislar ACCESS DENIED

Si el error reapareciera y los pasos anteriores no funcionaran, active el registro detallado de carga de ensamblados:

1. Crear HKLM\SOFTWARE\Microsoft\Fusion.
2. Dentro, añadir DWORD EnableLog = 1 y LogFailures = 1.
3. Recrear la avería. Se generará un archivo fuslogvw.exe donde se enumeran las rutas de búsqueda de ensamblados y qué pasos fallan.
4. Deshabilitar la clave tras la captura para no dejar rastro permanente.

ProcMon, por su parte, permite ver puntualmente qué proceso recibió ACCESS DENIED al intentar abrir clr.dll u otro recurso. Filtros sugeridos:

Process Name is powershell.exe
Result is ACCESS DENIED

La traza mostrará el objeto, la ruta y la regla de seguridad que impidió la lectura, facilitando el ajuste del permiso o la excepción en el antivirus.

Conclusión práctica

Reinstalar .NET Framework 4.8 es, en la gran mayoría de casos, el remedio definitivo al fallo “Starting the CLR failed with HRESULT 80070005” en Windows Server 2019. El proceso es rápido, reversible y no compromete otras cargas de trabajo. Para quienes necesitan continuidad del servicio, PowerShell 7 ofrece un entorno de automatización moderno, multiplataforma y libre de dependencias en el CLR clásico. Implementar ambas soluciones —reparación del runtime y adopción de PowerShell 7— deja al servidor protegido frente a futuras corruptelas y al equipo de TI con herramientas actualizadas.