In Windows CE .NET 4.2, warum könnte SetTimeZoneInfo hängen?

Question

Unser Produkt eine Aufgabe-Manager-System enthält die Anwendungen Code in einer DLL auf einem geplanten Intervall laufen zu lassen, geben Sie Regeln darüber, ob ein Ausfall der Aufgabe die entsprechende Anwendung deaktivieren sollen usw. Meistens ist es für Daten-Upload verwendet, Daten-Download, lokale Datenbank Wartung, etc. Eine der Funktionen ist es, die Geräte Zeit über NTP zu synchronisieren und die OS‘Zeitzone Info-set. Dazu verwenden wir OpenNetCF der DateTimeHelper Klasse, die als Wrapper um Win32 P / Invokes zu dienen scheint.

Einer der anderen Merkmal des Task-Managers ist, dass, wenn eine Aufgabe ausgeführt werden länger als die ihm zugewiesene Zeitfenster, der Task-Manager wird Thread.Abort () es andere Aufgaben laufen zu lassen. Wir sehen eine alarmierende Anzahl von Fäden Abtreibungen in dem die höchste Funktion auf dem Stack ist OpenNetCF.WindowsCE.NativeMethods.SetTimeZoneInformation (). Warum sollte die zugrunde liegende P / Invoke (SetTimeZoneInfo) hängt für so lange Zeit?

Unser Code läuft auf Windows CE 4.2, und mit einer viel kleineren totzukriegen, auf Windows CE 5.0 - der Code ist hier das gleiche zwischen den beiden Versionen. Bisher habe ich dies auf 4.2 Geräte gesehen auftreten, aber nie auf 5,0, und auch mit der kleineren Anzahl von Benutzern auf 5,0, ich glaube, ich würde es es war dort anwesend gesehen haben.

Die Funktion unten ist die Funktion, aus dem das Problem stammt. Er wandelt eine Zeitzone Abkürzung zu seinem vollen Namen, dann den Namen verwendet die richtige Zeitzone zu finden und versucht, dass man das Gerät die aktuelle Zeitzone einzustellen.

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

Dank wie immer für Ihre Hilfe. Irgendwelche Gedanken?

Answer 1

Der DateTimeHelper.SetTimeZoneInformation Aufruf ist eine sehr dünne Hülle um ein P / Invoke auf den MSDN doc für SetTimeZoneInformation , es ist ein wirklich einfacher synchroner Aufruf der wahr oder falsch zurückzugibt. Das sagt mir, dass der API nicht die Ursache entweder wahrscheinlich ist.

Eine Sache im CE zu remeber ist, dass man nie übernimmt die Plattform makellos ist becasue es deshalb getan durch den OEM und Variationen haben kann. Die Tatsache, dass Sie den Fehler in 4.2 sehen und nicht 5,0 führen würde mir folgendes überprüfen:

1. Stellen Sie sicher, dass das 4.2-Gerät Bild hat alle QFEs angewendet
2. Prüfen Sie, ob es ein OS-Code Unterschied zwischen 4.2 und 5.0 für die Zeitzone Zeug ist (ich bezweifle es, aber ich habe nicht 4.2 PB nicht mehr installiert ist).
3. Überprüfen Sie die OEM-Implementierung für Zeiteinstellung. Ändern die Zone macht implizit einen Anruf um die Zeit einzustellen, und es ist möglich, ein Fehler in dem 4.2 BSP gibt es die eine potenzielle Sperre oder Rasse hat, die Sie zu treffen.