C++ вызов функции API ::GetTickCount() скачет примерно на 18 дней

На нескольких компьютерах с Windows я видел, что два следующих друг за другом вызова ::GetTickCount() возвращают разницу в 1610619236 мс (около 18 дней). Это не из-за несоответствия og int/unsigned int. Я использую Visual C++ 2015/2017.

Кто-нибудь еще видел такое поведение? У кого-нибудь есть идеи о том, что может вызвать такое поведение?

С уважением, Джон

Пример кода, показывающий ошибку:

class CLTemp
{
    DWORD nLastCheck;
    CLTemp() 
    {
        nLastCheck=::GetTickCount();
    }
    //Service is called every 200ms by a timer
    void Service()
    {
        if( ::GetTickCount() - nLastCheck > 20000 )//check every 20 sec
        {
            //On some Windows machines, after an uptime of 776 days, the
            //::GetTickCount() - nLastCheck gives a value of 1610619236
            //(corresponding to around 18 days)
            nLastCheck = ::GetTickCount();
        }
    }

};

person rauhe    schedule 23.10.2020    source источник
comment
Вместо этого рекомендуется использовать GetTickCount64(). Тем не менее, я знаком с некоторыми средами антианализа, которые обманывают значение.   -  person Petesh    schedule 23.10.2020
comment
Отвечает ли это на ваш вопрос? Значения GetTickCount в Windows 10   -  person Build Succeeded    schedule 23.10.2020
comment
Что возвращает эта функция? =› Получает количество миллисекунд, прошедших с момента запуска системы, до 49,7 дней.   -  person Build Succeeded    schedule 23.10.2020
comment
@Build Succeeded Я не думаю, что проблема связана. Я использую GetTickCount исключительно для проверки разницы во времени между вызовами функций. Поэтому я не использую абсолютное время в качестве индикатора.   -  person rauhe    schedule 23.10.2020
comment
Можете ли вы поделиться кодом?   -  person Build Succeeded    schedule 23.10.2020
comment
@Petesh Было бы разумно использовать GetTickCount64(), но наш код массово использует GetTickCount(), и мы бы не хотели этого менять. Среда антианализа, которую вы упомянули, это антивирусные приложения? или у вас есть примеры?   -  person rauhe    schedule 23.10.2020
comment
@BuildSucceeded @Build Succeeded Код довольно прост. У нас есть функция, которая вызывается часто, она работает каждые миллисекунды dwInfoSendInterval. function_that_is_called_every_500ms () ... if( ::GetTickCount() - dwLastInfoSend > dwInfoSendInterval ) ) { //Do something dwLastInfoSend = ::GetTickCount(); } ... Мы очень редко видели в работающих системах, что ::GetTickCount() - dwLastInfoSend = ~18 days. Это в системе, которая работает уже 2 года.   -  person rauhe    schedule 23.10.2020
comment
ваше значение подозрительно близко к 0x60000000, вероятно, какая-то ошибка переноса, особенно если ваш компьютер работает уже 2 года, предоставьте минимально воспроизводимый пример   -  person Alan Birtles    schedule 23.10.2020
comment
Случайно ли эти несколько систем работают под управлением Windows Checked Builds?   -  person Michaël Roy    schedule 23.10.2020
comment
Это не связано с несоответствием og int/unsigned int. - Как бы мне ни хотелось в это верить, просто существует слишком много ошибок с таким описанием. Нам нужен минимально воспроизводимый пример.   -  person IInspectable    schedule 23.10.2020
comment
Я попытался предоставить образец кода в исходном вопросе. Однако; мы видим ошибку только в системах Windows, которые работают около 2 лет, поэтому воспроизвести ошибку очень сложно. Примечание: уже 2 года работает не наше приложение, а сам компьютер.   -  person rauhe    schedule 26.10.2020
comment
@MichaëlRoy Нет, к сожалению, сборки Windows — это Windows Server и Windows Professional (в разных версиях), но не проверенная сборка.   -  person rauhe    schedule 26.10.2020
comment
@AlanBirtles Значение близко к «0x60000000», но есть ли что-то особенное в этом числе?   -  person rauhe    schedule 26.10.2020
comment
Не то, чтобы я знал, но быть так близко к такому круглому числу довольно маловероятно случайно, это должно быть артефактом того, что вызывает вашу проблему (вероятно, что GetTickCount не очень надежен и не должен использоваться для чего-то важного)   -  person Alan Birtles    schedule 26.10.2020
comment
@rauhe Следует спросить, установили ли вы вне всяких сомнений, что разница на самом деле заключается в последовательных возвратах GetTickCount, а не, например, из-за некоторого повреждения памяти, которое может привести к поломке nLastCheck?   -  person dxiv    schedule 26.10.2020
comment
@dxiv: Вероятность повреждения памяти нескольких компьютеров в одних и тех же двух битах (логически, а не физически) практически равна нулю.   -  person MSalters    schedule 26.10.2020
comment
@dxiv Нет, я не исключал, что может быть утечка памяти, но, как также пишет MSalters, это маловероятно.   -  person rauhe    schedule 26.10.2020
comment
@rauhe Вряд ли, согласен. Но странные события иногда имеют еще более странные причины.   -  person dxiv    schedule 26.10.2020