Un événement USER32 1074 consigne une demande d’arrêt ou de redémarrage par un processus. Le motif peut être déclaré planifié ou non planifié. Cet événement ne prouve donc ni une panne électrique, ni que l’arrêt s’est terminé correctement.
Lire qui a demandé le redémarrage
Dans le journal Système, ouvrez le message complet et relevez le chemin du processus, le compte, le type d’arrêt, le Reason Code et le commentaire. Conservez ces informations avec l’heure du serveur : elles constituent le point de départ de la recherche.
Get-WinEvent -FilterHashtable @{
LogName = 'System'
Id = 1074
StartTime = (Get-Date).AddDays(-7)
} -MaxEvents 30 |
Select-Object TimeCreated, ProviderName, Id, Message |
Format-ListRapprocher la demande des autres journaux
- Comparer l’heure avec la fenêtre de maintenance et l’historique des mises à jour.
- Vérifier les tâches planifiées et les journaux de l’outil d’administration identifié, sans conclure sur le seul nom du processus.
- Lire les événements voisins et leur fournisseur pour distinguer demande logicielle, arrêt non propre et éventuel bugcheck.
Get-WinEvent -FilterHashtable @{
LogName = 'System'
Id = 41, 6008, 1001
StartTime = (Get-Date).AddDays(-7)
} -MaxEvents 60 |
Select-Object TimeCreated, ProviderName, Id, Message |
Format-ListKernel-Power 41 et EventLog 6008 décrivent un redémarrage après un arrêt non propre ; ils ne donnent pas à eux seuls sa cause. Un événement 1001 doit aussi être interprété avec son fournisseur et son message.
Si le processus est WmiPrvSE.exe
WmiPrvSE peut porter une demande effectuée par un script ou une application : son nom ne désigne pas directement l’auteur initial. Pour un incident récurrent, la méthode Microsoft rapproche une trace WMI et une trace de processus. Préparez cette collecte sur une durée limitée ; la fiche liée décrit la procédure et ses contraintes de stockage.
Valider la conclusion
Documentez la demande identifiée, les journaux concordants et l’action retenue. Exemple : un outil de gestion programme un redémarrage dans une fenêtre erronée ; corriger sa planification est plus pertinent que désactiver globalement les mises à jour. Si la corrélation reste insuffisante, gardez cette hypothèse ouverte plutôt que d’attribuer l’arrêt à un utilisateur.