web-dev-qa-db-ja.com

1時間前に時間を変更しているWindowsプロセスを見つける

理由は不明ですが、システム時刻を定期的に変更するWindowsマシンを持っています。それは1時間ごとに発生するようです。

このWindowsマシンは仮想マシンです（Parallels Desktop 9、Win7ゲスト、OSXホスト）。 NTPサービス（ NetTime ）が実行されており、エラーがすぐに修正されますが、変更から修正までのわずか数秒で問題が発生します。

確認しました：

  • VM時刻同期が無効になっている
  • Windowsの「インターネット時間」が無効になっている
  • WindowsTimeサービスが無効になっています
  • NTPクライアントを1つだけ実行し、15分ごとに更新しています

厄介な問題があります。私たちは一晩天文学サービスを実行します。自動DST変更に起因する問題を回避するために、自動DST変更を無効にし、その日の後半にマシンのタイムゾーンを正しいオフセットのゾーンに手動で設定します。たとえば、スペインでは現在DSTです。標準時はUTC + 1、DSTはUTC +2です。 DSTが変更された翌朝、マシンのタイムゾーンをギリシャUTC +2に設定しました。ホストマシンは正常に構成されています（正しいタイムゾーン、自動DST変更）。複雑なのは、時計がUTC + 1の現在の時刻（DST前の時刻）に戻ることです。

いくつかのプロセスがこれを変えています。おそらくそれはそれ自身のタイムゾーン設定を持っています。しかし、私はそれを追跡することができませんでした。変更はシステムログに記録されます。 2つの重要なエントリがあります：時間が正しく設定されていない場合と、修正された場合： Event log timestamps
（完全な開示、イベントログはイベントID = 1でフィルタリングされますが、他のイベントは無意味に見えます）。

これらがどれほど定期的に発生するかは興味深いです（1時間ごと、1秒ごと）。さらに興味深いのは、これらが稼働時間の時間であることです。タスクマネージャーでシステムの稼働時間を監視できます。1時間以上経過すると、時計が変わります。

また、イベントの詳細を見るのも興味深いです。

- <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>

このイベントが01:31から00:31に変化するのを確認できます（UTC時間、イベントログに表示される03:31から02:31ローカル）。特に興味深いのは、この行です。

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

PID4はSystemプロセスです。
Task Manager process list

ProcessExplorerを使用すると、システムプロセス（PID 4）を検査でき、ThreadId 56の詳細を確認できます（リサイクルされておらず、正しいプロセスを探していると仮定します）。
Process Explorer

しかし、それはすべて私には意味不明です。ここで確認できる唯一の意味のあることは、開始時間と、それがクロック変更イベント時間とどのように関連しているかです（前述のように、稼働時間と同期して1時間ごと）。

この回答 セキュリティログで時間の変更を見つけることについて話し、NetTimeサービスによって開始されたすべての変更がそこにあります。しかし、問題のある変更は疑わしいほど欠落しています： Security Log

分析は正しいですか？正しい場合、システムプロセスがシステムクロックを1時間ごとに変更するのはなぜですか？

windowsvirtualizationprocessntptime-synchronization
2
Ian

さて、すべての最悪のタイプの問題がそうであるように、これには2つの部分がありました。

  1. Windowsは、システム時刻を1時間ごとにハードウェアクロックに更新します。 （これは起動時にも行われるため、テストが高速化されることに注意してください）
  2. Parallelsは、ハードウェアクロックを誤って仮想化していました。古いバージョンのParallels（PD9）を使用していると言わざるを得ませんが、これが修正されていることを願っています。

私はこれについて明確な声明を見つけていませんが、同じことを確認する多くの人々を見てきました：毎時Windowsはリアルタイムクロック（RTC、またはBIOSのハードウェアクロック）を読み取り、再同期しますそれと。参考文献を参照してください： ＃1 、 ＃2 、 ＃ 、 ＃4 。

明らかに、これらのほとんどは、障害のあるRTC、フラットなBIOSバッテリー、または* nix OS（現地時間ではなくRTCにUTCを格納する）でのデュアルブートに関係しています。しかし、Windowsがこれを1時間ごとに実行するという事実は変わりません。これを無効にする方法はまだ見つかりません。

さらに、Parallelsはハードウェアクロック自体を保持せず、代わりにVM構成ファイル）に（システム時間からの）オフセットを保持します。問題は、このオフセットが正しくないことです。 DSTを考慮に入れます。たとえば、スペインのマドリードにホストMacがあります。通常はUTC + 1ですが、現在の夏時間はUTC + 2です。ゲストマシンで時刻を設定すると、ParallelsはDSTなしのゲスト時間とホストタイムゾーン。

例を見てみましょう：
現在の時刻はUTC00：00です。
マドリードの標準時はUTC + 1なので、01：00です。現在DST、UTC + 2、02：00であることを除いて。ゲストマシンを02:00に設定すると、WindowsはこれをRTCに書き込もうとし、Parallelsはゲスト時間とMadrid Standard（01:00）の差を計算し、<TimeShift>-3600</TimeShift>を構成ファイルに保存します（ファイルは再起動時に更新されますが、この変数は実行時にメモリ内で追跡されると思います）。したがって、WindowsがRTC（Parallelsはホストシステム時刻を読み取る）を読み取るたびに、RTCはHostTime-3600s（-1時間）に設定されていると見なされ、時間を更新します。

ゲストマシンのセットアップが複雑であることはわかっています（DSTなしでタイムゾーンを見つけるために手動でカイロに設定されています）。Parallelsに疑いの恩恵を与え、ゲストとホストの両方が正しいタイムゾーンに設定されているかどうかを確認したいと思いました。 （DSTでマドリッド）。いいえ、それはまだ台無しです。

解決策：
Windowsが1時間ごとにRTCを読み取らないようにする方法が見つからないため、当面の間、ホストマシンにそうでないタイムゾーンを使用するように強制しました。 dST（Cairo、UTC + 2など）を使用します。これは機能します。ゲスト時間を02:00に保存し、Cairo時間（UTC + 2）が02:00の場合、Parallelsは<TimeShift>0</TimeShift>を保存します。

醜い。

1
Ian

ソフトウェアで使用できる時間は、システム時間と現地時間の2つです。 DST設定に関係なく、システム時刻は更新しないでください。現地時間は調整されるものです。そうでない場合は、OSまたはアプリケーションにプログラミングエラーがある可能性があります。アプリケーションが使用している可能性があります。 GetLocalTime（）は、GetSystemTime（）を使用する必要があり、UIが誤ってシステム時刻であると表示している場合。

0
Anthony Bachler