We have a windows service which hosts different appdomains. This processes uses remoting over IPC and TCP to communicate across the different app domains and with other processes.
This process is compiled using .NET framework 2.0 (vs2005) but we forced it to run on CLR 4.0 using the following entry in the config file.
The problem is that after some hours of running, the process starts eating up the CPU cycles. When debugging with WINDBG we notice that the thread consuming much of the CPU is in fact the Garbage Collector (<gcServer> is set to true).
On inspection of the Heap we notice that there is a very huge array on the LOH of the type System.LocalDataStoreElement with around 18million entries all set to null. This array is copied and increased each time, which is what is causing the cpu issue.
Now in our services we are passing Identities to impersonate user in the other appdomains / processes in the Named dataslots for the different threads (we have an object which implements the ILogicalThreadAffinative).
This issue is not present if the process runs on the CLR 2.0. Anybody can shed to us some light of what we are doing wrong or what changed in the CLR 4.0 please?
Why don't you re-build project with .NET Framework V4.0 directly?
The useLegacyV2RuntimeActivationPolicy attribute is useful if your application uses legacy activation paths, such as the CorBindToRuntimeEx function, and you want those paths to activate version 4 of the CLR instead of an earlier version, or if your application is built with the .NET Framework 4 but has a dependency on a mixed-mode assembly built with an earlier version of the .NET Framework. In those scenarios, set the attribute to true.
Paul Zhou [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Install a windows service monitoring system. Below software might help you.