Skip to main content

Troubleshooting

Viewing Logs

If the Agent is not working properly or there is no data, you can usually get more information from the logs to locate the problem.

Default UniAgent log location: C:\Program Files\tingyun\monitor\logs\agent\dotnet.log

Default log location for standard installation: C:\Program Files (x86)\Networkbench.COM\DotNET Profiler\log\agent.log

Under normal circumstances, there should be no Error, Critical, or similar keywords in agent.log.

By default, the log level is Info and audit mode is disabled, so the amount of information is limited. You can set the log level to debug and enable audit mode to output more log information for troubleshooting.

Troubleshooting Installation Issues

Check TingYun.dll in GAC

Note: Installing the Agent requires deploying an assembly in the .NET Global Assembly Cache (GAC), which requires administrator privileges.

Some security software may block the installer from operating on the GAC. Please check the behavior of your security software.

If you install with a restricted user or are blocked by antivirus software, the installer may indicate success, but after enabling monitoring and accessing the website, the page may fail due to the Agent component not being found.

You can verify this by restarting the website and accessing it immediately after installation. If this occurs, uninstall the Agent, then reinstall it with an administrator account or adjust your security software to allow GAC operations.

If you cannot change or pause the security software, try creating the following directory as an administrator and manually copy TingYun.dll from the net45 directory to this location:

%windir%\Microsoft.NET\assembly\GAC_MSIL\TingYun\v4.0_3.0.0.0__539a9bbefd34e379

Check DCOM Component tingyun_profiler.dll

Note: Installing the Agent requires registering the DCOM component tingyun_profiler.dll, which writes to the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{8BEB2128-D285-4E1D-91B6-11ACD43EC0EE}.

If security software blocks registry operations, enabling monitoring will result in no monitoring data or logs. Windows events will show error code 0x80040152:

If this occurs, pause the security software and reinstall. After confirming that monitoring logs are generated, re-enable the security software.

Check IIS Service Environment Variables

Note: Enabling the Agent requires writing values to system environment variables and the IIS service registry.

Some security software or Windows updates may periodically clean environment variables and registry entries, causing the Agent to stop working. If the Agent is not working, check the following registry and environment variables:

  • Registry: The following keys should all contain a value named Environment.

    • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IISADMIN
    • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC
    • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WAS
  • System environment variables: There should be a variable named COR_PROFILER in the system environment variables list.

Agent Installed Successfully but No Data

  1. After initial installation, it may take some time to see data, usually 5 minutes or longer. Please wait a bit longer.
  2. Some users' browsers have cache issues. Even if there is data, you may not see it without a forced refresh. Try clearing the cache, forcing a refresh, or using a different browser.
  3. After installing the Agent, you must enable monitoring; otherwise, the Agent will not take effect.
  4. Confirm that the license key is correct.
  5. Confirm that the web server has user access. Agent data is based on HTTP request performance. If there is no access, there will be no performance data. If there is no user access, use a browser to access the application, then check the report after 5 minutes.

Monitoring Asynchronous Methods

The Agent provides limited support for asynchronous method calls. When the application calls asynchronous methods and does not explicitly use ConfigureAwait(false) to clear the thread context, it can monitor asynchronous methods for databases and HttpClient.

For a technical description of ConfigureAwait(false), see this document.

"Loading this assembly would produce a different grant set from other instances. (Exception from HRESULT: 0x80131401)"

LegacyCasModel Mode

Some websites are configured with LegacyCasModel=true or NetFx40_LegacySecurityPolicy to use the older .NET 2.0 security model. For compatibility, SharePoint and BlogEngine.NET may use LegacyCasModel. After installing the Agent, SharePoint pages may report the error "Loading this assembly would produce a different grant set from other instances. (Exception from HRESULT: 0x80131401)". BlogEngine will not report an error, but the Agent log will show the following errors, and monitoring data cannot be reported.

ERROR System.Net.HttpWebRequest::SerializeHeaders, in rejit
ERROR System.Net.ConnectStream::CallDone, in rejit

If the website calls HttpClient or HttpWebRequest, failures may occur, affecting business execution.

When the .NET 4.0 core runs in 2.0 legacy security mode and tries to load code rewritten by monitoring tools, the CLR will throw the above error.

Any .NET monitoring tool, such as Dynatrace, NewRelic, or Microsoft's SCOM (System Center Operations Manager), will encounter this issue.

Changing LegacyCasModel to false may cause a "SecurityException". If you change LegacyCasModel to false and all features are tested without SecurityException, you can safely use the Agent. If you cannot change LegacyCasModel, you cannot use the Agent.

Multiple Application Domains in a Single Process

Some applications use reflection to dynamically load assemblies. If dynamic assemblies use multiple application domains and multiple domains directly or indirectly call Agent-instrumented methods, the error "Loading this assembly would produce a different grant set from other instances. (Exception from HRESULT: 0x80131401)" will occur.

Set the global system environment variable COMPlus_LoaderOptimization=1 and restart monitoring to see if the issue is resolved.

Occasional Slow Access After Installing the Agent

Usually, during process restart, .NET applications are slower to respond because the Agent is embedded and some code is instrumented. If you notice slow website response, it is usually because IIS is configured with a process recycling mechanism, causing the process to restart during operation and thus slow response.

IIS process recycling mechanisms include:

  • Fixed recycling interval: The default is 1740 minutes (29 hours).
  • Recycling by maximum request count: When a process handles a specified number of requests, it recycles. Default is 0 (unlimited).
  • Recycling at a specified time: You can specify a fixed time for recycling. Default is none.
  • If the site is idle, the process will be recycled after 20 minutes of inactivity by default.

Open IIS Manager > Application Pools, select the pool, click Advanced Settings > Recycling to view the recycling policy.

Check Advanced Settings > Process Model for "Idle Time-out (minutes)".

You can also check the Windows event log, filter for "Level" equals "Information" and "Source" equals ".NET Runtime" to determine when the application restarted and whether it matches the slow access times.

Recommendations:

  • Change the process recycling policy to recycle at a specific time, setting the restart to a business off-peak period, such as 2:00-4:00 AM.
  • Change the "Idle Time-out (minutes)" in the application pool's Advanced Settings > Process Model to 200.

Agent Log Error: "This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms"

Trigger: FIPS is enabled on the Windows server, and there is a bug in some versions of the cryptographic algorithm.

See: https://support.microsoft.com/zh-cn/topic/kb2925865-%E5%9C%A8%E5%90%AF%E7%94%A8-fips-%E7%9A%84-windows-%E4%B8%8A%E6%89%A7%E8%A1%8C-ssis-%E7%A8%8B%E5%BA%8F%E5%8C%85%E6%97%B6%E5%87%BA%E9%94%99-f7da8f5a-1b2d-2df9-a960-11ec6bc20645

Solution:

  1. Press Win+R, enter regedit to open the registry editor
  2. Edit HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled and set the value to 0
  3. Exit the registry editor
  4. Restart IIS