VB.Net Timer Issue

  • Thread starter Thread starter igor
  • Start date Start date
I

igor

I have recently discovered that the system.Timers.Timer from.Net
Framework v1.1 is not reliable when used on Windows 2003 server. When
incorporated into a Windows Service, the timer_elapsed event will stop
executing after 30 to 40 days. After learning this, I found the same
issue had been documented in the the System.Threading.Timer class as
well. This limits my options for having a timer based windows service
using the .net framework.

I can convert the project to .Net Framework 2.0, but I am unsure
whether or not this will resolve the issue.

Any ideas would be helpful.

Thank you.
 
Why do I think the actual problem occurs at 49.7 days. This is a known
issue with 32 bit windows (2^31-1 milliseconds is about 49.7 days). It's
not that the timer service stops, it's that the internal timers wrap back to
zero and the trigger doesn't occur anymore. The work around is to track
what day or month it is (numeric day of month or month of year is
sufficient) Here's an example workaround.

Module Module1
Public ReadOnly Interval As New System.TimeSpan(1, 0, 0)
Public t As New System.Timers.Timer(Interval.Milliseconds)
Public MonthNumber As Integer = Today.Month

Sub Main()
AddHandler t.Elapsed, AddressOf t_Elapsed
t.Start()
End Sub

Private Sub t_Elapsed(ByVal sender As Object, ByVal e As
System.Timers.ElapsedEventArgs)
If MonthNumber <> Today.Month Then
RemoveHandler t.Elapsed, AddressOf t_Elapsed
MonthNumber = Today.Month
t = New System.Timers.Timer(Interval.Milliseconds)
AddHandler t.Elapsed, AddressOf t_Elapsed
t.Start()
End If

' Proceess timer event
End Sub

End Module


Mike Ober.
 
Michael,
Thank you for your help. I have a couple of questions. Why is it
that resetting the timer variable to a new instance every month fixes
the issue? If the System.Timers.Timer class elapsed events fire when
the internal timer reaches a specific future time value, than wouldn't
any elapsed event set to fire after the 49.7 day point fail?

As I understand it, the internal timer you mention is the timer which
starts when the server is rebooted and increments until the 49.7 day
point is reached.

Thanks again
 
I'm guessing here on the solution as it sounds like the 32 bit millisecond
rollover. As for why the creation of a new timer - this should initialize
the timer to "0" and then it should be able to run for 49.7 days. When
windows hits 49.7 days (2^31-1) milliseconds, it simply rolls over to 0.
Windows 95 would actually become unstable at this point (if it hadn't
already done so from usage). As for your question, I don't have an answer
since for longer time periods I use the task manager to start an application
at a specific time and not application code.

Mike.
 
Why do I think the actual problem occurs at 49.7 days. This is a
known issue with 32 bit windows (2^31-1 milliseconds is about 49.7
days). It's not that the timer service stops, it's that the internal
timers wrap back to zero and the trigger doesn't occur anymore. The
work around is to track what day or month it is (numeric day of month
or month of year is sufficient) Here's an example workaround.
Click to expand...

I recall seeing a KB article about this... do you happen to have any links
to any MS documentation?


I did find an article Joel on Software linked - Southern California's ATC
servers crashed after 49.7 days.

But I thought MS fixed this in a service pack?
 
I have recently discovered that the system.Timers.Timer from.Net
Framework v1.1 is not reliable when used on Windows 2003 server. When
incorporated into a Windows Service, the timer_elapsed event will stop
executing after 30 to 40 days. After learning this, I found the same
issue had been documented in the the System.Threading.Timer class as
well. This limits my options for having a timer based windows service
using the .net framework.

I can convert the project to .Net Framework 2.0, but I am unsure
whether or not this will resolve the issue.
Click to expand...


Seems like there is a hotfix:

..NET 1.1
http://support.microsoft.com/kb/843561/en-us
 
igor said:
I have recently discovered that the system.Timers.Timer from.Net
Framework v1.1 is not reliable when used on Windows 2003 server. When
incorporated into a Windows Service, the timer_elapsed event will stop
executing after 30 to 40 days. After learning this, I found the same
issue had been documented in the the System.Threading.Timer class as
well. This limits my options for having a timer based windows service
using the .net framework.
Click to expand...

Only use the Timer to sidestep the Service's OnStart routine.
Within your "main processing" loop, use Threading.Sleep() instead, as in

Imports System.Threading

Private _bStopRequested as Boolean
Private _bStopped as Boolean

Sub OnStart()
tmrBoot.Start()
End Sub

Sub OnStop()
_bStopRequested = True
Do While Not _bStopped
Thread.Sleep(500)
Loop
End Sub

Sub tmrBoot_Timer()
tmrBoot.Stop()

Me.Run()
End Sub

Sub Run()
_Stopped = False
Do While Not bStopRequested
' Do the real work here

Thread.Sleep(1000)
Loop
_Stopped = True
End Sub

HTH,
Phill W.
 
No links to documentation. Just my memory that this was a problem with
Windows 95 and early versions of NT prior to one of the NT4 service packs.
As far as I know, the server crash issue was fixed in Windows 98 and 2000.
However, the underlying problem itself - 32 bit timer counters rolling over
after 49.7 days will not be resolved until the transition to 64 bit
computing is complete. Then the rollover time will be measured in
centuries.

Mike.
 
No links to documentation. Just my memory that this was a problem
with Windows 95 and early versions of NT prior to one of the NT4
service packs. As far as I know, the server crash issue was fixed in
Windows 98 and 2000. However, the underlying problem itself - 32 bit
timer counters rolling over after 49.7 days will not be resolved until
the transition to 64 bit computing is complete. Then the rollover
time will be measured in centuries.
Click to expand...

Here's the SP: http://support.microsoft.com/kb/843561/en-us
 
You would think MS would have caught this during .NET 1.1 development since
the OS teams had already addressed and fixed problems with the same
underlying tickcount rollover.

Mike.
 
You would think MS would have caught this during .NET 1.1 development
since the OS teams had already addressed and fixed problems with the
same underlying tickcount rollover.
Click to expand...

I noticed in Microsoft's KB that .NET CF 2.0 was still affected until a
recent SP ;-)
 
Back
Top