.NET Fat Client: no CLR generation and thread count values when OS runs in German
I have just spend hours to get memory values for the generation 0, 1, 2 and large object heap spaces in dynaTrace for a .NET FAT client app.
Last time I had a identically issue on a .NET server app, compuware support wrote in the TT:
"The user that runs that application should be a member of the Performance Monitor Users group locally in Windows, and you should make sure the Windows Remote Management service is running. "
This was the solution for that case. But this time even this was not working.
After checking the measures in the system profile and trying to find the according counters in perfom on the Win7 desktop, where the app was running, I got the idea that it would be easier to switch the OS language to english, so the counters can be found easier. I have done this. Logout and login in the OS to get the language changed. Like this, it was indeed easier to compare dynaTrace measures couter names with perfmon counter names. But this was not the only one that improved the situation. After switching the OS language to english, I got the values in dynaTrace.
Does this mean, I will not be able to get this performance values out of the CLR when the OS is running in German language?
Hi Stefan
Thanks for all the insight on how you solved this problem. I will forward this to the engineering team to get more insight. As far as I know it should work independant of the OS Language. But - let me double check.
Andi
I just got word from engineering. There is an environment variable that you can set that will enable our agent to also work in localized versions of Windows. This option however comes with a slight CPU Overhead. This should not be a big problem if you are talking about a .NET Rich Client Application.
So - try to set the following env variable for your process:DT_ENABLEPERFCOUNTERTRANSLATION=true
Let us know if this works for you.
Hi Andreas
I will try this next time I am at customer side (next year). But not sure if I can put this in place in the production, as we already found out by dynaTrace, that the bottleneck of the app is the client CPU 
As you tell me, this will produce some overhead on that CPU, I don't think, customer will be happy with that.
But thank you anyway.
Kind regards, Stefan
Hi again
I was able to test it.
Yes, this works very well.
Thank you very much.
Kind regards, Stefan
Welcome the
Dynatrace Community Forums
Check out the Forum User Guide and Forum Guidelines to learn how to get started.Community Member of the Month
August 2017
Announcing Dynatrace's Community Member of the Month for August 2017, Rick B.! Click here to read more! 