Come risolvere l'errore Dependency Service su Windows VPS -- TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster

1 1 visite 04/05/2026 Pubblicato il: 04/05/2026 08:00 Tempo di lettura: 10 min

Il messaggio Dependency Service su una Windows VPS non indica quasi mai un singolo guasto. Di solito è l’effetto finale di un servizio che non parte perché una dipendenza è ferma, un account non ha più i permessi giusti, la rete non sale come previsto o una policy ha rotto l’avvio automatico. La regola utile è questa: non partire dal servizio che “si vede” in errore, ma dal suo grafo di dipendenze e dallo stato reale della macchina.

In pratica, prima si verifica qual è il layer rotto — rete, storage, Service Control Manager, account, applicazione — e solo dopo si interviene. Su VPS Windows il problema può essere banale, come una scheda virtuale senza DHCP, oppure più sporco, come una dipendenza disabilitata dopo un update o un restore. Se tocchi servizi e registry senza un ordine, rischi di allargare il danno e rendere il rollback più complicato.

Come leggere davvero l’errore Dependency Service

La dicitura completa cambia, ma il significato operativo è simile: il servizio richiesto non può avviarsi perché uno dei componenti da cui dipende è indisponibile. Non confondere il sintomo con la causa. Un esempio tipico è un sito o un’app che non risponde perché W3SVC, RPC, DHCP Client o un database locale non sono in stato Running. In altri casi il servizio parte ma fallisce subito perché gira con un account che non ha più il diritto Log on as a service.

Se hai accesso alla VPS, la prima domanda è semplice: il servizio è fermo per una dipendenza mancante o per un errore interno? La differenza cambia completamente il percorso. Il primo caso si risolve spesso in pochi minuti; il secondo richiede log, Event Viewer e verifica della configurazione applicativa.

Diagnosi iniziale: il layer giusto prima di toccare qualcosa

Lavora in quest’ordine: servizi di base → rete → servizio applicativo → log evento. È il modo più rapido per evitare modifiche inutili.

Verifica lo stato del servizio che fallisce.
```
sc query nome_servizio
```
Atteso: STATE diverso da STOPPED se la macchina è sana. Se vedi STOPPED o errori di start, prendi nota del WIN32_EXIT_CODE.
Controlla le dipendenze dichiarate.
```
sc qc nome_servizio
```
Atteso: elenco di DEPENDENCIES coerente. Se manca un servizio chiave o è stato disabilitato, hai già una causa candidata.
Apri Event Viewer e cerca gli eventi del Service Control Manager.
```
eventvwr.msc
```
Guarda Windows Logs > System e filtra per Service Control Manager. Eventi come 7000, 7001, 7009 e 7031 sono spesso la traccia giusta.
Verifica la rete base se il servizio dipende da connettività o licenze remote.
```
ipconfig /all
ping 127.0.0.1
ping gateway_ip
nslookup nomehost
```
Atteso: IP corretto, gateway raggiungibile, DNS risolutivo coerente. Se la rete è rotta, molti servizi “falliscono per dipendenza” anche se il problema vero è altrove.

Se il servizio riguarda web, mail o database, controlla anche il log applicativo. I percorsi cambiano, ma spesso trovi indizi in C:\Windows\System32\Winevt\Logs\ per eventi, oppure nei log dell’app sotto C:\inetpub\logs\, C:\Program Files\ o nella directory dati del software. Non inventare il percorso: se non lo conosci, usa il pannello del prodotto o la documentazione del vendor.

Cause più comuni su Windows VPS

Le cause reali che vedo più spesso su VPS Windows sono poche, ma ricorrono con regolarità. Ordinale così: dipendenza ferma, account o permessi rotti, configurazione corrotta o parziale. La rete virtuale e il disco pieno sono i due falsi amici più frequenti: sembrano problemi “di sistema”, ma si riflettono subito su servizi che non si alzano.

Dipendenza disabilitata o arrestata. Un update, un hardening o un restore può aver fermato un servizio base. Su Windows, se un servizio richiesto è in stato Disabled, il servizio figlio non partirà mai.
Account del servizio cambiato o password scaduta. Succede spesso dopo manutenzione manuale o rotazione non coordinata. Il servizio sembra “dipendente”, ma in realtà non riesce a fare logon.
Configurazione corrotta. Un file di config incompleto, un binding sbagliato, una porta occupata o un registro alterato possono bloccare il servizio e far apparire un errore generico di dipendenza.
Rete o DNS locali non pronti. Se il servizio deve contattare un endpoint interno, una domain controller o un backend remoto all’avvio, un problema DNS o route lo fa fallire in catena.
Disco pieno o permessi su path dati. Il servizio non scrive file temporanei, socket o database locali e si ferma con messaggi poco chiari.

Verifiche rapide che falsificano le ipotesi in pochi minuti

Qui l’obiettivo non è “fare troubleshooting in eterno”, ma tagliare il campo. Ogni test deve dirti subito se la pista è buona o no.

La dipendenza è davvero su
```
sc query nome_dipendenza
```
Se è RUNNING, questa pista perde peso. Se è STOPPED o DISABLED, hai una causa concreta.
Il servizio ha permessi corretti
```
services.msc
```
Apri le proprietà del servizio, controlla la scheda Log On. Se usa un account dedicato, verifica credenziali e diritti locali. Se hai accesso amministrativo, puoi confrontare con un servizio simile funzionante.
Il sistema non è saturo
```
wmic logicaldisk get caption,freespace,size
systeminfo | findstr /C:"Available Physical Memory"
```
Disco quasi pieno o memoria libera molto bassa possono impedire l’avvio. Se lo spazio libero è sotto la soglia operativa del tuo servizio, fermati prima di fare altro.
Il canale eventi mostra il punto esatto
```
wevtutil qe System /q:"*[System[(Provider[@Name='Service Control Manager'])]]" /f:text /c:10
```
Se gli ultimi eventi parlano di timeout, access denied o servizio non trovato, sei già vicino alla causa.

Soluzione consigliata passo-passo

La correzione va fatta con criterio reversibile. Prima riporti in vita la catena minima, poi sistemi la causa a monte. Se il servizio è in produzione, considera il blast radius: un riavvio di dipendenze può impattare più applicazioni di quanto sembri.

Salva lo stato attuale prima di cambiare qualcosa
```
sc qc nome_servizio > C:	emp
sc query nome_servizio >> C:	empackup_servizio.txt
```
Se devi toccare registry o configurazioni, esporta il ramo interessato con reg export prima della modifica. Se non sai quale ramo, non procedere alla cieca.
Riattiva la dipendenza ferma
```
sc start nome_dipendenza
```
Se parte, rilancia il servizio principale. Se fallisce, il messaggio di errore della dipendenza è quello che conta davvero.
Correggi il tipo di avvio
```
sc config nome_dipendenza start= auto
```
Attenzione allo spazio dopo start=: su sc è obbligatorio. Usa questa modifica solo se la dipendenza deve essere persistente e la policy del sistema lo consente.
Ripristina l’account del servizio
```
services.msc
```
Se l’account è cambiato, reimposta credenziali corrette e verifica il diritto Log on as a service. Dopo la modifica, prova l’avvio manuale. Se hai GPO o hardening, controlla che non stiano riscrivendo il diritto a ogni refresh di policy.
Controlla porta e binding
```
netstat -ano | findstr :porta
```
Se la porta è già occupata, il servizio può fallire con un errore che sembra di dipendenza. In quel caso identifica il PID, risali al processo e valuta se c’è conflitto applicativo o un vecchio processo zombie.
Ripara la configurazione dell’app

Se il prodotto ha un file di config, confrontalo con un backup noto buono. Per IIS, guarda i binding del sito; per database, controlla il servizio e il path dati; per agent o middleware, verifica il file di configurazione e le credenziali verso backend esterni.
Riavvia solo ciò che serve
```
Restart-Service nome_servizio
```
Se la piattaforma lo consente, evita reboot completi finché non hai identificato la causa. Il riavvio totale è una mitigazione, non una diagnosi.

Se il problema è legato a Windows Update o a un ripristino, verifica anche se il servizio dipende da componenti di sistema alterati. In quel caso il rollback più pulito è spesso un ripristino della configurazione precedente o una correzione del servizio specifico, non una reinstallazione aggressiva.

Quando il problema è davvero di rete o DNS

Su VPS Windows la rete virtuale è spesso sottovalutata. Un servizio che dipende da dominio, licensing server, repository interni o endpoint HTTPS può fallire se il DNS non risolve o se la route verso il backend non è pronta all’avvio. In questi casi il messaggio “dependency service” è secondario: il servizio figlio aspetta qualcosa che non arriva.

Verifica i DNS configurati.
```
ipconfig /all
```
Atteso: server DNS corretti e coerenti con il tuo ambiente. Se vedi DNS pubblici dove dovresti avere un resolver interno, hai trovato un problema concreto.
Controlla la risoluzione del nome usato dal servizio.
```
nslookup nome_backend
```
Se la risposta è errata o manca, il servizio che dipende da quel nome può fallire all’avvio.
Verifica connettività verso la porta richiesta.
```
Test-NetConnection nome_backend -Port 443
```
Se TcpTestSucceeded è False, il problema non è il servizio locale ma la raggiungibilità del dipendente remoto.

Se il servizio è IIS, SQL Server o un agent simile

Su ruoli noti, conviene ragionare per prodotto. IIS, SQL Server, agent di backup, antivirus e software di monitoraggio hanno dipendenze e log molto diversi. Non serve reinventare il troubleshooting, ma serve guardare nel posto giusto.

Per IIS, controlla W3SVC, WAS e i binding del sito. Un certificato scaduto o un binding duplicato può far sembrare che il problema sia “di dipendenza”, mentre il servizio web non riesce a inizializzarsi. Per SQL Server, la dipendenza può essere il servizio engine o un account di servizio con permessi sui file MDF/LDF. Per un agent, la causa è spesso la perdita del token o del path di lavoro.

Quando possibile, usa il pannello del prodotto per validare lo stato, perché spesso espone più contesto del semplice Service Control Manager. La CLI resta utile per confermare il sintomo e automatizzare il check, ma l’applicazione a volte scrive il motivo vero solo nel suo log interno.

Rollback e blast radius: cosa non dimenticare

Ogni modifica a servizi, account o registry su una VPS ha un blast radius reale: può impattare più siti, più applicazioni o più tenant se la macchina è condivisa. Prima di cambiare start type, credenziali o configurazioni, prepara sempre un rollback semplice.

Se hai cambiato un servizio, annota il valore precedente di start type e dell’account usato.
Se hai modificato registry o config, conserva il file originale con timestamp.
Se hai riattivato dipendenze, verifica che la modifica non venga annullata da GPO, script di startup o tool di gestione centralizzata.
Se il servizio non riparte dopo la correzione, torna al punto precedente invece di accumulare altre modifiche.

Rollback pratico: ripristina il file o il valore esportato, riporta il servizio allo stato precedente e riconferma con sc query e Event Viewer. Se il problema era una corruzione temporanea e il sistema è tornato stabile, fermati lì. Se invece l’errore riappare, hai un difetto strutturale da cercare nei log o nella configurazione gestita centralmente.

Checklist operativa da tenere a portata di mano

Questa sequenza è quella che uso quando devo chiudere in fretta un caso “Dependency Service” su Windows VPS senza fare danni collaterali.

Identifica il servizio preciso e le sue dipendenze con sc qc.
Controlla lo stato delle dipendenze con sc query.
Leggi gli eventi del Service Control Manager in eventvwr.msc.
Verifica rete, DNS e porte con ipconfig /all, nslookup e Test-NetConnection.
Controlla account del servizio, permessi e spazio disco.
Applica una sola correzione alla volta e rilancia il servizio.
Se risolto, documenta la causa e il rollback usato.

Assunzione operativa: la VPS è in produzione o comunque da trattare come tale finché non dimostri il contrario; per questo ogni modifica va fatta in modo reversibile e con verifica immediata dopo il cambio.