Why Thread Dump Report Not Generated?

It could because of one of the following reasons:

Why Thread Dump Report Was Not Generated (Java)?

1. 'j' argument not set right

In the yc-360 script's YAML configuration file, probably JAVA_HOME directory is not set to 'j' argument OR if it is set, make sure it's pointing to the proper JAVA_HOME directory.

2. 'jstack' tool not present

Make sure '/bin/jstack' is present under the 'j' argument folder. Sometimes you could have configured the 'j' argument to JRE_HOME folder. JRE (Java runtime environment) is a sub-set of JAVA_HOME, which has only essential tools to run java applications, but not all tools necessary for debugging. JRE doesn't have the 'jstack' tool. yc-360 script needs the 'jstack' tool to capture thread dump. If you have restrictions in installing JAVA_HOME in your production server, you can use 'tdPath' or 'tdCaptureCmd' arguments. For more details, refer to 'Thread dump' section on this page.

3. User Permissions

The yc-360 script should be launched with the same user permissions as your target application's user permission. Say for example, if your target process is launched by 'ec2-user', then yc-360 script should also be launched with the same 'ec2-user' permissions. You cannot give high level user permissions like 'root' to run yc-360 script.

Why Thread Snapshot Report Was Not Generated (.NET)?

1. Tool was not run as Administrator

Thread snapshot capture uses ClrMD, which attaches to the target process in passive (read-only) mode. Windows requires elevated privileges to open and inspect another process's memory.

How to fix?
Right-click the terminal or Command Prompt used to run the yc-360 script and select "Run as administrator". Then run the capture again.

2. Incorrect process ID (PID) was passed

If the PID does not correspond to a running process, or the process exited between the time the PID was identified and when the capture ran, the attach will fail immediately.

How to fix?
Confirm the PID is correct and the process is still running before capture starts. Use:

tasklist /FI "IMAGENAME eq YourApp.exe"

3. The target process is not a .NET application (no CLR loaded)

ClrMD can only read thread stacks from processes that have the .NET CLR loaded. If the process is a native application or if the CLR has not yet fully initialized (very early in startup), the attach will succeed but no managed threads or stacks will be found.

How to fix?
Ensure the target process is a .NET application and has been running long enough for the CLR to finish initializing (typically a few seconds after startup).

4. Missing DAC (Data Access Component)

ClrMD decodes the CLR's internal memory layout using a DAC (mscordacwks.dll for .NET Framework, mscordaccore.dll for .NET Core/5+). The DAC version must exactly match the .NET runtime version running inside the target process. If the DAC cannot be located, thread stacks cannot be read.

On a healthy machine the correct DAC is found automatically alongside the .NET runtime installation. This can fail in the following situations:

• The .NET runtime was installed in a non-standard location
• The runtime version in the target process is unusual (e.g. a preview or patched version)
• The machine has multiple conflicting .NET installations

How to fix?
Ensure a standard .NET Framework or .NET runtime is installed on the same machine where yc-360.exe script is run. Check NetLogs\log_<date>.txt next to yc-360.exe script for a detailed DAC resolution error message.

5. Security software or policy blocking process attachment

Anti-virus software, endpoint detection tools (EDR), or Windows security policies can block any process from reading another process's memory — even in passive/read-only mode. This produces an access-denied error at attach time.

How to fix?
Add an exclusion for yc-360.exe script in your endpoint security tool, or coordinate with your security team to allow the capture on the target machine. Check NetLogs\log_<date>.txt for the specific error code.

6. Bitness mismatch between yc-360.exe script and the target process

ClrMD requires that the bitness (32-bit or 64-bit) of yc-360.exe script matches the target .NET process. A 64-bit tool cannot attach and decode a 32-bit process, and vice versa.

How to fix?
Use the version of yc-360.exe scriptthat matches your application's architecture. In Task Manager Details tab, 32-bit processes are marked with *32.