`System.Timers.Timer` starts when in disabled state after setting interval value

[DoctorMarvin21]

Description

I've found interesting behavior of System.Timers.Timer when AutoReset = false. Looks like it's there for a while.

When Timer elapsed at least once, it starts automatically when setting any new Interval value even though Enabled is false

Reproduction Steps

const int TimerInterval = 100;
int elapsedTimes = 0;

using var timer = new System.Timers.Timer { AutoReset = false, Interval = TimerInterval };

timer.Elapsed += (s, e) =>
{
    elapsedTimes++;
    Console.WriteLine($"I'm elapsed {elapsedTimes} time(s)");
};

Console.WriteLine($"Starting timer normally");
timer.Start();
Thread.Sleep(TimerInterval * 2);

Console.WriteLine($"Setting timer interval when timer elapsed");
timer.Interval = TimerInterval;
Thread.Sleep(TimerInterval * 2);

Expected behavior

Output of the code snippet is:
Starting timer normally
I'm elapsed 1 time(s)
Setting timer interval when timer elapsed

Actual behavior

Output of the code snippet is:
Starting timer normally
I'm elapsed 1 time(s)
Setting timer interval when timer elapsed
I'm elapsed 2 time(s)

Regression?

I tracked code to the early .NET Framework versions. Looks like it has always been an issue.

Known Workarounds

Use System.Threading.Timer instead of System.Timers.Timer.

Configuration

Tested on .NET 8 and Windows 10.

Other information

There are inconsistent checks for current timer state. Property Enabled setter checks for _enabled field state and if _timer is not null, but Interval property only checks if _timer is not null. ThenMyTimerCallback(object? state) sets _enabled to false without disposing and/or setting _timer to null.

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

I've found interesting behavior of System.Timers.Timer when AutoReset = false. Looks like it's there for a while.

1. When Timer elapsed at least once, it starts automatically when setting any new Interval value even though Enabled is false
2. Memory leak when starting timer over after it's elapsed (Elapsed => Start => Elapsed => Start, etc...)

I attached code for the first case as memory leak is incredibly slow. Please, check Other Information section below.

Reproduction Steps

const int TimerInterval = 100;
int elapsedTimes = 0;

using var timer = new System.Timers.Timer { AutoReset = false, Interval = TimerInterval };

timer.Elapsed += (s, e) =>
{
    elapsedTimes++;
    Console.WriteLine($"I'm elapsed {elapsedTimes} time(s)");
};

Console.WriteLine($"Starting timer normally");
timer.Start();
Thread.Sleep(TimerInterval * 2);

Console.WriteLine($"Setting timer interval when timer elapsed");
timer.Interval = TimerInterval;
Thread.Sleep(TimerInterval * 2);

Expected behavior

Output of the code snippet is:
Starting timer normally
I'm elapsed 1 time(s)
Setting timer interval when timer elapsed

Actual behavior

Output of the code snippet is:
Starting timer normally
I'm elapsed 1 time(s)
Setting timer interval when timer elapsed
I'm elapsed 2 time(s)

Regression?

I tracked code to the early .NET Framework versions. Looks like it has always been an issue.

Known Workarounds

Use System.Threading.Timer instead of System.Timers.Timer.

Configuration

Tested on .NET 8 and Windows 10.

Other information

There are inconsistent checks for current timer state. Property Enabled setter checks for _enabled field state, but Interval property checks if _timer is not null.

Actual problem comes in MyTimerCallback(object? state) when it sets _enabled to false without disposing and setting _timer to null (if _autoReset is false).

Author:	DoctorMarvin21
Assignees:	-
Labels:	area-System.Threading, untriaged
Milestone:	-

[DoctorMarvin21]

After exploring Timer code a little longer...

1. Same bug can be reproduced with changing AutoReset property as it's implementation is almost the same as in Interval property
2. You can't "fix" the timer by stopping it as Enabled property setter coded well and checks for current _enabled field value

Here's the updated reproduction scenario:

const int TimerInterval = 100;
int elapsedTimes = 0;

using var timer = new System.Timers.Timer { AutoReset = false, Interval = TimerInterval };

timer.Elapsed += (s, e) =>
{
    elapsedTimes++;
    Console.WriteLine($"I'm elapsed {elapsedTimes} time(s)");
};

Console.WriteLine("Starting timer normally");
timer.Start();
Thread.Sleep(TimerInterval * 2);

Console.WriteLine($"Timer Enabled state is {timer.Enabled}");

Console.WriteLine("Forcibly setting stop even though timer is disabled");
timer.Stop();

Console.WriteLine("Setting timer interval when timer elapsed");
timer.Interval = TimerInterval;
Thread.Sleep(TimerInterval * 2);

Console.WriteLine("Resetting Auto-Reset property value");
timer.AutoReset = true;
timer.AutoReset = false;
Thread.Sleep(TimerInterval * 2);

Output is:
Starting timer normally
I'm elapsed 1 time(s)
Timer Enabled state is False
Forcibly setting stop even though timer is disabled
Setting timer interval when timer elapsed
I'm elapsed 2 time(s)
Resetting Auto-Reset property value
I'm elapsed 3 time(s)

[DoctorMarvin21]

Also, I think it's System.ComponentModel rather than System.Threading. @ericstj, am I right?

Tagging subscribers to this area: @dotnet/area-system-componentmodel
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

I've found interesting behavior of System.Timers.Timer when AutoReset = false. Looks like it's there for a while.

When Timer elapsed at least once, it starts automatically when setting any new Interval value even though Enabled is false

Reproduction Steps

const int TimerInterval = 100;
int elapsedTimes = 0;

using var timer = new System.Timers.Timer { AutoReset = false, Interval = TimerInterval };

timer.Elapsed += (s, e) =>
{
    elapsedTimes++;
    Console.WriteLine($"I'm elapsed {elapsedTimes} time(s)");
};

Console.WriteLine($"Starting timer normally");
timer.Start();
Thread.Sleep(TimerInterval * 2);

Console.WriteLine($"Setting timer interval when timer elapsed");
timer.Interval = TimerInterval;
Thread.Sleep(TimerInterval * 2);

Expected behavior

Output of the code snippet is:
Starting timer normally
I'm elapsed 1 time(s)
Setting timer interval when timer elapsed

Actual behavior

Output of the code snippet is:
Starting timer normally
I'm elapsed 1 time(s)
Setting timer interval when timer elapsed
I'm elapsed 2 time(s)

Regression?

I tracked code to the early .NET Framework versions. Looks like it has always been an issue.

Known Workarounds

Use System.Threading.Timer instead of System.Timers.Timer.

Configuration

Tested on .NET 8 and Windows 10.

Other information

There are inconsistent checks for current timer state. Property Enabled setter checks for _enabled field state and if _timer is not null, but Interval property only checks if _timer is not null. ThenMyTimerCallback(object? state) sets _enabled to false without disposing and/or setting _timer to null.

Author:	DoctorMarvin21
Assignees:	-
Labels:	area-System.ComponentModel, untriaged
Milestone:	-

[ericstj]

I agree with @DoctorMarvin21 that the behavior appears to have been there a while. This isn't the sort of behavior we're likely to change since it's very observable - but we would welcome improvements to the documentation.

@DoctorMarvin21 can you have a look at https://learn.microsoft.com/en-us/dotnet/api/system.timers.timer.interval?view=net-8.0 and see if you think it could be improved? One thing I noticed was:

If the interval is set after the Timer has started, the count is reset. For example, if you set the interval to 5 seconds and then set the Enabled property to true, the count starts at the time Enabled is set. If you reset the interval to 10 seconds when count is 3 seconds, the Elapsed event is raised for the first time 13 seconds after Enabled was set to true.

That seems to cover this scenario. If you'd like to improve the docs, have a look in https://github.com/dotnet/dotnet-api-docs/blob/main/xml/System.Timers/Timer.xml

[DoctorMarvin21]

@ericstj, thanks for pointing out that Interval property has detailed documentation. And this documentation desribes this scenario and suggest to apply workaround:

If Enabled and AutoReset are both set to false, and the timer has previously been enabled, setting the Interval property causes the Elapsed event to be raised once, as if the Enabled property had been set to true. To set the interval without raising the event, you can temporarily set the Enabled property to true, set the Interval property to the desired time interval, and then immediately set the Enabled property back to false.

I surely agree that changing so old code is a bad idea. On the other hand, that is so obvious a bug that it's extremely confusing.

[DoctorMarvin21]

On the other hand, I'm not sure that I agree with statement that it's very observable. Even though I have over 10 years of experience with .NET and faced some controversial behaviors, I never saw such an obvious bug and didn't expect it to be in Microsoft code, so I first needed to recheck all other possible cases. Finally, this bug caused false-negative results in hardware test scenarios with a low reproduction rate.
I understand that Microsoft tries to keep .NET Framework code as it is to make migrations flawless, but before I'll close this (as this bug is obviously documented well at least for Interval). @ericstj, what do you think about creating proposal for breaking change to fix this?