4 votes

Trouver le processus Windows qui recule l'heure d'une heure.

J'ai une machine Windows qui change périodiquement l'heure du système, pour des raisons inconnues. Cela semble se produire toutes les heures.

Cette machine Windows est une machine virtuelle (Parallels Desktop 9, Win7 invité, OSX hôte). Elle possède un service NTP ( NetTime ) en cours d'exécution qui corrige rapidement l'erreur, mais dans ces quelques secondes entre le changement et la correction, elle pose des problèmes.

J'ai vérifié :

  • La synchronisation temporelle de la VM est désactivée
  • Windows "Internet Time" est désactivé
  • Le service Windows Time est désactivé
  • Je n'ai qu'un seul client NTP, qui met à jour toutes les 15 minutes.

Il y a une complication. Nous gérons un service d'astronomie de nuit. Afin d'éviter les problèmes liés aux changements automatiques d'heure, nous désactivons les changements automatiques d'heure et réglons manuellement le fuseau horaire de la machine plus tard dans la journée sur une zone avec le décalage correct. Par exemple, en Espagne, c'est l'heure d'été en ce moment. L'heure normale est UTC+1, le DST est UTC+2. Le matin après le changement d'heure, nous réglons le fuseau horaire de la machine sur la Grèce UTC+2. La machine hôte est configurée normalement (fuseau horaire correct, changement automatique de l'heure d'été). La complication est que l'horloge revient à l'heure actuelle à UTC+1 (heure pré-DST).

Un processus quelconque est en train de changer cela. Il est possible qu'il ait son propre réglage de fuseau horaire. Mais je n'ai pas été en mesure de le retrouver. Les changements sont enregistrés dans le journal du système. Il y a deux entrées clés : l'endroit où l'heure est mal réglée et le moment où elle est corrigée : Event log timestamps
(Pour tout vous dire, le journal des événements est filtré par l'ID d'événement = 1, mais les autres événements semblent dénués de sens).

Il est intéressant de voir à quel point ces événements sont réguliers (toutes les heures, à la seconde près). Ce qui est encore plus intéressant, c'est que ce sont des heures de Temps de fonctionnement . Je peux surveiller le temps de fonctionnement du système dans le Gestionnaire des tâches, et lorsqu'il dépasse l'heure, l'horloge change.

Il est également intéressant de regarder les détails de l'événement :

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> 
    - <System> 
        <Provider Name="Microsoft-Windows-Kernel-General" Guid="{GUID}" /> 
        <EventID>1</EventID> 
        <Version>0</Version> 
        <Level>4</Level> 
        <Task>0</Task> 
        <Opcode>0</Opcode> 
        <Keywords>0x8000000000000010</Keywords> 
        <TimeCreated SystemTime="2018-04-18T00:31:28.500000000Z" /> 
        <EventRecordID>500706</EventRecordID> 
        <Correlation /> 
        <Execution ProcessID="4" ThreadID="56" /> 
        <Channel>System</Channel> 
        <Computer>T07-VM-GUEST</Computer> 
        <Security UserID="SID" /> 
    </System> 
    - <EventData> 
        <Data Name="NewTime">2018-04-18T00:31:28.500000000Z</Data> 
        <Data Name="OldTime">2018-04-18T01:31:28.861800000Z</Data> 
    </EventData> 
</Event>

Nous pouvons voir que cet événement change de 01:31 à 00:31 (heure UTC, 03:31 à 02:31 locale comme indiqué dans le journal des événements). Ce qui est particulièrement intéressant est cette ligne :

<Execution ProcessID="4" ThreadID="56" /> 

Le PID 4 est le System processus :
Task Manager process list

En utilisant ProcessExplorer, je peux inspecter le processus System (PID 4) et je peux voir quelques détails sur ThreadId 56 (en supposant qu'ils ne sont pas recyclés et que je regarde le bon) :
Process Explorer

Mais c'est du charabia pour moi. La seule chose significative que je vois ici est l'heure de début, et comment elle est liée aux heures de changement d'horloge (comme je l'ai dit plus haut, toutes les heures en synchronisation avec Uptime).

Cette réponse parle de trouver les changements d'heure dans le journal de sécurité, et tous les changements initiés par le service NetTime s'y trouvent. Mais les changements problématiques sont étrangement absents : Security Log

Mon analyse est-elle correcte et, dans ce cas, pourquoi le processus système modifie-t-il mon horloge système toutes les heures ?

1voto

Ian Points 160

Ok, comme tous les pires types de problèmes, celui-ci avait deux parties.

  1. Windows met à jour l'heure du système toutes les heures en fonction de l'horloge matérielle. (Notez qu'il le fait aussi au démarrage, ce qui a accéléré les tests).
  2. Parallels virtualisait l'horloge matérielle de manière incorrecte. Je dois dire que j'utilise une ancienne version de Parallels (PD9), j'espère qu'ils ont déjà corrigé ce problème.

Je n'ai pas trouvé de déclaration définitive à ce sujet, mais j'ai vu beaucoup de personnes à ma place confirmer la même chose : toutes les heures, Windows lit l'horloge en temps réel (RTC, ou l'horloge matérielle dans le BIOS) et se re-synchronise avec elle. Voir les références : #1 , #2 , #3 , #4 .

Il est évident que la plupart d'entre eux sont liés à un RTC défectueux, à des batteries BIOS déchargées ou à un double démarrage avec un système d'exploitation *nix (qui enregistre l'UTC dans le RTC, et non l'heure locale). Mais le fait est que Windows fait cela toutes les heures. Je n'ai pas encore trouvé le moyen de le désactiver.

En outre, Parallels ne conserve pas d'horloge matérielle en soi, mais un décalage (par rapport à l'heure du système) dans le fichier de configuration de la VM. Le problème est que ce décalage ne prend pas correctement en compte l'heure d'été. Par exemple, j'ai un Mac hôte à Madrid, en Espagne, qui est normalement à UTC+1, mais qui est actuellement à l'heure d'été à UTC+2. Lorsque je règle l'heure dans ma machine invitée, Parallels calcule la différence entre l'heure de mon invité et le fuseau horaire de mon hôte SANS DST.

Faisons un exemple :
L'heure actuelle est UTC 00:00.
L'heure normale de Madrid serait UTC+1, donc 01:00. Sauf que c'est actuellement l'heure d'été, UTC+2, 02:00. Je règle ma machine invitée sur 02:00, Windows essaie de l'écrire dans RTC, Parallels calcule la différence entre l'heure de ma machine invitée et l'heure standard de Madrid (01:00), et enregistre <TimeShift>-3600</TimeShift> dans le fichier de configuration (le fichier n'est mis à jour qu'au redémarrage, j'imagine que cette variable est suivie en mémoire pendant l'exécution). Ainsi, chaque fois que Windows lit le RTC (Parallels lit l'heure du système hôte), il pense que le RTC est réglé sur HostTime-3600s (-1 heure) et met à jour l'heure.

Je sais que ma machine invitée a une configuration compliquée (réglée manuellement sur Cairo pour trouver un fuseau horaire sans DST), je pensais donner à Parallels le bénéfice du doute et voir s'il fonctionne correctement avec l'invité et l'hôte réglés sur le bon fuseau horaire (Madrid avec DST). Non, ça ne marche toujours pas.

Solution :
Je n'arrive pas à trouver un moyen d'empêcher Windows de lire le RTC toutes les heures, alors pour l'instant j'ai forcé la machine hôte à utiliser un fuseau horaire qui n'utilise pas l'heure d'été (par exemple le Caire, UTC+2). Cela fonctionne. Lorsque je sauvegarde l'heure de mon invité à 02:00, et que l'heure du Caire (UTC+2) est 02:00, Parallels sauvegarde <TimeShift>0</TimeShift> .

Moche.

0voto

Anthony Bachler Points 101

Deux heures sont disponibles pour le logiciel, l'heure du système et l'heure locale. L'heure système ne doit pas être mise à jour, quel que soit le paramètre DST. C'est l'heure locale qui est ajustée. Si ce n'est pas le cas, il y a une erreur de programmation dans votre système d'exploitation ou plus probablement dans l'application. Il se peut que l'application utilise par exemple GetLocalTime() alors qu'elle devrait utiliser GetSystemTime() et que l'interface utilisateur indique par erreur qu'il s'agit de l'heure système.

0voto

cirovladimir Points 391

J'ai lutté avec cet événement exact du système pendant des jours. De nombreuses tentatives de désactivation ou de configuration des services de synchronisation du temps ont échoué. J'ai fini par trouver une solution de contournement pour empêcher le système d'ajuster l'heure du système toutes les 3600 secondes.

L'API Win32 offre une SetSystemTime pour régler l'heure du système à l'heure souhaitée. PowerShell offre une fonction plus pratique Set-Date qui englobe l'appel de l'API. En appelant Set-Date -Adjust 0 le temps du système reste inchangé, mais le système semble heureux. La partie laide, l'appel doit être répété toutes les 3600 secondes, pour empêcher l'événement système de se produire continuellement. Par conséquent, je lance un script PowerShell pour enregistrer une tâche planifiée qui est déclenchée toutes les 59 minutes :

$taskName = "Mock System Time Synchronization"
$taskDescription = "This task prevents the system to synchronize the system time with the hardware clock every 3600 seconds."

$startTime = (Get-Date) + (New-TimeSpan -Minutes 1)
$action = New-ScheduledTaskAction -Execute 'Powershell.exe' -Argument '-WindowStyle Hidden -command "& Set-Date -Adjust 0"'
$trigger =  New-ScheduledTaskTrigger -Once -At $startTime -RepetitionInterval (New-TimeSpan -Minutes 59)

Register-ScheduledTask -Action $action -Trigger $trigger -TaskName $taskName -Description $taskDescription -User "System"

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X