Microsoft MVP성태의 닷넷 이야기
.NET Framework: 460. GetTickCount / GetTickCount64와 0x7FFE0000 주솟값 [링크 복사], [링크+제목 복사],
조회: 24620
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

GetTickCount / GetTickCount64와 0x7FFE0000 주솟값

GetTickCount API는 시스템이 시작된 이후 경과한 시간을 밀리초 단위로 반환합니다. (10ms ~ 16ms 단위입니다.)

GetTickCount function
; https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-gettickcount

위의 문서에도 나와있지만 이것의 반환값이 "DWORD"라서 32비트이므로 경과 시간을 표현하는데 한계가 있습니다. 대략 49.7일이 지나면 다시 0으로 돌아온다는 것이지요. 그래서 이 문제를 해결하려면 GetTickCount64를 쓰라고 권장하고 있습니다.

GetTickCount64 function
; https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-gettickcount64

위의 문서에 추가된 덧글에 보면 (64비트까지 확장되었으므로) 기간이 "585 million years"까지 늘어나기 때문에 기간 걱정은 할 필요가 없어진 것입니다.

새삼스럽게 GetTickCount 이야기를 꺼낸 것은 재미있는 글을 보았기 때문입니다. ^^

GetTickCount를 대체할만한 방법 있을까요? 
; http://lab.gamecodi.com/board/zboard.php?id=GAMECODILAB_QnA_etc&no=3187&z=

위의 덧글 중에 보면 0x7FFE0000라는 주소에 32비트/64비트 윈도우 운영체제 공통으로 KSYSTEM_TIME이라는 구조체 값이 들어 있다는 것입니다.

typedef struct _KSYSTEM_TIME  
{  
     ULONG LowPart;  
     LONG High1Time;  
     LONG High2Time;  
} KSYSTEM_TIME, *PKSYSTEM_TIME;

C#으로 이 값을 구해 보면 다음과 같이 코딩할 수 있습니다.

using System;
using System.Runtime.InteropServices;

class Program
{
    static void Main(string[] args)
    {
        IntPtr ptr = new IntPtr(0x7FFE0008);
        KSYSTEM_TIME systemTime = new KSYSTEM_TIME();
        Marshal.PtrToStructure(ptr, systemTime);

        Console.WriteLine("LowPart: " + systemTime.LowPart);
        Console.WriteLine("HighTime: " + systemTime.HighTime);
        Console.WriteLine("High2Time: " + systemTime.High2Time);

        ulong fullTime = (ulong)systemTime.LowPart | ((ulong)systemTime.HighTime << 32);
        Console.WriteLine("KSYSTEM_TIME: \t\t" + fullTime);
/*

출력결과

LowPart:   2242934063
HighTime:  102
High2Time: 102
KSYSTEM_TIME:  441971822558
*/
    }
}

[StructLayout(LayoutKind.Sequential)]
public class KSYSTEM_TIME
{
    public uint LowPart;
    public int HighTime;
    public int High2Time;
}


재미있는 것은 GetTickCount/64 결과와의 비교값입니다.

Console.WriteLine("Environment.TickCount: \t" + Environment.TickCount);
Console.WriteLine("GetTickCount: \t\t" + GetTickCount());
Console.WriteLine("GetTickCount64: \t" + GetTickCount64());

위의 코드를 한꺼번에 실행시키면 다음과 같은 결과를 얻을 수 있습니다.

KSYSTEM_TIME:           442837484163
Environment.TickCount:  44283734
GetTickCount:           44283750
GetTickCount64:         44283750

Environment.TickCount는 내부적으로 GetTickCount를 부를 것이므로 값이 같아야 하지만 JIT 컴파일 시간으로 인해 약간 차이가 벌어지는 것 같습니다. JIT 컴파일로 인한 부작용을 없애기 위해 한번 컴파일된 상태로 호출하면 다음과 같이 마지막 3개의 값이 대개 동일하게 나옵니다.

KSYSTEM_TIME:           442837503715
Environment.TickCount:  44283750
GetTickCount:           44283750
GetTickCount64:         44283750

문제는 KSYSTEM_TIME값과 TickCount의 관계입니다. 위의 값을 보면 KSYSTEM_TIME 값에서 정밀도를 절삭한 유형이 TickCount로 해석되는 듯합니다. 즉, GetTickCount가 49.7일이 지나서 0부터 다시 시작한다면 KSYSTEM_TIME 역시 정밀도만 좋은 것일 뿐 49.7일에 대한 문제는 해결되지 않는 것으로 보입니다. (따라서, KSYSTEM_TIME 값이 GetTickCount에 대한 해결책으로 보이지는 않습니다.)

제가 해당 API를 설계한 사람이 아니어서 더 이상의 해석은 불가능하지만, 암튼 0x7FFE0000 이라는 특수한 주소를 알았다는 사실만으로 오늘은 만족해야겠습니다. ^^

(첨부한 파일은 이 글의 예제 코드를 포함합니다.)




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]







[최초 등록일: ]
[최종 수정일: 1/3/2024]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2015-09-08 07시29분
[deepdark] 맨 아래 49.7일에 대해서 테스트는 해 보지 못했지만..
GetTickCount()와 GetTickCount64() 가 모두 같이 참조하는 메모리 주소로 보이고, 말씀하신대로 정밀도와 관련된 하부 얼마는 버리는 것이 맞는 것 같습니다.
다만, GetTickCount()의 경우 DWORD에 값을 받아오므로 Overflow 되는 부분에 대해 0부터 다시 시작하는 것이고, GetTickCount64()를 생각해볼때,
49.7일에 무관하게 더 큰 값이 기록될 것으로 보입니다.
[guest]
2015-09-08 07시47분
@deepdark 님, 이 글에서 GetTickCount64가 49.7일에 제약받는다고 쓰지 않았습니다. 처음 부분에도 나오지만 GetTickCount64는 "585 million years" 동안의 값이 표현될 것입니다. 이 글의 요지는 KSYSTEM_TIME이 49.7일에 제약을 받는지에 대해 쓴 것입니다.

그런데, 이번 기회를 통해 다시 코드를 보니 왠지 KSYSTEM_TIME이 49.7일 이후 GetTickCount64와 동일한 값은 아니어도 어떤 식으로든 상위 8바이트 내에서의 값이 변화하지 않을까 싶습니다. 한번 테스트를 해봐야겠군요. ^^
정성태
2016-06-22 03시15분
[kernel] 단순히 HighTime이 밀리세컨드를 표현하는 게 아니라 HighTime을 32비트 왼쪽으로 밀고 10000으로 나누는 거라서 KSYSTEM_TIME도 49.7일 이후에 0으로 바뀌지는 않을 것 같습니다.
HighTime = FFFFFF <-- 이게 밀리세컨드 표현이면 4294967295 / 1000 / 60 / 60 / 24 = 49.7 이지만
((ulong)(FFFFFF << 32)) / 10000 <--- 실제로는 이것이 밀리세컨드 표현이므로 1844674406941458 / 1000 / 60 / 60 / 24 = 21350398 일정도이지 않을까요.

ps: 여담이지만 홈페이지 너무 잘보고 있습니다. 닷넷과 C#의 역사를 볼 수 있는 곳이네요
[guest]
2016-06-22 11시56분
@kernel 님 설명 감사합니다. ^^
정성태

... 61  62  63  [64]  65  66  67  68  69  70  71  72  73  74  75  ...
NoWriterDateCnt.TitleFile(s)
12042정성태10/26/201911100오류 유형: 573. OneDrive 하위에 위치한 Documents, Desktop 폴더에 대한 권한 변경 시 "Unable to display current owner"
12041정성태10/23/201911100오류 유형: 572. mstest.exe - The load test results database could not be opened.
12040정성태10/23/201911343오류 유형: 571. Unhandled Exception: System.Net.Mail.SmtpException: Transaction failed. The server response was: 5.2.0 STOREDRV.Submission.Exception:SendAsDeniedException.MapiExceptionSendAsDenied
12039정성태10/22/20199779스크립트: 16. cmd.exe의 for 문에서는 ERRORLEVEL이 설정되지 않는 문제
12038정성태10/17/20199339오류 유형: 570. SQL Server 2019 RC1 - SQL Client Connectivity SDK 설치 오류
12037정성태10/15/201915240.NET Framework: 867. C# - Encoding.Default 값을 바꿀 수 있을까요?파일 다운로드1
12036정성태10/14/201916296.NET Framework: 866. C# - 고성능이 필요한 환경에서 GC가 발생하지 않는 네이티브 힙 사용파일 다운로드1
12035정성태10/13/201912433개발 환경 구성: 461. C# 8.0의 #nulable 관련 특성을 .NET Framework 프로젝트에서 사용하는 방법 [2]파일 다운로드1
12034정성태10/12/201911800개발 환경 구성: 460. .NET Core 환경에서 (프로젝트가 아닌) C# 코드 파일을 입력으로 컴파일하는 방법 [1]
12033정성태10/11/201915477개발 환경 구성: 459. .NET Framework 프로젝트에서 C# 8.0/9.0 컴파일러를 사용하는 방법
12032정성태10/8/201911960.NET Framework: 865. .NET Core 2.2/3.0 웹 프로젝트를 IIS에서 호스팅(Inproc, out-of-proc)하는 방법 - AspNetCoreModuleV2 소개
12031정성태10/7/20199384오류 유형: 569. Azure Site Extension 업그레이드 시 "System.IO.IOException: There is not enough space on the disk" 예외 발생
12030정성태10/5/201915648.NET Framework: 864. .NET Conf 2019 Korea - "닷넷 17년의 변화 정리 및 닷넷 코어 3.0" 발표 자료 [1]파일 다운로드1
12029정성태9/27/201915760제니퍼 .NET: 29. Jennifersoft provides a trial promotion on its APM solution such as JENNIFER, PHP, and .NET in 2019 and shares the examples of their application.
12028정성태9/26/201911523.NET Framework: 863. C# - Thread.Suspend 호출 시 응용 프로그램 hang 현상을 해결하기 위한 시도파일 다운로드1
12027정성태9/26/20198807오류 유형: 568. Consider app.config remapping of assembly "..." from Version "..." [...] to Version "..." [...] to solve conflict and get rid of warning.
12026정성태9/26/201912466.NET Framework: 862. C# - Active Directory의 LDAP 경로 및 정보 조회
12025정성태9/25/201910805제니퍼 .NET: 28. APM 솔루션 제니퍼, PHP, .NET 무료 사용 프로모션 2019 및 적용 사례 (8) [1]
12024정성태9/20/201912247.NET Framework: 861. HttpClient와 HttpClientHandler의 관계 [2]
12023정성태9/18/201912665.NET Framework: 860. ServicePointManager.DefaultConnectionLimit와 HttpClient의 관계파일 다운로드1
12022정성태9/12/201915710개발 환경 구성: 458. C# 8.0 (Preview) 신규 문법을 위한 개발 환경 구성 [3]
12021정성태9/12/201927588도서: 시작하세요! C# 8.0 프로그래밍 [4]
12020정성태9/11/201914424VC++: 134. SYSTEMTIME 값 기준으로 특정 시간이 지났는지를 판단하는 함수
12019정성태9/11/20199756Linux: 23. .NET Core + 리눅스 환경에서 Environment.CurrentDirectory 접근 시 주의 사항
12018정성태9/11/20198752오류 유형: 567. IIS - Unrecognized attribute 'targetFramework'. Note that attribute names are case-sensitive. (D:\lowSite4\web.config line 11)
12017정성태9/11/201911801오류 유형: 566. 비주얼 스튜디오 - Failed to register URL "http://localhost:6879/" for site "..." application "/". Error description: Access is denied. (0x80070005)
... 61  62  63  [64]  65  66  67  68  69  70  71  72  73  74  75  ...