Come risolvere PowerShell che non funziona su Windows

Quando PowerShell “non funziona” su Windows, il problema raramente è PowerShell in sé: di solito c’è di mezzo il punto di avvio, il profilo utente, una policy di esecuzione, il PATH, un file di sistema corrotto, oppure un blocco introdotto da hardening, antivirus o aggiornamenti andati male. La prima cosa da fare non è reinstallare tutto, ma capire quale layer si è rotto: avvio dell’eseguibile, apertura della console, caricamento del profilo, esecuzione degli script, oppure funzionamento di comandi specifici.

La distinzione conta perché “PowerShell non si apre” e “PowerShell si apre ma non esegue script” sono due incidenti diversi, con cause e rimedi diversi. Nel primo caso si lavora su collegamenti, binari, registro e dipendenze di sistema. Nel secondo si lavora su execution policy, profilo, moduli, permessi e restrizioni di sicurezza. Se si salta questa separazione, si finisce facilmente a fare modifiche inutili che allargano il blast radius senza risolvere nulla.

Il sintomo va letto per livello, non per nome del programma

Il modo più rapido per orientarsi è classificare il guasto in uno di questi casi:

• l’applicazione non parte proprio;
• la finestra si apre e si chiude subito;
• si apre ma alcuni comandi falliscono;
• gli script locali non partono, ma i comandi manuali sì;
• funziona in un account ma non in un altro.

Se il problema riguarda solo un account, la probabilità sale su profilo utente, policy locale o variabili d’ambiente. Se riguarda tutti gli utenti, si guarda prima a file di sistema, aggiornamenti, antivirus, AppLocker/WDAC o a una modifica lato immagine di sistema.

Diagnosi rapida: cosa verificare prima di toccare la macchina

Prima di cambiare configurazioni, raccogli evidenza minima. Se PowerShell non si avvia, prova a lanciare direttamente l’eseguibile e osserva l’errore. Su Windows recenti conviene verificare sia Windows PowerShell sia PowerShell 7, perché possono coesistere e fallire in modo indipendente.

Apri Esegui o un prompt dei comandi e prova:

powershell -NoLogo -NoProfile -Command "$PSVersionTable.PSVersion"
where powershell
where pwsh

Interpretazione pratica:

• se where powershell non trova nulla, il problema è nel PATH o nell’installazione;
• se powershell -NoProfile parte ma l’avvio normale no, il colpevole è spesso il profilo utente;
• se pwsh funziona ma powershell no, il problema è circoscritto a Windows PowerShell 5.1 o al suo binario;
• se entrambi falliscono con errori di accesso o blocco, guardare policy di sicurezza, antivirus o componenti di sistema.

Se l’errore è una finestra che compare e sparisce, lancia PowerShell da un prompt già aperto. In questo modo l’output resta visibile e si evita di inseguire un crash “muto”.

Ipotesi ordinate per probabilità

1) Profilo PowerShell corrotto o script di avvio problematico. È la causa più comune quando PowerShell parte con -NoProfile ma non normalmente. La falsifichi in pochi minuti avviando:

powershell -NoLogo -NoProfile

Se così funziona, il problema sta in $PROFILE o in uno script richiamato dal profilo. Il file tipico è sotto %UserProfile%\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 per Windows PowerShell e sotto %UserProfile%\Documents\PowerShell\Microsoft.PowerShell_profile.ps1 per PowerShell 7.

2) Execution policy o restrizioni di sicurezza. Se gli script falliscono ma i comandi interattivi no, la policy può bloccare l’esecuzione. La falsifichi con:

Get-ExecutionPolicy -List
Get-ItemProperty -Path HKCU:\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell

Se compare Restricted, AllSigned o una policy forzata da MachinePolicy/UserPolicy, il blocco è verosimile. Se invece la policy è permissiva, il problema va cercato altrove.

3) Corruzione del binario, dipendenze mancanti o hardening lato sistema. Se PowerShell non parte nemmeno con -NoProfile e l’errore è immediato, controlla Event Viewer, integrità dei file di sistema e eventuali blocchi da AppLocker/WDAC o antivirus. La falsificazione più rapida è verificare se altri utenti sulla stessa macchina hanno lo stesso guasto e se il binario esiste nel percorso standard.

Verifiche immediate che danno risposta utile

Le verifiche sotto sono poco invasive e ti dicono subito dove intervenire.

1. Controlla il percorso del binario: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe per Windows PowerShell e il percorso di installazione di PowerShell 7, se presente.
2. Esegui la shell senza profilo: powershell -NoLogo -NoProfile. Se parte, il problema è quasi certamente nel profilo o in un modulo caricato all’avvio.
3. Verifica la policy: Get-ExecutionPolicy -List. Se c’è una policy di dominio, non ha senso forzare modifiche locali senza capire chi la impone.
4. Controlla i log applicativi e di sicurezza in Event Viewer: cerca errori al momento del tentativo di avvio, blocchi di script o crash del processo.
5. Se il problema è solo sugli script, prova un file minimale firmato o un file di test locale per capire se il blocco è di policy o del contenuto.

Comandi utili per la verifica:

Get-ExecutionPolicy -List
Test-Path $PROFILE
Get-Content $PROFILE -ErrorAction SilentlyContinue
Get-ChildItem Env:PATH

Se $PROFILE esiste e contiene moduli, importazioni, alias o funzioni personalizzate, commenta temporaneamente le righe una per una. L’obiettivo è trovare il punto di rottura senza cancellare nulla. Se c’è un modulo terzo che si carica all’avvio, è spesso lui a introdurre il problema.

Soluzione consigliata passo-passo

La sequenza sotto privilegia azioni reversibili. Prima si isola il componente, poi si corregge, solo dopo si consolida.

1. Avvio pulito. Prova powershell -NoLogo -NoProfile. Se funziona, rinomina temporaneamente il profilo utente invece di modificarlo in blocco. Per esempio, sposta Microsoft.PowerShell_profile.ps1 in .bak. Questo ha blast radius limitato e rollback immediato.
2. Ripristino del profilo in modo incrementale. Riattiva il contenuto del profilo per blocchi piccoli. Se il problema ricompare dopo un Import-Module, hai trovato il punto debole. In quel caso verifica la versione del modulo e la sua compatibilità con la shell installata.
3. Verifica e correzione della policy. Se Get-ExecutionPolicy -List mostra una policy troppo restrittiva ma non imposta da dominio, puoi valutare una modifica mirata per l’utente corrente:

Set-ExecutionPolicy -Scope CurrentUser RemoteSigned

Prima di applicarla, verifica il contesto: su macchine gestite da GPO, la modifica locale può essere inutile o temporanea. Il rollback è semplice:

Set-ExecutionPolicy -Scope CurrentUser Undefined

1. Controllo integrità di sistema. Se l’eseguibile non parte o si comporta in modo anomalo anche con profilo disattivato, esegui controlli sui file di sistema. Questo non è un fix “magico”, ma serve a capire se il danno è più profondo:

sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth

Qui il rischio operativo è basso, ma serve tempo. Se il sistema è in produzione o sotto vincoli stretti, valuta la finestra di manutenzione prima di procedere.

1. Verifica di blocchi esterni. Se il problema persiste, controlla AppLocker, WDAC, Defender for Endpoint, AV terzi o altre policy di hardening. Un blocco esterno spesso lascia tracce chiare nei log di sicurezza o nei registri applicativi al momento del tentativo di avvio.
2. Reinstallazione solo come ultima opzione mirata. Se hai confermato che il binario è danneggiato o mancante, reinstalla la versione interessata invece di “ripulire” tutto il sistema. Su PowerShell 7 conviene usare il pacchetto ufficiale o il gestore software adottato dall’organizzazione; su Windows PowerShell 5.1 il recupero passa di solito dai componenti di sistema e dagli aggiornamenti Windows.

Se stai lavorando su una macchina con più utenti, fai attenzione al blast radius: toccare policy o profili globali può impattare account che al momento funzionano. La strategia corretta è isolare il problema per utente e per versione della shell, poi estendere la correzione solo se confermata.

Casi tipici e come riconoscerli al volo

Finestra che si chiude subito. Spesso è un errore nel profilo o in un comando di startup. La prova più rapida è powershell -NoProfile. Se parte, non serve andare oltre con il binario.

Script bloccato con messaggio sulla policy. Qui il problema non è la shell ma la regola di esecuzione. Get-ExecutionPolicy -List dice subito se la restrizione è locale o imposta centralmente.

Comandi sconosciuti o moduli mancanti. Se PowerShell è vivo ma alcuni cmdlet non esistono, non stai vedendo un guasto della shell: manca il modulo o non è nel path di moduli. Controlla Get-Module -ListAvailable e la compatibilità della versione.

Errore solo per un utente. Qui la prima pista è il profilo, poi il PATH utente, poi eventuali variabili d’ambiente o policy per singolo account. Non partire dal sistema intero: perderesti tempo e allargheresti l’intervento inutilmente.

Controlli finali e rollback

Dopo ogni correzione, verifica sempre tre cose: apertura della shell, esecuzione di un comando banale, esecuzione del caso d’uso reale che prima falliva. Un test minimo valido è:

powershell -NoLogo -NoProfile -Command "$PSVersionTable.PSVersion"
powershell -Command "Get-Date"

Se il problema era nel profilo, il rollback consiste nel ripristinare il file originale dal backup o nel riattivare le righe una alla volta fino a identificare quella rotta. Se il problema era in una policy locale appena cambiata, torna allo stato precedente con Undefined per lo scope modificato o con il valore iniziale documentato prima dell’intervento.

Se hai eseguito sfc o DISM, controlla anche che non ci siano errori residui in Event Viewer e che il binario risponda con la versione attesa. In caso di reinstallazione di PowerShell 7, conserva il pacchetto usato e la versione precedente: il rollback deve essere rapido, non una caccia al download.

Assunzione operativa: il sistema è Windows recente, la shell in questione può essere Windows PowerShell 5.1 o PowerShell 7, e il guasto va trattato come incidente utente fino a prova contraria.