Windows CE .NET 4.2でSetTimeZoneInfoがハングするのはなぜですか？

Question

当社の製品には、アプリケーションがスケジュールされた間隔でDLL内のコードを実行したり、タスクの失敗により関連アプリケーションを無効にするかどうかのルールを指定したりできるタスクマネージャーシステムが含まれています。データのダウンロード、ローカルデータベースのメンテナンスなど。使用される機能の1つは、NTPを介してデバイスの時刻を同期し、OSのタイムゾーン情報を設定することです。このために、OpenNetCFのDateTimeHelperクラスを使用します。これは、Win32 P / Invokesのラッパーとして機能するようです。

タスクマネージャの他の機能の1つは、タスクが割り当てられた時間ウィンドウよりも長く実行される場合、タスクマネージャは他のタスクの実行を許可するThread.Abort（）であることです。スタックの最上位の関数がOpenNetCF.WindowsCE.NativeMethods.SetTimeZoneInformation（）である驚くべき数のスレッド中断が発生しています。基礎となるP / Invoke（SetTimeZoneInfo）がこのように長時間ハングするのはなぜですか？

当社のコードはWindows CE 4.2で実行され、Windows CE 5.0でははるかに小さなユーザーベースで実行されます。ここのコードは2つのバージョンで同じです。これまでのところ、これは4.2デバイスで発生しましたが、5.0では発生しませんでした。5.0のユーザー数が少なくても、そこに存在していれば見たことがあると思います。

以下の関数は、問題の原因となっている関数です。タイムゾーンの省略形をフルネームに変換し、その名前を使用して適切なタイムゾーンを見つけ、デバイスの現在のタイムゾーンをそのタイムゾーンに設定しようとします。

        public static bool SetTimeZone(string timeZoneAbbreviation)
        {
            string TimeZoneInfo = string.Empty;
            bool timeZoneChanged = false;

            switch (timeZoneAbbreviation)
            {
                case ALASKA:
                    TimeZoneInfo = ALASKA_TZN;
                    break;
                case ALASKA_ALT:
                    TimeZoneInfo = ALASKA_TZN;
                    break;
                case ATLANTIC:
                    TimeZoneInfo = ATLANTIC_TZN;
                    break;
                case ATLANTIC_ALT:
                    TimeZoneInfo = ATLANTIC_TZN;
                    break;
                case CENTRAL:
                    TimeZoneInfo = CENTRAL_TZN;
                    break;
                case CENTRAL_ALT:
                    TimeZoneInfo = CENTRAL_TZN;
                    break;
                case EASTERN:
                    TimeZoneInfo = EASTERN_TZN;
                    break;
                case INDIANA:
                    TimeZoneInfo = INDIANA_TZN;
                    break;
                case HAWAII:
                    TimeZoneInfo = HAWAII_TZN;
                    break;
                case MOUNTAIN:
                    TimeZoneInfo = MOUNTAIN_TZN;
                    break;
                case ARIZONA:
                    TimeZoneInfo = ARIZONA_TZN;
                    break;
                case PACIFIC:
                    TimeZoneInfo = PACIFIC_TZN;
                    break;
                case PACIFIC_ALT:
                    TimeZoneInfo = PACIFIC_TZN;
                    break;

                default:                    
                    break;
            }

            TimeZoneInfo += "\0";

            TimeZoneCollection tzc = new TimeZoneCollection();
            tzc.Initialize();

            foreach (TimeZoneInformation tzi in tzc)
            {
                string tzDisplayName = tzi.DisplayName.TrimEnd(new char[]{'\\','0'});

                if (tzDisplayName.ToUpper(CultureInfo.CurrentCulture).Equals(TimeZoneInfo.ToUpper(CultureInfo.CurrentCulture)))
                {
                    DateTimeHelper.SetTimeZoneInformation(tzi);
                    System.Globalization.CultureInfo.CurrentCulture.ClearCachedData();
                    timeZoneChanged = true;
                    break;
                }
            }

            return timeZoneChanged;
        }

いつもお世話になりました。何か考えはありますか？

Answer 1

DateTimeHelper.SetTimeZoneInformationの呼び出しは、 SetTimezoneInformation API （ソースで確認しました）。基本的に呼び出しを行い、リターンコードをチェックします。これ以上はないため、SDF自体を根本原因として除外します。

次に、 SetTimezoneInformationのMSDNドキュメントを見ると、 TRUEまたはFALSEを返す本当に簡単な同期呼び出し。これにより、APIが根本的な原因ではない可能性が高いことがわかります。

CEで覚えておくべきことの1つは、OEMによって行われたためにプラットフォームが完璧であり、したがってバリエーションがある可能性があることを決して想定できないことです。 5.0ではなく4.2で障害が発生したという事実から、次の点を確認することになります。

1. 4.2デバイスイメージにすべてのQFEが適用されていることを確認します
2. タイムゾーンに関する4.2と5.0のOSコードの違いがあるかどうかを確認します（疑いはありますが、PB 4.2はもうインストールされていません）。
3. 時間の設定については、OEMの実装を確認してください。ゾーンを暗黙的に変更すると、時間を設定するための呼び出しが行われます。4.2BSPには、ロックまたは競合の可能性があるバグが存在する可能性があります。