I made a program using the Timer class, and I start the timer with
Timer.Start(), but don't stop it with Timer.Stop(), and I assumed this
was ok, but, Process Explorer informs me, after running it about 10 or
20 times:

---------------------------
Process Explorer
---------------------------
The .NET performance counters on this system are corrupt.
Run Exctrlst from the Microsoft Windows Resource Kit to repair them.
---------------------------
OK
---------------------------

Is this because Timer can't clean itself up? (And I have no idea what
Exctrlst is.)

Zytan

Thanks for the reply, Pete.


> Does the problem resolve itself? For example, if you reboot? Or is it
> persistent?

The error only appeared once, and I rebooted, and I have not seen it
since. Although, I have not done much development since, so this
doesn't mean much.

I should NOTE that I've used the System.Windows.Forms.Timer before,
many times, in this exact manner (letting the form destruct it without
telling it to stop explicitly), and I have never seen this error
before.

However, it seemed strange that it appears right after I about 20 or
30 test runs of a really, really simple application that does nothing
more than making a System.Windows.Forms.Timer, and uses it to update a
rich text box. Note that it didn't appear right away, but only after
30 or 60 minutes of development and test running the program.


> If it's persistent, you may want to read through these links:
>
> http://blogs.msdn.com/mikedodd/archi...17/243799.aspx
> (Note the date...you'll want to look in your .NET installation for the
> most up-to-date .ini file, using the blog entry as a guide)
>
> http://channel9.msdn.com/forums/Tech...ounters-are-co...
>
> http://support.microsoft.com/kb/300956

Thanks for these links. I will update this thread if the problem
continues, with further information. As of yet, I specifically stop
the timer before the form closes, to see if this will resolve the
situation.


> Either way, if and when you get your perf counters fixed, can you
> reproduce the problem at will?

No, I cannot. I will mess with this and see if I can do this, and let
you know.


> You are vague about which Timer class
> you're using,

System.Windows.Forms.Timer


> but I don't really see why failing to stop an instance of
> any of the Timer classes would corrupt your performance counters. That
> sounds like a bug to me (in .NET).

I agree.

Zytan

> > Either way, if and when you get your perf counters fixed, can you
> > reproduce the problem at will?
>
> No, I cannot. I will mess with this and see if I can do this, and let
> you know.

I cannot repro the issue. Perhaps it takes some time before Process
Explorer discovers it, I am not sure. I'll post back with any
findings.

Zytan

> > System.Windows.Forms.Timer
>
> In that case I am definitely skeptical that your corrupted counters have
> anything to do with the use of the Timer class.
> System.Windows.Forms.Timer uses WM_TIMER, if I recall correctly, and that
> should not have anything to do with the performance counters.

That would make sense, but I am uncertain how WM_TIMER is
implemented. The multi-media timer is probably good enough, though,
it normally has 0.001 seconds accuracy, which is all WM_TIMER has
through its invocation, so it probably uses the MM timer.


> Please do keep us updated if you see it happen again and you can determine
> more specifics about the issue.

I have not seen it appear since. And, I am not running ANY software
that uses the performance counters, so it's just strange that I got
the error at all. The only thing remotely linked to it was the usage
of System.Windows.Forms.Timer for 30 minutes just before it
occurred...

Thanks, Pete.

Zytan

> > That would make sense, but I am uncertain how WM_TIMER is
> > implemented.
>
> Oddly enough, even after all these years I have never bothered to look
> into that.

Me neither!


> However, the important thing to know is that it's an
> unmanaged window message having zero to do with .NET. Since it's
> specifically the ".NET performance counters" that were corrupted, there
> really should be no connection.

Agreed.


> > The multi-media timer is probably good enough, though,
> > it normally has 0.001 seconds accuracy, which is all WM_TIMER has
> > through its invocation, so it probably uses the MM timer.
>
> I doubt it. Actually, let me rephrase that...I know for a fact that the
> winmm timer is different from the WM_TIMER timer. One particular
> difference is that the winmm timers have better accuracy, in that WM_TIMER
> is subject to the whims of the Windows thread scheduler, while the winmm
> timer is implemented in a way to minimize the difference.

Ah, didn't know that. I assumed they were the same timer.

But, WM_TIMER has to be based on the MM timer or the high performance
counter, one or the other, unless there's other counters I don't know
about (is the 18.2 Hz clock another counter, or is it the MM timer?).
I just assumed WM_TIMER was based on the MM timer.


> I wish I could recall more details, but my knowledge in that area "has
> been lost to the sands of time", as they say.

I'm not going to worry about this. If the problem crops up again,
I'll report back with findings, and do some more digging, but until
then, I have more important things to worry about

Thanks, Pete

Zytan

> WM_TIMER predates winmm for sure (the multimedia timer was introduced to
> address some of the limitations of WM_TIMER).

Ah.

> As I said, I don't actually know the specific implementation of WM_TIMER.
> But I see no reason that it _must_ be based on some other timer that you
> know about. It's entirely possible that Windows handles WM_TIMER
> independently of any other timers.

Yes, true.

Zytan

> System.Windows.Forms.Timer uses WM_TIMER, if I recall correctly.....

Just ran across this today:

http://msdn.microsoft.com/en-us/libr...rms.timer.aspx
"The Windows Forms Timer component is single-threaded, and is limited
to an accuracy of 55 milliseconds. If you require a multithreaded
timer with greater accuracy, use the Timer class in the System.Timers
namespace."

It sounds like it's using the 18.2 Hz clock... that's once every 55
ms.

Zytan