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

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

Why GC Analysis Report Was Not Generated (Node.js)?

Unlike Java (which can write GC logs to a dedicated file) or .NET (which emits CLR GC events via ETW), Node.js has no flag that writes garbage collection activity to a file of your choosing. --trace-gc always writes to the process's standard output, interleaved with your application's console logs. The yc-360 script must therefore discover or be pointed at that output. If it cannot find usable GC lines, the GC Analysis Report will not be generated.

1. GC tracing is not enabled

If the Node.js process was not started with --trace-gc, no GC trace lines are produced and the report will be empty.

How to fix?
Start (or restart) your application with --trace-gc:

node --trace-gc app.js

You can also set it via NODE_OPTIONS so it applies without changing the launch command:

NODE_OPTIONS="--trace-gc" node app.js

For more background, see Configuring Continuous GC Log Capture.

2. On Windows, nodejsGCLogPath is missing or incorrect

On Windows, the yc-360 script cannot auto-discover another process's standard output. If you do not redirect the application's output to a file and pass that path as nodejsGCLogPath, GC Log capture will be empty and no GC report will be generated.

How to fix?

1. Redirect the application's stdout/stderr to a file at startup:

node --trace-gc app.js > app-output.log 2>&1

2. Point the yc-360 script at that same file:

.\yc -onlyCapture -p {PID} -appRuntime=nodejs -nodejsGCLogPath=C:\path\to\app-output.log

3. On Linux / macOS, auto-discovery cannot find the process output

On Linux and macOS, the script normally discovers the target process's standard output as long as the application was started with --trace-gc. In some environments (containers, process managers, custom redirects, or non-standard process trees), auto-discovery can fail and the GC report will be missing.

How to fix?
Use the same redirect + nodejsGCLogPath approach as on Windows:

node --trace-gc app.js > /var/log/myapp-output.log 2>&1

./yc -onlyCapture -p {PID} -appRuntime=nodejs -nodejsGCLogPath=/var/log/myapp-output.log

4. User permissions do not match the Node.js process

The yc-360 script should be launched with the same user permissions as your target Node.js application. If the script runs as a different user (for example root while the app runs as node or ec2-user), it may be unable to read the process output or related artifacts, and GC capture can fail.

How to fix?
Run the yc-360 script as the same OS user that owns the Node.js process.

5. Wrong process ID (PID) or appRuntime is not set to nodejs

The GC report for Node.js is built from V8 GC trace lines for a specific process. If the wrong PID is passed, the process exited before capture started, or the script was not told to use the Node.js capture path (-appRuntime=nodejs), no usable GC data will be collected.

How to fix?
Confirm the PID belongs to your Node.js process, then pass -appRuntime=nodejs:

./yc -onlyCapture -p {PID} -appRuntime=nodejs -a {APPLICATION_NAME}

On Linux you can verify the process with:

ps -ef | grep node

6. Capture window was too short / no GC cycle ran

Even when --trace-gc is enabled and the output path is correct, a lightly loaded process may not run a garbage collection cycle during the capture. In that case the captured GC log can legitimately contain zero events, so the GC Analysis Report will look empty or will not be generated.

How to fix?
Re-run the capture under representative load, or wait until the process has been running long enough for at least one GC cycle to appear in the output. See also Why is GC Log missing or empty for my Node.js application?.