Why Heap Dump Report Not Generated?

It could because of one of the following reasons:

Why Heap Dump Report Was Not Generated (Java)?

1. 'hd' argument not passed

Since capturing heap dump pauses the JVM, yc-360 script doesn't capture heap dump by default. In order to capture the heap dump, you need to pass 'hd' argument to the yc-360 script. You can pass the 'hd' argument in two modes:

1.1. Command-line

Specify the -hd argument in the command-line

1.2. Configuration file

Specify 'hd: true' argument in the YAML configuration file.

2. '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.

3. 'jcmd' tool not present

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

4. user permissions

The yc-360 script should be launched with the same user permissions as your target application's user permission. Say 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 scripts.

Why Memory Report Was Not Generated (.NET)?

• IMPORTANT: For .NET applications, the Memory Report captures basic information about application memory.
• This is not a full heap dump (.dmp) file.
• Full heap dump capture for .NET applications is not yet available in the current version of
• the yc-360 script.

1. Tool was not run as Administrator

Memory capture uses the same ClrMD passive attach as Thread Snapshot and requires the same elevated privileges to open and inspect the target 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 is wrong or the process has exited, the attach will fail and no memory data will be captured.

How to fix?
Confirm the PID is correct using Task Manager or:

tasklist /FI "IMAGENAME eq YourApp.exe"

3. Managed heap is not yet initialized

After attaching, the tool checks whether the CLR heap can be walked (heap.CanWalkHeap). This check fails if the CLR has not yet fully initialized its garbage collection heap — which can happen if the process was captured within the first few seconds of startup.

How to fix?
Wait until your .NET application has fully started up and is handling requests before triggering the memory capture.

4. Missing DAC (Data Access Component)

The same DAC requirement that applies to Thread Snapshot also applies to Memory capture, since both use ClrMD to attach to the process.

How to fix?
Ensure a standard .NET Framework or .NET runtime is installed. Check NetLogs\log_<date>.txt for a detailed error message about DAC resolution.

5. Security software or policy blocking process attachment

Anti-virus software or security policies can block ClrMD's read-only process attach, preventing memory data from being read.

How to fix?
Add an exclusion for yc-360.exe script in your endpoint security tool, or coordinate with your security team.

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

A bitness mismatch prevents ClrMD from attaching and reading the managed heap.

How to fix?
Use the yc-360.exe script binary that matches the architecture (32-bit or 64-bit) of your .NET application.