Dynamic assemblies being interpreted as static?

shagglez

Whilst the number of dynamic assemblies remains relatively constant, static assemblies are growing rapidly:


Breakdown seems to contain a lot of system generated names, what you'd expect to see in dynamic assemblies, and since there are no stacktraces in static assemblies breakdown, you can't tell where they are coming from. Here it is for reference:


Is it possible they are mixed up?

The application is running as a Windows service, if that's relevant. Profiler version: 8.2.0.73

Jessica R

Hi there,

Thanks for your post!

Hm, I wonder if those may be embedded binary resources. Can you kindly check--if you use Process Explorer to check the properties of the process, does the .NET assemblies tab show those assemblies and with paths listed?

shagglez

Thanks for your response. Here is the output of .NET Assemblies tab as per your request:



As you can see the output is pretty much the same, not sure what that means. I've also circled the scroll bar to give you an idea of just how many of those there are.

Jessica R

Many thanks for checking that!

I was thinking that these may be temporary assemblies created by XMLSerializer, but these would normally be identified as dynamic assemblies. After speaking with one of our developers though who looked at the Microsoft code, he noted it is also possible for XMLSerializer to create static temp assemblies if SOAP bindings are in use (if the setting UseLegacySerializerGeneration is on, or if errors were encountered during the creation of a dynamic assembly): http://referencesource.microsoft.com/#q ... mpAssembly

The assemblies produced are therefore not dynamic, even though they are temporary. If you think this applies in your case, it's possible to look at the temporary assemblies and debug into them, in case this might help with identifying their source: http://www.hanselman.com/blog/HOWTODebu ... embly.aspx

On the other hand, another colleague said he's seen a similar case of randomly named static assemblies without size and it was due to a known issue with XSLT. If you use an embedded script with an XSL file, it will create temporary assemblies and may create a memory leak if these are created and loaded repeatedly. Since these are written temporarily to disk before loading them, the profiler calls them static assemblies.

For more details on that issue:
http://blogs.msdn.com/b/xmlteam/archive ... sform.aspx
http://support.microsoft.com/kb/316775

Do either of these sound like they may apply to your application?

shagglez

Sorry, I got distracted by something else and forgot to respond.

I don't use XSL or XML serialization anywhere so I don't think it's that (at least not explicitly, perhaps one of the linked libraries is?).

If it helps I also noticed recently that csc.exe becomes extremely active doing something, and it stops when I kill the service, so somehow they are linked.

Jessica R

Hi,

No worries and thanks for the update!

It does seem like it would be related to serialization (kindly see here - http://stackoverflow.com/questions/6286 ... of-csc-exe). In case one of the linked libraries is, are you able to share which ones you're using?