Hello all, I have an application that has been running from several years now without major issues. Now the customer has updated one of his systems from Win10 to Windows 11 (version 24H2, build 26100.6899) and the application has started to raise strange errors that seem to originate on the value returned by Timer () function.
The application is a multithreaded app developed in CVI2017 and running in dozen of applications with PCs from different brands. The issue originates in a thread spawned from the main thread by means of
cmtErr = CmtScheduleThreadPoolFunction (DEFAULT_THREAD_POOL_HANDLE, TestSurvey, NULL, &threadID);
if (cmtErr < 0) {
line = __LINE__;
goto Error;
}
The skeleton of the thread function is this one:
int CVICALLBACK TestSurvey (void *functionData)
{
static int onTest = 0;
double tini = Timer ();
while (!endThread) {
xt = Timer (); // <=== Save Timer () value
if (((xt - tini) > (testTime * 1.2))) {
// Warn a sync alarm with remote device
}
if (GetInQLen (com) >= 13) {
// Read and decode messages from the remote device
comChk (ComRd (com, msg, 13));
// Dump messages to disk together with 'xt' variable
// Process remote device data
// At test start:
if (!onTest) {
// Do stuff
tini = Timer ();
onTest = 1;
}
// At test end signaled by remote device:
onTest = 0:
}
Loop: ;
}
Error:
// Clean up stuff
// ...
return 0;
}
As you can see, on each iteration I save Timer () value and originate a warning if the remote device does not send a test end signal within expected test time + 20%.
I also note down all messages received from remote device together with internal variables values including 'xt' which holds the Timer () value saved previously.
By examining those raw data I see that Timer () value has inconsistent jumps in value not related to expected thread looping time (and surely not coherent with the real operation of the machine). Here is an abstract of raw data file which evidences the anomaly (Timer () lies in the column following '0d' values):
0x31 0c 8c 00 00 00 00 02 0c 7d 00 14 0d 133144762.66 128849795.31 5.0 - 49 2956 0 0, 2 3197 20
0x31 0c 8c 00 00 00 00 03 08 94 06 11 0d 133144762.72 133144762.66 5.0 - 49 2956 0 0, 3 1940 1553
0x31 0c 8c 00 00 00 00 04 07 fd 07 49 0d 133144762.79 133144762.72 5.0 - 49 2956 0 0, 4 1789 1865
0x31 0c 8c 00 00 00 00 05 08 03 07 31 0d 133144762.79 133144762.72 5.0 - 49 2956 0 0, 5 2051 1841
0x61 00 00 07 fd 00 00 00 39 fb ad ec 0d 137439730.11 133144762.72 5.0 - 97 0 1789 0, 0 30/10 15:56:57 <<== ***
0x31 0c 8c 00 00 00 00 05 07 ed 07 3d 0d 137439730.11 133144762.72 5.0 - 49 2956 0 0, 5 1773 1853
0x46 0c 73 06 d6 07 53 64 0c d7 00 00 0d 137439730.83 137439730.83 5.0 - 70 3187 1494 1875, 100 3031 0
0x31 0c 8c 00 00 00 03 20 00 00 00 04 0d 158914568.64 133144762.72 5.0 - 49 2956 0 3, 32 0 4
0x31 0c 8c 00 00 00 03 20 00 00 00 04 0d 158914568.66 158914568.64 5.0 - 49 2956 0 3, 32 0 4
As you can see, in the highlighted row the timer value is 137439730.11 with a jump of over 4-million-seconds from the previous record !! This fires the sync error which is causing lots of troubles to my customer.
Now questions are:
- Has anybody observed a similar problem?
- What can be causing this?
- Will other methods to check time value be affected as well (e.g. GetTickCount() SDK function) ?
- Can updating to a more recent run-time engine patch this problem?
