Échec des mises à jour après modification du servicing stack. L'installation des correctifs échoue systématiquement sur nos postes de travail

Question

Échec des mises à jour après modification du servicing stack. L'installation des correctifs échoue systématiquement sur nos postes de travail

Louis Thomas 40

Bonjour à tous,

Mon équipe essaie toute la journée de déployer les nouveaux correctifs sur le parc informatique.

Et nous avons déjà tout essayé pour faire passer les mises à jour sur les machines concernées.

Les mises à jour se sont bloquées juste après la modification du servicing stack et l’installation du paquet prérequis.

Les rapports locaux échouent sans donner d'explication claire. On ne sait pas si le problème vient d'une dépendance manquante entre les paquets ou si le composant de maintenance du système nécessite une réparation complète.

Comment puis-je vérifier les dépendances des paquets et déterminer si une réparation du service de maintenance est nécessaire sur nos machines ?

Merci beaucoup d'avance.

0 commentaires

1 réponse

Votre réponse

Answer 1

Bonjour Louis Thomas,

Avant d'envisager une réparation, je commencerais par déterminer si l'échec est lié à une dépendance de package ou à une corruption du magasin de composants. Pour cela, vérifiez l'état des packages avec DISM /Online /Get-Packages /Format:Table et recherchez ceux qui restent de manière persistante dans un état tel que Install Pending, Install Failed ou Uninstall Pending.

J'examinerais ensuite C:\Windows\Logs\CBS\CBS.log ainsi que les fichiers archivés CbsPersist_*.log, car ils indiquent généralement le package exact et le code d'erreur à l'origine de l'échec. Les informations contenues dans C:\Windows\Logs\DISM\dism.log permettent également de confirmer si le composant de maintenance rencontre des erreurs lors de la validation ou de l'installation des packages.

Si les journaux montrent des erreurs telles que 0x80073712 ou d'autres références à une corruption du magasin de composants, il devient alors pertinent d'évaluer l'état du système avec DISM /Online /Cleanup-Image /ScanHealth avant de lancer une réparation.

Quel code d'erreur ou quel package revient de façon répétitive dans le CBS.log ? C'est généralement l'information la plus utile pour déterminer si le problème provient d'une dépendance manquante ou d'une corruption du servicing stack.

Si cette réponse vous aide, merci de l'accepter.

Tracy Le.