为什么开机仅几小时 GetTickCount 取到的数值为 -1954795468 按我的认识 应该是在21天之后才会取得负值 呀

BIGGER2016 2016-05-30 01:14:06
在XP系统下正常的代码，为什么在WIN8 64位的系统中 开机仅几小时 GetTickCount 取到的数值为 -1954795468 按我的认识 应该是在21天之后才会取得负值 呀

相关代码如下：

Public Declare Function GetTickCount Lib "kernel32" () As Long ' 返回从开机始之后的毫秒数
Public sCurrentCount As Long
sCurrentCount = GetTickCount

sCurrentCount 取得的值 为 -1954795468
...全文
1241 20 打赏 收藏 转发到动态 举报
写回复
用AI写文章
20 条回复
切换为时间正序
请发表友善的回复…
发表回复
嗷嗷叫的老马 2016-06-19
  • 打赏
  • 举报
 回复
引用 19 楼 Chen8013 的回复:
[quote=引用 18 楼 myjian 的回复:] [quote=引用 17 楼 Chen8013 的回复:] [quote=引用 16 楼 myjian 的回复:] 好象也有人在WIN8 64位上遇到过这个问题. 有可能是一个BUG?
老马，好久不见！　 这个在 Win7 64位上都是正常的，　到了Win8那儿，就BUG了？有点说不通吧。 [/quote] 好久不见! 我搜了一下,看见有人在说开机五六小时就负值的,也是WIN8 64位,但没提到原因. 另外这个GetTickCount只是读个值,也许它读的那个地方被改了?比如有名的变速齿轮之类软件,就是HOOK相关的时间API来实现变速的[/quote] 按理说也不应该有什么软件去乱改这些数据。 呃，我们在这儿瞎猜，没有什么意义。 我刚来这个帖子回复时，就说了叫楼主验证一下。 按我在3楼说的做一下验证，找一点“推测依据”也不是难事，他却啥也不过问， 　　只管自顾自的“问”，对别人的疑惑他当没看见。 问题不能解决，我们也无法确认“出问题”的原因，费那些脑筋干什么！ 我不可能为了他这个没什么价值的问题，去装一个毫无意义的Win8来试吧！！！ [/quote] 也是啊!别人楼主都不上心,咱们费个啥劲啊,热脸贴啥冷屁股哈哈
舉杯邀明月 2016-06-18
  • 打赏
  • 举报
 回复
引用 18 楼 myjian 的回复:
[quote=引用 17 楼 Chen8013 的回复:] [quote=引用 16 楼 myjian 的回复:] 好象也有人在WIN8 64位上遇到过这个问题. 有可能是一个BUG?
老马，好久不见！　 这个在 Win7 64位上都是正常的，　到了Win8那儿，就BUG了？有点说不通吧。 [/quote] 好久不见! 我搜了一下,看见有人在说开机五六小时就负值的,也是WIN8 64位,但没提到原因. 另外这个GetTickCount只是读个值,也许它读的那个地方被改了?比如有名的变速齿轮之类软件,就是HOOK相关的时间API来实现变速的[/quote] 按理说也不应该有什么软件去乱改这些数据。 呃，我们在这儿瞎猜，没有什么意义。 我刚来这个帖子回复时，就说了叫楼主验证一下。 按我在3楼说的做一下验证，找一点“推测依据”也不是难事，他却啥也不过问， 　　只管自顾自的“问”，对别人的疑惑他当没看见。 问题不能解决，我们也无法确认“出问题”的原因，费那些脑筋干什么！ 我不可能为了他这个没什么价值的问题，去装一个毫无意义的Win8来试吧！！！
嗷嗷叫的老马 2016-06-18
  • 打赏
  • 举报
 回复
引用 17 楼 Chen8013 的回复:
[quote=引用 16 楼 myjian 的回复:] 好象也有人在WIN8 64位上遇到过这个问题. 有可能是一个BUG?
老马，好久不见！　 这个在 Win7 64位上都是正常的，　到了Win8那儿，就BUG了？有点说不通吧。 [/quote] 好久不见! 我搜了一下,看见有人在说开机五六小时就负值的,也是WIN8 64位,但没提到原因. 另外这个GetTickCount只是读个值,也许它读的那个地方被改了?比如有名的变速齿轮之类软件,就是HOOK相关的时间API来实现变速的
舉杯邀明月 2016-06-17
  • 打赏
  • 举报
 回复
引用 16 楼 myjian 的回复:
好象也有人在WIN8 64位上遇到过这个问题. 有可能是一个BUG?
老马，好久不见！　 这个在 Win7 64位上都是正常的，　到了Win8那儿，就BUG了？有点说不通吧。
嗷嗷叫的老马 2016-06-17
  • 打赏
  • 举报
 回复
好象也有人在WIN8 64位上遇到过这个问题. 有可能是一个BUG?
赵4老师 2016-06-16
  • 打赏
  • 举报
 回复
开机超过49.71/2天， GetTickCount就超过2^31了。
赵4老师 2016-06-16
  • 打赏
  • 举报
 回复
我的意思是楼主实际已经开机快到49.71天了，但由于中途修改过系统时间，让楼主误以为开机仅几小时。
舉杯邀明月 2016-06-16
  • 打赏
  • 举报
 回复
引用 12 楼 zhao4zhong1 的回复:
楼主电脑开机后，系统时间被修改过。我猜。

瞎说！！！
GetTickCount() 的结果根本不受“改时间”的影响。

这张图片，第一行的数据是“起始时间”，3个数据分别是：
当前系统时间　　从“0时”起当前时间的毫秒数　　开机后GetTickCount()的值
第二行的数据“改了系统时间之后”的结果，3个数据分别是：
当前系统时间　　当前时间跟前一时间相差毫秒数　　　GetTickCount()跟前一次相差毫秒数

可以看到：
点了Command1取得“时间基准”后，我在DOS窗口中改系统时间，再过来点Command2，
把时间改快了接近42分钟（不足42）时间，从“系统时间”计算的结果是快了250万毫秒；
但 GetTickCount() 的差值不到4000毫秒。
这就说明：
1.　我点Command1、打开DOS窗口改时间、点Command2，总共不到4秒；
2.　GetTickCount()不依赖系统时间，它是独立计数的，改系统时间不影响它。
赵4老师 2016-06-15
  • 打赏
  • 举报
 回复
楼主电脑开机后，系统时间被修改过。我猜。
BIGGER2016 2016-06-14
  • 打赏
  • 举报
 回复
引用 10 楼 Chen8013 的回复:
[quote=引用 9 楼 BIGGER2016 的回复:] [quote=引用 8 楼 BIGGER2016 的回复:] [quote=引用 7 楼 Chen8013 的回复:] [quote=引用 4 楼 BIGGER2016 的回复:] [quote=引用 3 楼 Chen8013 的回复:] 楼主算错了吧，应该是“约24.855天”之后才变负数的。 出现这个问题，应该是系统的原因吧，我在“ Win7-32位专业版”中的运行结果也是正常的。 不知道有没有可能在64位系统中，它的含义“重新定义过”了？ 比如它返回的是“微秒”而不是毫秒（这是我乱猜的，很可能不对，但楼主可以用下面的方法试验一下：） 用一个Timer控件，设置它的周期为1秒（或100ms）； 比较一下每次GetTickCount()的返回值，看它的差值是多少。 （跟以前一样，差值单位应该是“毫秒”；或者它真的应该是“微秒”为单位了　）
非常感谢，有没有具体的解决方法？ [/quote] 我这儿根本“遇不到问题”、也无法确定造成你的那种问题的原因，那又何来“解决问题”的说法？ 你按我说的去验证一下，又不是什么很麻烦的事。 先得摸清楚情况再说啊。 要不你就搜索一下“GetTickCount64”，看看那些资料对你有帮助没。 [/quote]日斤斤计较[/quote] 打错了，非常感谢。 [/quote] 我在 Win7 SP1/64位 下，运行结果完全正常。 真不知道是不是楼主的使用方法（或者说“代码”）是不是有问题。 [/quote] 非常感谢，还有其他答案吗？
舉杯邀明月 2016-06-05
  • 打赏
  • 举报
 回复
引用 9 楼 BIGGER2016 的回复:
[quote=引用 8 楼 BIGGER2016 的回复:] [quote=引用 7 楼 Chen8013 的回复:] [quote=引用 4 楼 BIGGER2016 的回复:] [quote=引用 3 楼 Chen8013 的回复:] 楼主算错了吧，应该是“约24.855天”之后才变负数的。 出现这个问题，应该是系统的原因吧，我在“ Win7-32位专业版”中的运行结果也是正常的。 不知道有没有可能在64位系统中，它的含义“重新定义过”了？ 比如它返回的是“微秒”而不是毫秒（这是我乱猜的，很可能不对，但楼主可以用下面的方法试验一下：） 用一个Timer控件，设置它的周期为1秒（或100ms）； 比较一下每次GetTickCount()的返回值，看它的差值是多少。 （跟以前一样，差值单位应该是“毫秒”；或者它真的应该是“微秒”为单位了　）
非常感谢，有没有具体的解决方法？ [/quote] 我这儿根本“遇不到问题”、也无法确定造成你的那种问题的原因，那又何来“解决问题”的说法？ 你按我说的去验证一下，又不是什么很麻烦的事。 先得摸清楚情况再说啊。 要不你就搜索一下“GetTickCount64”，看看那些资料对你有帮助没。 [/quote]日斤斤计较[/quote] 打错了，非常感谢。 [/quote] 我在 Win7 SP1/64位 下，运行结果完全正常。 真不知道是不是楼主的使用方法（或者说“代码”）是不是有问题。
BIGGER2016 2016-06-04
  • 打赏
  • 举报
 回复
引用 8 楼 BIGGER2016 的回复:
[quote=引用 7 楼 Chen8013 的回复:] [quote=引用 4 楼 BIGGER2016 的回复:] [quote=引用 3 楼 Chen8013 的回复:] 楼主算错了吧，应该是“约24.855天”之后才变负数的。 出现这个问题，应该是系统的原因吧，我在“ Win7-32位专业版”中的运行结果也是正常的。 不知道有没有可能在64位系统中，它的含义“重新定义过”了？ 比如它返回的是“微秒”而不是毫秒（这是我乱猜的，很可能不对，但楼主可以用下面的方法试验一下：） 用一个Timer控件，设置它的周期为1秒（或100ms）； 比较一下每次GetTickCount()的返回值，看它的差值是多少。 （跟以前一样，差值单位应该是“毫秒”；或者它真的应该是“微秒”为单位了　）
非常感谢，有没有具体的解决方法？ [/quote] 我这儿根本“遇不到问题”、也无法确定造成你的那种问题的原因，那又何来“解决问题”的说法？ 你按我说的去验证一下，又不是什么很麻烦的事。 先得摸清楚情况再说啊。 要不你就搜索一下“GetTickCount64”，看看那些资料对你有帮助没。 [/quote]日斤斤计较[/quote] 打错了，非常感谢。
BIGGER2016 2016-06-04
  • 打赏
  • 举报
 回复
引用 7 楼 Chen8013 的回复:
[quote=引用 4 楼 BIGGER2016 的回复:] [quote=引用 3 楼 Chen8013 的回复:] 楼主算错了吧，应该是“约24.855天”之后才变负数的。 出现这个问题，应该是系统的原因吧，我在“ Win7-32位专业版”中的运行结果也是正常的。 不知道有没有可能在64位系统中，它的含义“重新定义过”了？ 比如它返回的是“微秒”而不是毫秒（这是我乱猜的，很可能不对，但楼主可以用下面的方法试验一下：） 用一个Timer控件，设置它的周期为1秒（或100ms）； 比较一下每次GetTickCount()的返回值，看它的差值是多少。 （跟以前一样，差值单位应该是“毫秒”；或者它真的应该是“微秒”为单位了　）
非常感谢，有没有具体的解决方法？ [/quote] 我这儿根本“遇不到问题”、也无法确定造成你的那种问题的原因，那又何来“解决问题”的说法？ 你按我说的去验证一下，又不是什么很麻烦的事。 先得摸清楚情况再说啊。 要不你就搜索一下“GetTickCount64”，看看那些资料对你有帮助没。 [/quote]日斤斤计较
舉杯邀明月 2016-05-31
  • 打赏
  • 举报
 回复
引用 4 楼 BIGGER2016 的回复:
[quote=引用 3 楼 Chen8013 的回复:] 楼主算错了吧，应该是“约24.855天”之后才变负数的。 出现这个问题，应该是系统的原因吧，我在“ Win7-32位专业版”中的运行结果也是正常的。 不知道有没有可能在64位系统中，它的含义“重新定义过”了？ 比如它返回的是“微秒”而不是毫秒（这是我乱猜的，很可能不对，但楼主可以用下面的方法试验一下：） 用一个Timer控件，设置它的周期为1秒（或100ms）； 比较一下每次GetTickCount()的返回值，看它的差值是多少。 （跟以前一样，差值单位应该是“毫秒”；或者它真的应该是“微秒”为单位了　）
非常感谢，有没有具体的解决方法？ [/quote] 我这儿根本“遇不到问题”、也无法确定造成你的那种问题的原因，那又何来“解决问题”的说法？ 你按我说的去验证一下，又不是什么很麻烦的事。 先得摸清楚情况再说啊。 要不你就搜索一下“GetTickCount64”，看看那些资料对你有帮助没。
赵4老师 2016-05-30
  • 打赏
  • 举报
 回复
使用GetTickCount的地方就考虑其返回值的有效范围和绕回0的可能。 https://msdn.microsoft.com/en-us/library/ms724408(VS.85).aspx
BIGGER2016 2016-05-30
  • 打赏
  • 举报
 回复
引用 2 楼 zhao4zhong1 的回复:
仅供参考：
#pragma comment(lib,"ntdll")
#pragma comment(lib,"user32")
#include <afxdisp.h>
#include <windows.h>
#include <winnt.h>
#include <stdio.h>
#include <memory.h>
#include <math.h>
BOOL r;
extern "C" NTSYSAPI NTAPI NtQuerySystemInformation(
    IN  UINT   SystemInformationClass,  // 信息类型
    OUT PVOID  SystemInformation,       // 缓冲指针
    IN   ULONG SystemInformationLength, // 缓冲的字节大小
    OUT PULONG ReturnLength OPTIONAL    // 写入缓冲的字节数
);
//第一个参数是请求的信息类型。这个参数可以有许多值。为了得到系统启动时间，我们只用其中的一个值：SystemTimeInformation（3）。
//如果，第一个参数是SystemTimeInformation，则第二个参数必须是一个SYSTEM_TIME_INFORMATION结构指针。
typedef struct {
    LARGE_INTEGER liKeBootTime;//系统被启动的时间（以1/10000毫秒计）。
    LARGE_INTEGER liKeSystemTime;
    LARGE_INTEGER liExpTimeZoneBias;
    ULONG         uCurrentTimeZoneId;
    DWORD         dwReserved;
} SYSTEM_TIME_INFORMATION;
SYSTEM_TIME_INFORMATION sti;
ULONG rl;
ULONG tk;
FILETIME ft;
//SYSTEMTIME lt;
//extern "C" ULONGLONG WINAPI GetTickCount64(void);
//ULONGLONG tk64;
ULONGLONG d497;
#define days_of_2_32ms 49.71026962962962962962962962963 //(2^32)/24/60/60/1000=49.71026962962962962962962962963
int main() {
    NtQuerySystemInformation(3,&sti,sizeof(sti),&rl);//3==SystemTimeOfDayInformation
    COleDateTime t,now;
    CString s,fmt="%Y-%m-%d %H:%M:%S";

    memcpy(&ft,&sti.liKeBootTime,sizeof(LARGE_INTEGER));
    t=COleDateTime(ft);
    s=t.Format(fmt);
    printf("                            Boot DateTime: %s\n",s);
    tk=GetTickCount();//The elapsed time is stored as a DWORD value. Therefore, the time will wrap around to zero if the system is run continuously for 49.7 days.
    now=COleDateTime::GetCurrentTime();
    t=now-COleDateTimeSpan((double)tk/86400000.0);
    s=t.Format(fmt);
    printf("Prev GetTickCount() Wrap to Zero DateTime: %s\n",s);
    s=now.Format(fmt);
    printf("     GetTickCount():%08X,Now DateTime: %s\n",tk,s);
    t=now+COleDateTimeSpan((double)(0xFFFFFFFFu-tk)/86400000.0);
    s=t.Format(fmt);
    printf("Next GetTickCount() Wrap to Zero DateTime: %s\n",s);
    return 0;
}
非常感谢，有没有具体的解决方法？
BIGGER2016 2016-05-30
  • 打赏
  • 举报
 回复
引用 3 楼 Chen8013 的回复:
楼主算错了吧，应该是“约24.855天”之后才变负数的。 出现这个问题，应该是系统的原因吧，我在“ Win7-32位专业版”中的运行结果也是正常的。 不知道有没有可能在64位系统中，它的含义“重新定义过”了？ 比如它返回的是“微秒”而不是毫秒（这是我乱猜的，很可能不对，但楼主可以用下面的方法试验一下：） 用一个Timer控件，设置它的周期为1秒（或100ms）； 比较一下每次GetTickCount()的返回值，看它的差值是多少。 （跟以前一样，差值单位应该是“毫秒”；或者它真的应该是“微秒”为单位了　）
非常感谢，有没有具体的解决方法？
舉杯邀明月 2016-05-30
  • 打赏
  • 举报
 回复
楼主算错了吧，应该是“约24.855天”之后才变负数的。 出现这个问题，应该是系统的原因吧，我在“ Win7-32位专业版”中的运行结果也是正常的。 不知道有没有可能在64位系统中，它的含义“重新定义过”了？ 比如它返回的是“微秒”而不是毫秒（这是我乱猜的，很可能不对，但楼主可以用下面的方法试验一下：） 用一个Timer控件，设置它的周期为1秒（或100ms）； 比较一下每次GetTickCount()的返回值，看它的差值是多少。 （跟以前一样，差值单位应该是“毫秒”；或者它真的应该是“微秒”为单位了　）
赵4老师 2016-05-30
  • 打赏
  • 举报
 回复
仅供参考：
#pragma comment(lib,"ntdll")
#pragma comment(lib,"user32")
#include <afxdisp.h>
#include <windows.h>
#include <winnt.h>
#include <stdio.h>
#include <memory.h>
#include <math.h>
BOOL r;
extern "C" NTSYSAPI NTAPI NtQuerySystemInformation(
    IN  UINT   SystemInformationClass,  // 信息类型
    OUT PVOID  SystemInformation,       // 缓冲指针
    IN   ULONG SystemInformationLength, // 缓冲的字节大小
    OUT PULONG ReturnLength OPTIONAL    // 写入缓冲的字节数
);
//第一个参数是请求的信息类型。这个参数可以有许多值。为了得到系统启动时间，我们只用其中的一个值：SystemTimeInformation（3）。
//如果，第一个参数是SystemTimeInformation，则第二个参数必须是一个SYSTEM_TIME_INFORMATION结构指针。
typedef struct {
    LARGE_INTEGER liKeBootTime;//系统被启动的时间（以1/10000毫秒计）。
    LARGE_INTEGER liKeSystemTime;
    LARGE_INTEGER liExpTimeZoneBias;
    ULONG         uCurrentTimeZoneId;
    DWORD         dwReserved;
} SYSTEM_TIME_INFORMATION;
SYSTEM_TIME_INFORMATION sti;
ULONG rl;
ULONG tk;
FILETIME ft;
//SYSTEMTIME lt;
//extern "C" ULONGLONG WINAPI GetTickCount64(void);
//ULONGLONG tk64;
ULONGLONG d497;
#define days_of_2_32ms 49.71026962962962962962962962963 //(2^32)/24/60/60/1000=49.71026962962962962962962962963
int main() {
    NtQuerySystemInformation(3,&sti,sizeof(sti),&rl);//3==SystemTimeOfDayInformation
    COleDateTime t,now;
    CString s,fmt="%Y-%m-%d %H:%M:%S";

    memcpy(&ft,&sti.liKeBootTime,sizeof(LARGE_INTEGER));
    t=COleDateTime(ft);
    s=t.Format(fmt);
    printf("                            Boot DateTime: %s\n",s);
    tk=GetTickCount();//The elapsed time is stored as a DWORD value. Therefore, the time will wrap around to zero if the system is run continuously for 49.7 days.
    now=COleDateTime::GetCurrentTime();
    t=now-COleDateTimeSpan((double)tk/86400000.0);
    s=t.Format(fmt);
    printf("Prev GetTickCount() Wrap to Zero DateTime: %s\n",s);
    s=now.Format(fmt);
    printf("     GetTickCount():%08X,Now DateTime: %s\n",tk,s);
    t=now+COleDateTimeSpan((double)(0xFFFFFFFFu-tk)/86400000.0);
    s=t.Format(fmt);
    printf("Next GetTickCount() Wrap to Zero DateTime: %s\n",s);
    return 0;
}
利剑出鞘2012 2016-05-30
  • 打赏
  • 举报
 回复
楼主解决了吗？我的在window7下，用MFC获取的也是负值
c语言编程GetTickCount,c语言计算时间方法---clock-GetTickCount-QueryPerformanceCounter
1、头文件time.h，函数clock()#include "stdafx.h"#include #include #include int main(void){int i,sum=0;clock_t start,finish;start=clock();for(i=1;i<10000000;i++){sum+=sqrt((float)i);}finish=clock();printf("...
获取操作系统启动到现在的时间---GetTickCount
直接上代码： #include #include // for GetTickCount #include // for Sleep int main() { int start = GetTickCount(); printf("%f\n", start / (3600000.0));// 操作系统运行到现在的时间 Sleep(2000); int end = GetTic
解决GetTickCount的问题
GetTickCount是一个api,它是反应到从开机到当前的毫秒数,这个很好.可以做一些短途的计时器. 比如说做服务器中对象池计时器,对象超过多少时间就自动释放对象. 但是GetTickCount也有一个麻烦的地方,就是在电脑运行了49.7天之后,数字会置0 ,然后从0开始.这样的话,简单的时间判断可能会造成49.7天后的bug,那么怎办呢?其实可以用一点小技巧就可以解决. ...
GetTickcount
GetTickcount函数:它返回从操作系统启动到当前所经过的毫秒数，常常用来判断某个方法执行的时间，其函数原型是DWORD GetTickCount(void)，返回值以32位的双字类型DWORD存储，因此可以存储的最大值是(2^32-1) ms约为49.71天，因此若系统运行时间超过49.71天时，这个数就会归0，MSDN中也明确的提到了:“Retrieves the number of m...
getTickCount()函数 区别GetTickCount()函数
getTickCount()函数 与GetTickCount()函数 转载文章 1.1. getTickCount() 实际上，该函数为opencv中的函数，该函数返回的值为自从某一时刻（比如计算机启动）开始，计算机总共经过的tick的次数，其需要结合getTickFrequency()函数使用，getTickFrequency()返回的是CPU在一秒钟内会发出的tick的次数，总体来说，该函数的精度较高，能够精确到1ms左右，获得时间的一个例子如： double t = (double)getTickCo
VB基础类

7,763

社区成员

197,609

社区内容

发帖
与我相关
我的任务
社区描述
VB 基础类
社区管理员
  • VB基础类社区
加入社区
  • 近7日
  • 近30日
  • 至今

加载中

查看更多榜单
社区公告
暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章