Unexepected output from Timeout command

[Squashman]

Little background: Every second Saturday of the month, our server support team manually patches any servers that are mission critical. When they patch my servers they have instructions to run a batch file to startup all of my automation tasks. Today somehow that batch file gave me some unexpected output from the TIMEOUT command. I have roughly 200 tasks on each of my servers that startup and run in the background from this batch file. After every 20+ tasks I use the timeout command to give those tasks some time to fully startup.

I get alerts from the server if all the tasks are not started. When I logged onto the server I saw the batch file still waiting for the first timeout command to finish counting down.

This is what I saw in the console.

Code: Select all

C:\Users\username\Desktop>TIMEOUT /T 30

Waiting for 4294920386, press a key to continue ...

Server was rebooted roughly around 8:30 am. I finally hit the enter key around 9:40 pm. Going to assume it started counting down from 4294967296.

I am baffled by this considering the help file from the TIMEOUT command.

Code: Select all

Parameter List:
    /T        timeout       Specifies the number of seconds to wait.
                            Valid range is -1 to 99999 seconds.

[dingdong]

Little background: Every second Saturday of the month, our server support team manually patches any servers that are mission critical. When they patch my servers they have instructions to run a batch file to startup all of my automation tasks. Today somehow that batch file gave me some unexpected output from the TIMEOUT command. I have roughly 200 tasks on each of my servers that startup and run in the background from this batch file. After every 20+ tasks I use the timeout command to give those tasks some time to fully startup.

I get alerts from the server if all the tasks are not started. When I logged onto the server I saw the batch file still waiting for the first timeout command to finish counting down.

This is what I saw in the console.

Code: Select all

C:\Users\username\Desktop>TIMEOUT /T 30

Waiting for 4294920386, press a key to continue ...

Server was rebooted roughly around 8:30 am. I finally hit the enter key around 9:40 pm. Going to assume it started counting down from 4294967296.

I am baffled by this considering the help file from the TIMEOUT command.

Code: Select all

Parameter List:
    /T        timeout       Specifies the number of seconds to wait.
                            Valid range is -1 to 99999 seconds.

What happens if you include

Code: Select all

/nobreak

?

[aGerman]

The value indicates that the internal countdown uses a variable of type unsigned int/long. Basically this has nothing to do with the restriction for the user to pass a maximum value of 99999. After conversion from text to a signed int it simply checks if it was -2 < n < 100000 and either continues or throws an error.

It's hard to guess what happened. Most likely it didn't stop counting down at 0 for whatever reason. Instead it decreased 0 again that leads to become UINT_MAX/ULONG_MAX (4294967295) for these unsigned types. Why this happened is something that I can't even guess. Having a look into the executable I found wcstol (string to signed long int), wcstod (string to floating point number with double precision), and wcstoul (string to unsigned long int). Only the first makes sense to convert the passed argument. The latter would be also possible. In case they convert to a floating point number this could have been the culprit. Comparisions (especially equality and inequality comparisions) of floating point numbers are doomed to failure.

Steffen

[penpen]

I played a little bit with "timeout.exe" and i couldn't fully reproduce that behaviour.
But there is a way to produce output of the high numbers.

Start "timeout /t 30" in a command shell and immediately mark some of its lines (needs quickedit enabled) before the screen info message is displayed the first time; the screen then should look somehow like this:

Code: Select all

Z:\>timeout /t 30 /nobreak
_

Note: the "_" marks the cursor position.

Then wait the 30 seconds and hit the return-key (doesn't work with any other key), then you often should see (doesn't work always, but for > 90% of the time):

Code: Select all

Z:\>timeout /t 30

Gewartet wird 4294967263n. Drücken Sie STRG+C, um den Vorgang zu beenden...

Z:\>_

The counter always stopped, even when using "timeout /t 30 /nobreak".

Sidenote:
You better should use "timeout /t 0 /nobreak" to avoid waiting too long... .


penpen

Edit: Added "Sidenote: ...".

[aGerman]

Confirmed on Win10. I was able to fully reproduce this behavior (actually penpen already did).

Code: Select all

@echo off &setlocal
echo %time%
timeout /t 30
echo %time%
pause

Output

Code: Select all

22:18:38,36

Gewartet wird 4294967274n. Weiter mit beliebiger Taste...
22:19:30,77
Drücken Sie eine beliebige Taste . . .

As you can see timeout runs as long as something was marked in the window. The second echo was not executed before hitting Enter.
The difference between 4294967274 and 0 (type overflow at 4294967296) is 22, +30 seconds timeout is 52 seconds. The same as the difference of the two time values.

Steffen

[jeb]

There is also a flaw in the timeout implementation, when the time/date is changed while the countdown is running, then the remaining seconds are changed.
Obviously the remaining seconds is calculated by something like
remaing_sec=stop_timestamp - current_time

On a Windows7 you can produce simply big number like 4294888777, by advance the day.
But Win7 also stops immediatly in this case.

jeb

[penpen]

Sometimes i don't see the obvious... (== changing the date) - but now (thx to jeb) i also played with changing the date.

I used one command shell window to execute "timeout /T 30 /NOBREAK", and a second one (with admin rights) to change the date (typically after i started timeout).

If you change the date from today to the 19th January 2039 or later, then the counter just stops counting down (on my win10) and waits (as it seems) forever:

Code: Select all

Z:\>timeout /T 30

Gewartet wird 1497278652n. Weiter mit beliebiger Taste...

If you then start "timeout /T 30" again, then the counter is still not counting (30 seconds forever)!
The timeout.exe only finishes when using the value "0".

After changing the date to 18.01.2038 (or earlier), then the counter immediately stops:

Code: Select all

Z:\>timeout /T 30 /NOBREAK

Gewartet wird 2147527477n. Drücken Sie STRG+C, um den Vorgang zu beenden...

If you then restart timeout, the counter sometimes jumps for whatever reason from 30 to ~650163494 (and continues counting):

Code: Select all

Z:\>timeout /T 30 /NOBREAK

Gewartet wird 650163494en. Drücken Sie STRG+C, um den Vorgang zu beenden...

I'm not fully sure, but i suspect that this behaviour may be caused by changing the date dozens of times, so maybe some signals may have occured too late - although, from the systems viewpoint, they are received earlier than sent (or vice versa) .

But if you use a date when the counter is running (without anything suspicious has happened), then you could chaynge the date to the 1th January 1980 (earliest possible date for my win10), and the counter is also still running:

Code: Select all

Z:\>timeout /T 30 /NOBREAK

Gewartet wird 1831852813n. Drücken Sie STRG+C, um den Vorgang zu beenden...

Sidenotes:
The behaviour is the same without using "/NOBREAK".
I used these date settings in the admin window (date format: DD-MM-YY):

Code: Select all

date 19-01-2038
date 18-01-2038
date 01-01-1980
date 12-06-2017

penpen