Windows Update - Panoramica dei log d’installazione degli aggiornamenti

  • Article

Come abbiamo visto nell’articolo precedente, nei nuovi sistemi operativi il processo di aggiornamento di una macchina è basato su di una tecnica transazionale, che garantisce la corretta installazione di tutti gli aggiornamenti scaricati.

Come accennato, gli eventi di sistema sono la prima fonte di informazione nel caso ci siano problemi durante l’installazione degli aggiornamenti. Le informazioni contenute nella descrizione degli eventi sono però ad alto livello, ovvero a livello di pacchetto.

Con questo articolo vi illustro dove reperire ulteriori informazioni riguardo un’installazione fallita.

I principali posti da cui recuperare le informazioni relative all’installazione dei componenti, oltre agli eventi di sistema, sono:

  • %windir%\WindowsUpdate.log
  • %Windir%\logs\CBS.log

Mentre nel caso di errori di installazione al reboot della macchina:

  • %WinDir%\WinSxS\pending.xml
  • %WinDir%\WinSxS\poqexec.log

Seguendo l’ordine sopra descritto, si può tracciare una completa attività del processo di aggiornamento, in ordine crescente di dettagli.

Nel log di WindowUpdate troviamo tutta l’interazione con il server di aggiornamento, sia esso WSUS oppure il sito web Microsoft, ed inoltre troviamo lo stato finale dell’installazione come riportato dal servizio CBS. Nel caso di errori specifici all’installazione la sola consultazione di questo file non è sufficiente.

Nel secondo log della lista - CBS.log - troviamo tutte le operazioni effettuate dai componenti CBS, quindi la creazione delle transazioni e la valutazione delle regole di applicabilità. Il log non è “user-friendly” però a volte uno sguardo sommario può dare qualche indicazione in più sull’errore occorso durante l’installazione e fare puntare il dito verso una determinata risorsa (file, registro, permesso, ect.)

Gli ultimi due file sono strettamente legati tra loro, e servono per individuare l’errore quando l’installazione subisce problemi in fase di riavvio della macchina.

Addentriamoci ulteriormente nell’architettura CBS.

Possiamo pensare ad un pacchetto di aggiornamento come una serie/lista di operazioni da effettuare sul sistema; questa lista di operazioni, da eseguire con un ordine ben definito da regole di precedenza e di dipendenza, viene suddivisa in due code differenti:

  • Coda delle operazioni primitive (Primitive Operations Queue)
  • Coda delle operazioni avanzate (Advanced Installer Queue)

La prima coda contiene tutte quelle operazioni considerate “facili”, come ad esempio le operazioni sui file o sul registro di sistema; mentre la seconda coda viene riempita con tutte le operazioni che non possono essere modellate come operazioni primitive: ad esempio una modifica alle regole del firewall, l’installazione di una licenza..etc..

Per lo scopo di questo articolo, per semplificare le cose, consideriamo solamente la coda delle operazioni primitive.

Una volta costruita la coda, essa viene passata ad un componente che si occupa di eseguire tutte le operazioni elencate all’interno di una transazione kernel. È frequente che tra tutte queste operazioni alcune non possano essere eseguite durante la sessione di installazione, per i più svariati motivi, primo fra tutti l’accesso a file/risorse attualmente in uso.

Tutte queste operazioni “bloccano” la transazione richiedendo la propria esecuzione in fase di avvio della macchina. Davanti ad una simile richiesta il sistema operativo genera un file XML con il contenuto della coda primitiva (POQ) da eseguire durante il prossimo reboot. Il file generato è pending.xml ed è situato dentro la cartella %windir%\winsxs.

Esempio di file pending.xml:

<PendingTransaction Version="1.0" Identifier="58d5f3e1ca77c80164000000280f4c15">
<POQ>

<BeginTransaction id="TI4.29915082:3359338114:4/Package_for_KB937287" />
<MoveFile source=" \SystemRoot\WinSxS\Temp\PendingRenames\b3053de0ca77c80161000000280f4c15 " destination=" \SystemRoot\WinSxS\FileMaps\$$_servicing_fc2045b9046cc796.cdf-ms" />
<CreateFile path=" \SystemRoot\WinSxS\FileMaps\$$_servicing_version_6.0.6001.18000 " fileAttribute="0x00000000" />
<DeleteFile path=" \??\C:\Windows\System32\test.exe" />

</POQ>

Se al prossimo riavvio dovesse capitare un problema, il file verrà rinominato in pending.xml.bad e verrà generato il file poqexec.log all’interno della stessa cartella. Quest’ultimo file è come se contenesse l’indice degli errori occorsi all’interno del file pending.xml.bad. Controllando questo file il più delle volte riusciamo a trovare la specifica operazione primitiva che ha causato la fallita installazione.

Riporto un esempio concreto del file poqexec.log:

1c91429dcbd5e25: 0, 0, 0, 0, StartTime ;
1c91429e0a9e5b1: 0, 0, 0, 0, EndTime ;
1c92edb3b79b5c1: 0, 0, 0, 0, StartTime ;
1c92edb43e8bf82: 0, 0, 0, 0, EndTime ;
1c935d353ff8079: 0, 0, 0, 0, StartTime ;
1c935d3554f2373: 0, 0, 0, 0, EndTime ;
1c948b2d25268d5: 0, 0, 0, 0, StartTime ;
1c948b2d25268d5: 65b, c0190036, 16, 0, DeleteFile ;\??\C:\Windows\System32\test.exe
1c948b2d2787f05: 0, 0, 0, 0, EndTime ;

In caso di errori persistenti, come suggerisce l’articolo KB 949358 è possibile eliminare il file pending.xml per evitare che al successivo riavvio la macchina tenti di eseguire le sempre stesse operazioni che portano al problema.

Ogni errore ha una sua soluzione specifica, ma controllando tutti questi file, possiamo avere maggiori dettagli sugli errori occorsi, ed a volte possiamo anche trovare un work-around per la risoluzione del problema.

 

Gianluca Bertelli
Support Engineer
Microsoft Enterprise Platforms Support