W32Time congela o Windows

0

Eu tenho um tablet do Windows 10 exibindo alguns dados de medição. Funciona 24 horas por dia. Depois de algum tempo, congela totalmente. Eu descobri que isso tem a ver com o serviço W32Time.

Quando me conecto ao tablet via psexec e executo:

net stop w32time

Tudo é normal, quando eu inicio o w32time novamente, ele trava novamente. Descobri que o w32time é sem parar para acertar o relógio para um horário fixo. Eu habilitei um log de depuração com o w32tm.

Alguém sabe o que está causando esse comportamento?

Aqui está o log

151644 08:01:11.3518164s - Peer151644 08:01:11.3514248s151644     08:01:11.3515930s - W32TmServiceMain: ********** Time Slip Notification **********
151644 08:01:11.3517243s - ClockDispln TimeSlip:TimeSlip LastUTC:13032961 SetUnsync: LI:3 S:0 RDl:0 RDs:0 TSF:0x0 
151644 08:01:11.3518042s - ClockDispln Discipline: Check and set secure time
151644 08:01:11.3518157s - TimeProvCommand([NtpClient], TPC_TimeJumped) called.
151644 08:01:11.3518840s - W32TmServiceMain: waiting i16.000s (1024.000s)
151644 08:01:11.3518994s - PeerPollingThread: PeerListUpdated
151644 08:01:11.3519677s - Setting the system time because it is outside the secure time limits.
151644 08:01:11.3519708s - PeerPollingThread: waiting 895.487s
151644 08:01:11.3520284s -  Current system time:  8:1:11.351 3/10/2016
151644 08:01:11.3521121s -  Target system time:  8:1:11.352 3/10/2016
151644 08:01:11.3514501s - ClockDispln Discipline: *SET*SECURE*TIME*
151644 08:01:11.3516121s - W32TmServiceMain: ********** Time Slip Notification **********
151644 08:01:11.3517127s - ClockDispln TimeSlip:TimeSlip LastUTC:13032961 SetUnsync: LI:3 S:0 RDl:0 RDs:0 TSF:0x0 
151644 08:01:11.3517941s - ClockDispln Discipline: Check and set secure time
151644 08:01:11.3518133s - TimeProvCommand([NtpClient], TPC_TimeJumped) called.
151644 08:01:11.3518786s - W32TmServiceMain: waiting i16.000s (1024.000s)
151644 08:01:11.3519155s - PeerPollingThread: PeerListUpdated
151644 08:01:11.3519501s - Setting the system time because it is outside the secure time limits.
151644 08:01:11.3519777s - PeerPollingThread: waiting 895.487s
151644 08:01:11.3520092s -  Current system time:  8:1:11.351 3/10/2016
151644 08:01:11.3520622s -  Target system time:  8:1:11.352 3/10/2016
151644 08:01:11.3510976s - ClockDispln Discipline: *SET*SECURE*TIME*
151644 08:01:11.3512558s - W32TmServiceMain: ********** Time Slip Notification **********
151644 08:01:11.3513971s - ClockDispln TimeSlip:TimeSlip LastUTC:13032961 SetUnsync: LI:3 S:0 RDl:0 RDs:0 TSF:0x0 
151644 08:01:11.3514731s - ClockDispln Discipline: Check and set secure time
151644 08:01:11.3514839s - TimeProvCommand([NtpClient], TPC_TimeJumped) called.
151644 08:01:11.3515530s - W32TmServiceMain: waiting i16.000s (1024.000s)
151644 08:01:11.3516283s - PeerPollingThread: PeerListUpdated
151644 08:01:11.3516375s - Setting the system time because it is outside the secure time limits.
151644 08:01:11.3516843s - PeerPollingThread: waiting 895.487s
151644 08:01:11.3517012s -  Current system time:  8:1:11.351 3/10/2016
151644 08:01:11.3517519s -  Target system time:  8:1:11.352 3/10/2016
151644 08:01:11.3512112s - ClockDispln Discipline: *SET*SECURE*TIME*
    
por Jascha Schubert 05.04.2016 / 12:07

2 respostas

0

Eu tive o mesmo problema em uma máquina com Windows 10. Parece, é um bug do Windows. Defina a seguinte chave do Registro como 0:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\SecureTimeLimits\SecureTimeConfidence
    
por 23.05.2016 / 14:23
0

Eu tentaria desinstalar e reinstalar o serviço usando o w32tm / unregister e depois o w32tm / register.

Eu não tive um sistema de bloqueio do serviço de tempo, mas eu tive casos em que o sistema realmente não joga bem quando o serviço foi gaked up. Desinstalar e reinstalar resolveu isso.

Além disso, considere a configuração do tempo de inicialização do serviço Automatic Delayed. Não tenho 100% de certeza do motivo, mas isso tende a reduzir a chance de que ele seja executado em um serviço conflitante, etc ... o serviço de horário começará alguns minutos após o início do último serviço.

    
por 05.04.2016 / 17:33