2

当社の製品には、スケジュールされた間隔でアプリケーションが 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;

            スイッチ (timeZoneAbbreviation)
            {
                ケースアラスカ:
                    TimeZoneInfo = アラスカ_TZN;
                    壊す;
                ケース ALASKA_ALT:
                    TimeZoneInfo = アラスカ_TZN;
                    壊す;
                ケースアトランティック:
                    TimeZoneInfo = ATLANTIC_TZN;
                    壊す;
                ケースATLANTIC_ALT:
                    TimeZoneInfo = ATLANTIC_TZN;
                    壊す;
                ケース中央:
                    TimeZoneInfo = CENTRAL_TZN;
                    壊す;
                ケース CENTRAL_ALT:
                    TimeZoneInfo = CENTRAL_TZN;
                    壊す;
                ケース東部:
                    TimeZoneInfo = EASTERN_TZN;
                    壊す;
                ケースインディアナ:
                    TimeZoneInfo = INDIANA_TZN;
                    壊す;
                ケースハワイ:
                    TimeZoneInfo = HAWAII_TZN;
                    壊す;
                ケース山:
                    TimeZoneInfo = MOUNTAIN_TZN;
                    壊す;
                ケースアリゾナ:
                    TimeZoneInfo = ARIZONA_TZN;
                    壊す;
                ケースパシフィック:
                    TimeZoneInfo = PACIFIC_TZN;
                    壊す;
                ケース PACIFIC_ALT:
                    TimeZoneInfo = PACIFIC_TZN;
                    壊す;

                デフォルト：                    
                    壊す;
            }

            TimeZoneInfo += "\0";

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

            foreach (tzc の TimeZoneInformation tzi)
            {
                文字列 tzDisplayName = tzi.DisplayName.TrimEnd(新しい char[]{'\\','0'});

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

            timeZoneChanged を返します。
        }

いつもお世話になっております。何かご意見は？

4

1 に答える 1

1

DateTimeHelper.SetTimeZoneInformation 呼び出しは、 SetTimezoneInformation APIに対する P/Invoke の非常に薄いラッパーです (ソースで確認したところです)。基本的に、呼び出しを行い、戻りコードをチェックします。それ以上のことは何もないため、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.2 BSP に潜在的なロックまたは競合が発生するバグがある可能性があります。
于 2009-01-05T18:04:16.990 に答える