Troubleshooting Application Crashes with OneAgent Without Disabling the Agent
When an application crashes after OneAgent installation, disabling the agent entirely is not necessary and should be avoided. Instead, use a structured, step-by-step isolation approach to identify the root cause while keeping monitoring in place.
Before You Begin
1. Verify technology support and agent version
Ensure the technology stack in use is supported by Dynatrace and that you are running the latest version of OneAgent. An outdated agent is a common source of instability.
Step 1 Disable RUM (Real User Monitoring) First
Start your investigation at the RUM layer. RUM instrumentation involves JavaScript injection and HTTP response modification, which can occasionally conflict with certain application or HTTP client behaviours. Isolating RUM is the quickest and least invasive first step.
How to disable RUM at the Process Group level:
- Navigate to the affected Process Group in the Dynatrace UI.
- Go to Settings → Real User Monitoring.
- Disable Enable Real User Monitoring.
- Restart OneAgent after making the change.
💡 Note: Disabling RUM at the Process Group level is preferred over using the OneAgent feature flag, as it also reduces configuration size by removing unnecessary application detection rules making it a cleaner and more efficient change.
If disabling RUM resolves the crash → Contact Dynatrace Support to investigate the specific RUM/injection conflict further.
If the crash persists → Continue to Step 2.
Step 2 Identify the Technology Stack
Navigate to the affected Process in the Dynatrace UI and expand the Properties and Tags section. This will list all technologies detected within that process.
📌 Example: A .NET-based process might show technologies such as IBM MQ, ADO.NET, and WCF. A Java-based process might show JDBC, JMS, or servlet frameworks. The steps that follow apply to all technologies the specific sensors you will see depend on what is detected in your process.
Make a note of every technology listed each one has a corresponding OneAgent sensor that can be individually disabled for testing.
Step 3 Isolate by Disabling OneAgent Sensors One at a Time
Navigate to Settings → Preferences → OneAgent Features and search for the sensors corresponding to the technologies identified in Step 2.
Disable them one at a time, following this procedure for each:
- Disable one sensor.
- Restart OneAgent.
- Observe whether the crash is resolved.
- If not, re-enable that sensor and move to the next one.
⚠️ Only disable one sensor per test cycle and always restart OneAgent between changes. This ensures you can accurately attribute the fix to a specific sensor.
📌 Example (.NET process): You might test sensors such as IBM MQ, ADO.NET, and WCF individually. This is illustrative the sensors available to you will reflect the technologies detected in your specific process, regardless of the technology stack in us
Step 4 Use the RUM Health Check for Additional Diagnostics (Optional)
If the issue appears related to RUM injection specifically, the RUM Health Check can provide rapid diagnostic insight without requiring log analysis. Issue a request to the application with the header User-Agent: dtHealthCheck (using cURL or Postman). The response headers will indicate the RUM sensor state and help pinpoint the layer at which the issue occurs.
Step 5 Collect Data and Raise a Support Ticket
Once you have identified (or narrowed down) the offending sensor, open a Dynatrace Support ticket with the following information.
📌 Note: The example below uses a .NET application as reference. The artifacts required will vary depending on your technology stack. Work with Dynatrace Support to confirm exactly what is needed for your environment.
| Artifact | Applies To | Notes |
|---|---|---|
| Link to the Process | All technologies | Direct URL from the Dynatrace UI |
| OneAgent logs | All technologies | Collected from the affected host |
| Name of the offending sensor | All technologies | Which sensor was disabled when the crash stopped |
| Windows Event Logs | Windows-based hosts | From the time window of the crash |
| Class dumps | .NET applications | Collected at time of crash |
| Memory dumps | .NET applications | Recommended tool: Debug Diagnostic Tool |
| Heap dumps / thread dumps | Java applications | Collected at time of crash |
| Application-specific logs | All technologies | E.g., IIS logs, Node.js logs, JVM logs depending on stack |
