c# Timer -- .NET performance counters on this system are corrupt

[Zytan]

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

[Peter Duniho]

On Fri, 27 Jun 2008 15:00:35 -0700, Zytan <zy**********@g mail.comwrote:

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.

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

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...are-corrupted/

http://support.microsoft.com/kb/300956

Maybe something in there will help.

Either way, if and when you get your perf counters fixed, can you
reproduce the problem at will? You are vague about which Timer class
you're using, 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).

Pete

[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

[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

[Peter Duniho]

On Sat, 28 Jun 2008 12:38:52 -0700, Zytan <zy**********@g mail.comwrote:

[...]

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

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.

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

Pete

[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

[Peter Duniho]

On Mon, 30 Jun 2008 13:43:48 -0700, Zytan <zy**********@g mail.comwrote:

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.

Oddly enough, even after all these years I have never bothered to look
into that. :) 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.

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.

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

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

[Peter Duniho]

On Wed, 02 Jul 2008 12:47:48 -0700, Zytan <zy**********@g mail.comwrote:

[...]
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.

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

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.

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