While reading this question and its replies Environment.TickCount is not enough I got confused.
They are saying that Environment.TickCount works for 48-49 days (OP) (and @Cody Gray says 25 days), but its an int value, so can store up to 2,147,483,647.
Now, 1 millisecond contains 10,000 ticks, that means it can hold up to 214,748.3+ milliseconds which is 214+ seconds only, which is less than 4 minutes.
Am I missing something?
Btw, now there is Environment.TickCount64 which provides a 64bit value.
For starters, TickCount returns milliseconds, not ticks in the sense of DateTime.Ticks. It does so with a precision the same as the system timer, which is about 10-16 milliseconds.
The documentation explains how the value cycles:
Because the value of the TickCount property value is a 32-bit signed integer, if the system runs continuously, TickCount will increment from zero to Int32.MaxValue for approximately 24.9 days, then jump to Int32.MinValue, which is a negative number, then increment back to zero during the next 24.9 days. You can work around this issue by calling the Windows GetTickCount function, which resets to zero after approximately 49.7 days, or by calling the GetTickCount64 function.
Doing the maths, we find out that 24.9 days is 2,151,360,000 (compared to Int.MaxValue of 2,147,483,647). MaxValue + |MinValue| yields 4294967295, which if divided by 86400000 milliseconds (1 day) yields about 49.7 days, as the documentation suggests.