Troubleshooting Timer -- When will it Elapse?

[Guest]

I have a Timer that I set to go off once a day, but it frequently fails! In
order to debug I would like to be able to check, at any moment, whether the
Timer is enabled and when it will next Elapse.

Is there any way -- whether in my code, or in the O/S -- to determine when a
Timer is scheduled to Elapse?

 

[PokerMan]

The timer interval property would tell you when it should be going off.

A Console.WriteLine("Timer fired""); in the method listening for the
timer.elapsed event would be a good debug, and tell you if and when it
fires.

It 'frequently' failes ....so it always fails, or sometimes fails. If
sometimes then look at what else changes on those moments. Write out log
files, catch errors etc.

With how simple a timer is, i would expect the timer is firing but sometimes
the code it triggers fails not the timer itself. So when it fails, what
happens?

 

[Guest]

Trying to find the "interval" property I realized that I am using
System.Threading.Timer, not System.Timers.Timer. Looks like there are
significant differences, including much less info available on the Threading
Timer. (I found the following article that goes into the differences:
http://msdn.microsoft.com/msdnmag/issues/04/02/TimersinNET/ )

I construct a Threading.Timer with TimerCallback delegate that begins by
writing something to the console. The failure is that when the timer was
supposed to go off nothing appears on the console.

Granted, there's a lot of other code running in this process, so there's
plenty of room for things to go wrong. And the fact that I want this timer
to callback on the order of 24 hours makes it hard to reproduce anything.
But I don't see how I can troubleshoot a failure on a Threading.Timer like
this without being able to see any of its properties!

So what I'm asking is how I can find any details on a Threading.Timer so I
can confirm -- as my other classes do their business -- that it is still
enabled, scheduled, and pointing at the right delegate.

 

[PokerMan]

Change to a normal Timers.Timer.......sounds like your present timer never
fires and i am guessing you dont need a thread timer?

if it never fires, then it always doesnt work, not 'frequently' doesnt. Once
you get your timer firing your problem is sovled?

You are assigning your delegate correctly to the event yes?

myTimer.Elapsed += OnTimerElapsed; //.net 2 syntax

 

[Guest]

It has succeeded on two days and failed on four.

I'll try a Timers.Timer, but I could still end up with this same problem --
even if I see the Interval and delegate set correctly, if I can't confirm
it's scheduled in the runtime or O/S I can't diagnose the point of failure.

 

[PokerMan]

I used to have a programme i ran every day as a backup of some work. I
ddin't use an internal timer. Just had the programme when run, do a back up.
So i used the os task scheduler, to run my app at midnight. This sounds like
a problem you'd solve outside of your app?

 

[John Vottero]

Are you sure that you're keeping a reference to the timer? If you don't,
the timer will work until it's garbage collected.

 

[Guest]

It's a static member of a class that is not IDisposable, so I assume it can't
be GC'd.

 

[Guest]

I definitely prefer to use the Windows Scheduler for daily tasks, but that
would be a bit of a kludge in this case because I'm trying to invoke event
handlers in a specific running process instance.

If I can't solve this Mystery of the Dying Timer I may do something like
that. But I'm sure I'm not the first or last person who wants to come up
with a method of debugging long-duration Timers.