Windows CE .NET 4.2에서 왜 SettimezoneInfo가 매달릴 수 있습니까?

Question

당사의 제품에는 애플리케이션이 예정된 간격에 따라 DLL에서 코드를 실행할 수있는 작업 관리 시스템이 포함되어 있습니다. 작업의 실패가 관련 응용 프로그램을 비활성화 해야하는지 여부에 대한 규칙을 지정합니다. 로컬 데이터베이스 유지 관리 등. 사용 된 기능 중 하나는 NTP를 통해 장치 시간을 동기화하고 OS 'TimeZone 정보를 설정하는 것입니다. 이를 위해 OpenNETCF의 DateTimeHelper 클래스를 사용합니다.이 클래스는 Win32 P/Invokes 주변의 래퍼 역할을하는 것으로 보입니다.

작업 관리자의 다른 기능 중 하나는 태스크가 할당 된 시간 창보다 길게 실행되면 작업 관리자가 다른 작업을 실행할 수 있도록 Thread.Abort ()를 실행한다는 것입니다. 스택에서 가장 높은 함수가 OpenNetCf.windowsce.nativeMethods.settimezoneinformation () 인 놀라운 스레드 낙태가 있습니다. 기본 P/호출 (SettimezoneInfo)이 왜 그렇게 오랫동안 매달릴까요?

당사의 코드는 Windows CE 4.2에서 실행되며 Windows CE 5.0에서 사용자 기반이 훨씬 작습니다. 여기의 코드는 두 버전간에 동일합니다. 지금까지, 나는 이것이 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 Call은 P/호출 주변의 매우 얇은 래퍼입니다. SettimezoneInformation API (방금 소스에서 확인했습니다). 기본적으로 호출을하고 리턴 코드를 확인합니다. 더 이상 아무것도 없어서 SDF 자체를 근본 원인으로 배제합니다.

다음으로, settimezoneinformation을위한 MSDN DOC, 진짜 또는 거짓을 반환하는 것은 정말 간단한 동기 호출입니다. 이것은 API가 근본 원인이 아닐 수 있음을 알려줍니다.

CE에서 기억해야 할 한 가지는 절대 플랫폼이 OEM에 의해 수행되기 때문에 플랫폼이 완벽하다고 가정하므로 변형을 가질 수 있습니다. 5.0이 아닌 4.2에서 실패를 본다는 사실은 다음을 확인하게됩니다.

1. 4.2 장치 이미지에 모든 QFE가 적용되었는지 확인하십시오.
2. 시간대 항목에 대해 4.2와 5.0 사이의 OS 코드 차이가 있는지 확인하십시오 (의심하지만 더 이상 PB 4.2가 설치되어 있지 않음).
3. 설정 시간을 확인하는 OEM 구현을 확인하십시오. 구역을 암시 적으로 호출하여 시간을 설정하고 4.2 BSP에 잠재적 인 잠금 또는 경주가있는 버그가있을 수 있습니다.