# Why GC Analysis Report Not Generated?
It could be because of one of the following reasons:
# Why GC Analysis Report Was Not Generated (Java)?
# 1. GC logging is not enabled
Enabling GC logging provides great benefits https://blog.gceasy.io/2021/07/08/i-dont-have-to-worry-about-garbage-collection-is-it-true/ (opens new window) such as: reduce overall application response time, troubleshoot memory problems, forecast outages, do effective capacity planning. In contrary to common thinking, enabling GC logging doesn't add any noticeable overhead https://blog.gceasy.io/2021/08/17/overhead-added-by-garbage-collection-logging/ (opens new window) to your application. Thus we strongly recommend you to enable GC logging on all your production servers.
You can enable GC logging by passing the following JVM arguments to your application start-up script.
Until Java 8:
If your application is running on Java 8 or below version, pass below JVM arguments:
-XX:+PrintGCDetails -Xloggc:<gc-log-file-path>
Example:
-XX:+PrintGCDetails -Xloggc:/opt/tmp/myapp-gc.log
2
3
4
5
From Java 9:
If your application is running on Java 9 or above version, pass the below JVM arguments:
-Xlog:gc*:file=<gc-log-file-path>
Example:
-Xlog:gc*:file=/opt/tmp/myapp-gc.log
2
3
4
5
# 2. 'j' argument not set right
In the yc-360 script's YAML configuration file, probably the JAVA_HOME directory is not set to the 'j' argument OR if it is set, make sure it's pointing to the proper JAVA_HOME directory.
# 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.
# 4. 'jstat' tool not present
Make sure '/bin/jstat' is present under the 'j' argument folder. Sometimes you could have configured the 'j' argument to the 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 'jstat' tool. The yc-360 script needs the 'jstat' tool to capture thread dump. If you have restrictions in installing JAVA_HOME in your production server, you can use 'gcPath' or 'gcCaptureCmd' arguments. For more details, refer to the 'Garbage collection log' section on this page.
# Why GC Analysis Report Was Not Generated (.NET)?
# 1. Tool was not run as Administrator
GC capture uses Windows ETW (Event Tracing for Windows) to listen to CLR garbage collection events.
Creating an ETW session is a privileged operation on Windows. If yc-360.exe script is not run with
Administrator rights, the session cannot be created and no GC data is captured.
How to fix?
Right-click the terminal or Command Prompt you use to run the yc-360 script and select
"Run as administrator". Then run the capture again.
# 2. A previous GC capture session was not cleaned up
The tool creates an ETW session named GCMonitorSession. If a previous run was interrupted
(for example, killed forcefully), that session name may still be registered by Windows. A new
capture attempt under the same name will fail silently or produce an empty report.
How to fix?
Wait a few minutes for Windows to time out and release the session, or restart the machine.
Running the capture again after the previous yc-360.exescript process has fully exited usually resolves this.
# 3. The target process is not a .NET application
The GC report is based on CLR GC events emitted via ETW. Only processes that run the .NET CLR (Common Language Runtime) emit these events. If the wrong PID is passed, or the process is a native (C++, Go, Node.js, etc.) application, no CLR events will be received and the report will be empty.
How to fix?
Confirm the PID belongs to a .NET process. In Windows Task Manager, go to Details, add the
".NET CLR Memory" column, or use tasklist /M mscor* to list processes with a loaded .NET runtime.
# 4. Incorrect process ID (PID) was passed
If the PID passed to the capture command does not match any running process, or the process exited before capture started, the ETW session will receive no events.
How to fix?
Verify the PID using Task Manager (Details tab) or by running:
tasklist /FI "IMAGENAME eq YourApp.exe"
Pass the correct PID to the yc-360 script configuration.
# 5. Bitness mismatch between yc-360.exe script and the target process
If the target .NET application is a 32-bit process but yc-360.exe script is running as 64-bit
(or vice versa), ETW event correlation may produce incorrect or empty results.
How to fix?
Use the yc-360.exe script binary that matches the architecture of your .NET application.
Check if your application is 32-bit or 64-bit in Task Manager (32-bit processes show *32 next to the process name in the Details tab).