Windows: l’invasione dei CBSPersist e dei cab_ (C:\Windows\Temp)

Gioxx  —  21/12/2016 — 22 Comments

È un problema che ho affrontato qualche tempo fa e che inizialmente mi ha dato un po’ di grattacapi, salvo poi trovare casi molti simili che mi hanno aiutato a risolvere l’anomalia. Il disco di un PC si satura e la colpa è della cartella C:\Windows\Temp, invasa da file senza estensione, dal nome che comincia sempre per cab_. Perché accade? Il problema viene generato da una installazione di alcuni aggiornamenti (da Windows Update) evidentemente non andata a buon fine, non del tutto almeno, nonostante la schermata preposta di Microsoft dica che tutto va bene.

Windows: l'invasione dei CBSPersist e dei cab_ (C:WindowsTemp)

Facendo un po’ più di attenzione, si scopre che in realtà di cartella che occupa spazio ce n’è un’altra. Teoricamente dovresti trovare anomala anche la C:\Windows\Logs\CBS, all’interno della quale dovresti trovare dei file CAB veri, e un file di log dalla dimensione decisamente robusta (CBS.log). L’anomalia parte proprio da qui. Partiamo con le opportune presentazioni (recuperate con una semplice ricerca):

CBS stands for “Component-Based Servicing” and it basically is the way components get installed and uninstalled during updates. It is the reason you see “Stage 1”, “Stage 2”, and “Stage 3” during the Service Pack 1 install (for example). “Stage 2” and “Stage 3” exists for the registry keys and files that are normally locked during regular operation.

Tutto chiaro? Un log in cui ogni aggiornamento di Microsoft va a scrivere e tiene traccia di ogni movimento. Un log destinato –per forza– a crescere, e che per un comportamento assolutamente standard va a ruotare, sospendendo la scrittura, finendo in un CAB che ne riduce (di parecchio) la dimensione, e infine ne prepara uno nuovo in cui tornare a scrivere, per poi ricominciare il giro ancora e ancora.

Se per qualsivoglia motivo questo procedimento non fila liscio, il CBS.log diventa più grande del previsto, ingestibile e –soprattutto– impossibile da mettere in un CAB nei tempi previsti. Il risultato? Cartella Temp di Windows piena di tentativi falliti di comprimere quel log, cartella CBS che si ingigantisce.

Diverse le fonti dove ho trovati informazioni in merito e persone capitate nello stesso vortice, ne ho selezionate tre che mi hanno aiutato:

Riepilogando, tutto questo può accadere in qualsiasi momento e -in base alla capacità del disco e lo spazio libero da poter sfruttare- potresti accorgertene a mesi (o forse anni) di distanza. Io ho scoperto di essere soggetto al problema solo perché un utente ha lamentato poco spazio libero e mi ha fatto scoprire l’anomalia. Le operazioni da affrontare per resettare il procedimento di scrittura e archiviazione del CBS.log è questo:

  • Fermare il servizio Windows Update.
  • Rinominare la cartella della Software Distribution (C:\Windows\SoftwareDistribution).
  • Cancellare ogni file in C:\Windows\Temp (ovviamente ignorando quelli in uso e che faranno comparire il classico errore a video di impossibilità di cancellazione, nda).
  • Riavviare il servizio di Windows Update.
  • Cancellare ora la cartella SoftwareDistribution precedentemente rinominata, non serve più, Windows Update provvederà a crearne una nuova in totale autonomia (dovrebbe già averlo fatto in fase di avvio del servizio, come da passaggio precedente).
  • Fermare il servizio Trusted Installer.
  • Cancellare ogni file in C:\Windows\Logs\CBS.
  • Riavviare il servizio Trusted Installer.
  • Forzare una ricerca aggiornamenti di Windows Update (direttamente via prompt).

Visto che questa cosa potrebbe capitare ad altri client in futuro, ho pensato di tradurla in codice batch, da dare in pasto anche al Kace di Dell (tanto per fare un esempio). Il tutto intervallando alcuni secondi di pausa prima di poter eseguire l’operazione successiva (dando così modo al client di non saltare alcun passaggio fondamentale):

sc stop wuauserv
ping 127.0.0.1 -n 7 > NUL
cd \Windows\
move SoftwareDistribution SoftwareDistribution_old
del /S C:\Windows\Temp\* /Q
FOR /D %%p IN ("C:\Windows\Temp\*.*") DO rmdir "%%p" /s /q
sc start wuauserv
rd /S /Q C:\Windows\SoftwareDistribution_old
sc stop TrustedInstaller
ping 127.0.0.1 -n 7 > NUL
del /S C:\Windows\Logs\CBS* /Q
sc start TrustedInstaller
ping 127.0.0.1 -n 5 > NUL
wuauclt.exe /detectnow

Così facendo ho risolto il problema e liberato spazio sul disco. Ho fatto queste modifiche al sistema mesi fa e il problema non si è più presentato (a me, ma anche ad altri utenti che nel frattempo ho rilevato nella nostra rete).

Facile (soprattutto se si ha un aiuto nella software distribution) fare un’analisi all’interno della rete aziendale e cercare le macchine che soffrono la stessa anomalia ma che ancora non hanno saturato il disco, basterà cercare nella cartella C:\Windows\Temp una forte presenza di cab_, così da portarsi avanti ed evitare che il problema si presenti agli occhi dell’utente.

Estote parati (cit.).

G

Update

Ho aggiunto il passaggio relativo alla cancellazione della cartella SoftwareDistribution rinominata (nella lista delle operazioni manuali da compiere), come da commento di GDB, che ringrazio per avermelo fatto notare.

ATTENZIONE: Questo post è stato scritto più di 5 mesi fa, potrebbe non essere aggiornato. Per qualsiasi dubbio ti invito a lasciare un commento per chiedere ulteriori informazioni! :)

Condividi l'articolo con i tuoi contatti:
  • Grazie delle dritte, dello script e della copiosa spiegazione.

    Per curiosità ho dato un occhiata alle cartelle del mio piccolo NAS casalingo gestito per forza di cose (aka miei figli…) da Win7 e non ho trovato nulla di strano ma il tutto tornerà sicuramente utile prima o poi.

    Articolo salvato e condiviso :)

  • In realtà spero che tu possa dimenticarti di questo articolo, per il semplice motivo che corrisponderebbe al non essere soggetto all’anomalia! :-)

    Per l’edit: ho volutamente messo questo titolo per una buona ricercabilità sul web. Quando ho notato l’invasione di questo tipo di file, ho cercato in giro e ho faticato a trovare qualcuno che andasse al punto (cioè il fatto di avere file di tipo cab_* in C:WindowsTemp) ;-)

  • GDB

    grazie! Ti chiedo un chiarimento.
    dopo aver rinominato la cartella software distribution non devo preoccuparmi al termine dei passaggi di ripristinare il nome?

  • Ciao, puoi addirittura cancellarla quella cartella rinominata. Windows Update provvederà a crearla da zero, scaricando qui gli aggiornamenti di cui ha bisogno in futuro. Nel file batch ho inserito questo passaggio, nella lista manuale no, rimedio subito :-)

  • GDB

    Grazie

  • Figurati :-)

  • Cita Vecchia

    Nel mio caso avrei titolato: “Come recuperare 4,8 Giga di spazio dal tuo ssd”
    Grazie Infinite per l’esaustivo ed utilissimo articolo!

  • Grazie a te per averlo letto e commentato! :-)

  • Fabiano

    Non ho liberato tanto spazio con il file batch, 75 GB hahahahahahhah
    Grazie

  • Beh, si dai, non è poi molto ;-) :-D

  • alxbrb

    Più leggo di bug (o planned features) come queste, più divento progressivamente consapevole di come l’architettura di questo sistema operativo e di moltissime delle sue pacchettizzazioni accessorie siano un insulto al concetto di essere umano pensante.

    Nemmeno un caching degli aggiornamenti decente ad eoni dal rilascio e su più distribuzioni. Nemmeno questo.

  • Sulla scoperta mi trovi alquanto d’accordo, non è stato semplice documentarmi quando è capitato a me (quindi prima di scrivere questo pezzo), ma quando ho scoperto quel log ci sono rimasto male pure io, mal comune mezzo gaudio? (anche se qui da ridere c’è ben poco!) :-)

  • alxbrb

    M$ as evah… :D

    WSUS (a meno che non sia gestito in un cluster a fondo perduto di risorse) esplode se si ri-indicizza a mano il db ogni dopo ogni patch-day.

    Wupdate soffre di bug sistemici come questi.

    Win 7 SP1 e Win XP, build stock, devo essere patchate a mano e syspreppate per poter avere un Windows Update funzionante..

    In buona sostanza si potrebbe tranquillamente ricevere uno stipendio solo per porre una pezza alle loro (più che volute e maldestre, imho), cavolate.

  • Per quanto riguarda WSUS (anche se in realtà dipende dalla tua versione di OS base) dai un’occhiata qui: https://gioxx.org/2016/08/09/wsus-clean-ps1/

    Per Win 7 e i problemi dovuti al patching che sembra in loop eterno quando ti allacci ai server Microsoft, dai un’occhiata qui: https://answers.microsoft.com/en-us/windows/wiki/windows_7-update/fix-windows-7-update-stuck-on-checking-for-updates/ad6cfeef-232a-49b4-a57b-39978eea6630

    Per le immagini base beh, su quello non puoi farci nulla. Io ormai tendo a scaricare le ISO degli OS (all’occorrenza, quando mi servono) direttamente da Digital River (tramite il Media Creation Tool di Microsoft, ma ovviamente parliamo di Windows 10, non certo di Xp).

  • alxbrb

    Io ho il mio set di iso patchate a mano. Vecchio stile.
    Solo che tento di scalare la casistica a grandi infrastrutture ed ovviamente inorridisco.

    In realtà comunque, la vera notizia che volevo portare alla luce é che qualsiasi versione di Windows 7 base o SP1, al momento non é in grado di usare Windows Update da WSUS. :D

    Il fix che sia SP2, o tramite tool (grazie! non lo conoscevo!), é quindi sempre necessario.

  • In realtà funziona, ma impiega davvero moltissimo tempo (dove moltissimo è più di quello che uno assegna di suo alla parola “moltissimo”).

  • alxbrb

    Non da quello che ho visto da Novembre 2016 a questa parte.
    Ho anche tenuto una box su per una settimana per curiosità (intervallata da qualche reboot e qualche wuauclt).. E WindowsUpdate.log non arrivava mai a loggare un report.
    (mentre lato wsus la macchina rimane sempre come “not yet contacted” / “not yet reported”.. per intenderci).

    Cosa che mi fà pensare che qualcosa sia cambiato (da nov 2016) rispetto alla situazione precendente (che ahimé purtroppo conosco).

  • Strano davvero, ho notato tutti i rallentamenti del caso (e quelli ci sono, eccome) ma non il completo hang della macchina. In ogni caso poco male, nel mio caso il dominio prevede una GPO che forza la ricerca delle patch quando la macchina viene associata la prima volta (e da quel momento in poi tutto va a posto), mentre per preparare i master (le immagini per clonare le macchine) viene tutto allineato con una rapida passata di WSUSOffline (gran mano santa) ;-)

  • alxbrb

    La mia risposta invece é stata un progressivo abbandono di Microsoft su tutti i livelli.
    (forte dei dovuti mezzi e del dovuto know-how, ovviamente, anche perché vengo solo in parte da questo tipo di ecosistema ed onestamente non ho intenzione di restarci)

    Ad ogni modo, mantengo comunque un piccolo ecosistema, iso patchata a mano con WU latest (o comunque una versione abbastanza recente da essere funzionante). (fatto sia con winxp che con win7, e poi distribuita la iso a chi prepara i pc, con una iso in sysprep a corredo)… in più un archivio locale di patch in caso serva. Usato in passato in diversi contesti.

    Uso inoltre spesso anche l’accoppiata PS + WuInstall per tagliare i tempi stupidi di microsoft e velocizzare le cose in remoto.

    Grazie di nuovo delle dritte. Specie la questione lato nodo WSUS. Non ho grosse necessità di automatizzare ma la parte SQL é interessate se correlata al classico “sqlcmd -E -S np:\.pipeMICROSOFT##WIDtsqlquery -i WsusDBMaintenance.sql” di vecchia maldestra microsoftiana memoria.

  • Figurati per le dritte. Ho tirato su il blog anni fa più o meno per questo motivo, continuo a darle (alternando ogni tanto articoli stupidi, ma quelli ci stanno!) ;-p

  • Federico

    Ho usato il tuo batch, grazie mille mi hai salvato la vita