Enter Case number reference for associated cases.

Ticket #

Type: dynaTrace

Include any information that is for INTERNAL use only

 

Information:

Detail the contextual information specific to the issue; i.e. Product, Version, Agent, System, etc.

AppMon: all versions with classic agents

Describe the problem, from the user perspective

A .NET agent is not delivering any PurePaths and in the agent overview the state "Instrumentation disabled because not all transformations were completed successfully" is shown.

Clearly list the Steps to resolve the issue

Fix network connectivity problems

Usually network connectivity issues are causing this problem, so this message comes with connectivity errors in the agent log. In case the collector and/or the monitored application hosts are running virtualized on vmWare, likely it is a known problem with high packet loss.
See https://kb.vmware.com/kb/2039495, https://kb.vmware.com/kb/1010071, or https://kb.vmware.com/kb/2056468.

Exclude huge assemblies from instrumentation

If this does not apply or the NIC buffers are already at maximum, this could also be caused by very high processing times on collector side because of big assembly file size, containing huge amounts of classes, or due to special obfuscation. Known are already certain 3rd party assemblies from vendors like Aspose or DevExpress, which can cause an in general non-critical disconnect, but in case immediately afterwards one essential assembly is tried to be instrumented, the disconnected state will likely trigger the same problem. Those assemblies can - like other non-essential assemblies - be excluded from instrumentation following this KB article: How to exclude assemblies from instrumentation
The consequence is that no sensors can be placed on classes within those excluded assemblies anymore, but due to obfuscation, the class and method names might not be of interest in a PurePath anyways, but autosensors will still bring visibility into non-instrumented assemblies. Additional benefit of excluding assemblies will be some memory overhead improvement (depending on assembly size).

Switch to AppMon agent

The new AppMon agent platform is performing instrumentation on the agent side, so is not affected by this kind of issues. Please refer to the agent platform introduction and the instructions how to switch.

Note the underlying reason for the problem

With the classic agents, the instrumentation is performed on the collector side, so connectivity must be reliable. Additionally some agent functionality is injected into fundamental assemblies every .NET CLR must contain (like mscorlib.dll and multiple System.*.dll assemblies), so processing those is a requirement for the agent to work.