I'm debugging a C#.NET / MC++.NET / UC++ application which is having
memory problems after 10-20 hours of runtime. I've already read a few
dozen threads on similar issues, so I'm not gonna go into tons of
detail.

Every perfmon log I've collected so far display # of byes in all heaps
as 0 always. This is when logging data to a file, I haven't tried live
display (since the problem occurs so slowly).

I do an explicit GC.Collect() every 20 seconds or so (I know the
problems associated with this, but it makes sense for our allocation
pattern). I've got one log that ran 70 hours sampling once per minute
with every entry zero. I've also got another a log which ran for 3
hours sampling every second with every entry zero.

I read another post that said this counter was only accurate after a
GC collection was done; I obviously can't coordinate that with when
perfmon samples data, but given that I explicitly do it every 20
seconds, you would think my sampling intervals would pick up valid
data...

Does this counter not work in the logging mode?

I haven't tested most of the other .NET memory counters yet, but I'll
be doing so in my next test trial.

Thanks,

I have an update on this issue.

EVERY .NET counter returns 0 values, I added all counters from .NET
CLR JIT and .NET CLR Memory, and none of them work when I load in data
from a saved perfmon log file. I am able to view these counters in
live mode inside of perfmon, but even on the tool which is recording
the data I am unable to load the log files.

Can anyone verify whether these counters work with saved log files, or
only in live mode?

I'm running XP SP1 on the profiled PC w/ v1.1 of the .NET framework.
Any upgrades to XP or perfmon/MMC I might need?

Thanks,

Hello Ken,

I'm seeing exactly this issue. Did everone ever send you a solution?

Thanks,
Rob

[quoted text, click to view]