On the surface level, this appears to work. The command line states that it is capturing data and, on closing of Chrome, writes out the report. Looking at the Diagnostics Summary, it tells that the OpenGL injection was successful for two PIDs, but also that no OpenGL events were collected for these PIDs.
Now, here is the fun part: none of these two PIDs is the PID of the Chrome process that actually ran the application. In the screenshot below, three Chrome processes are pinned. The two green ones are the ones with the injection and the remaining pinned one is the one where the actual rendering happens.
The timings and the naming of the second green Chrome process suggests that Chrome somehow crashed after the injection and then recovered with a new window that actually loaded the WebGL application. A new window that did not get injected, and thus did not have its WebGL calls capture.
I tried the Chrome debug logs, but they get overwritten at each application start and I noticed that the earliest timestamps align with the start of the uninjected process. So no joy there.
Is this an error in Nsight’s or Chrome’s behaviour or am I doing something wrong here? I would also take alternative suggestions on how I could narrow down the cause of this.
When you launch Chrome from the command line, the process that you launch sends a message to the main (already-existing) chrome process running and causes it to open a new tab in the tree of that process.
When I tried the command-line you gave here, what I saw is that the Nsight Systems CLI exited before I closed the WebGL window - and the report looked much like the one in your screenshot.
I then closed out of chrome and also killed all chrome processes in the Task Manager, then tried again - which resulted in the CLI staying alive until I closed Chrome, and in the resulting report containing the OpenGL API and GPU workload traces working correctly.
I don’t know Chrome well enough to tell you if there’s a way to make it run in a standalone mode (I did try --incognito which still behaved like the first attempt, even though the WebGL tab opened in a separate browser window).
Let me know if a completely fresh instance of Chrome doesn’t work for you, and we’ll try to figure out what is the difference between the attempt that worked for me and your environment.
Thank you for taking the time for looking into this. The behaviour I described is on a fresh Chrome instance. But interesting that it worked as intended for you. So this is most likely something in my setup. For completeness sake, my configuration:
Nsight Systems 2025.5.1 (CLI run as admin from powershell)
Chrome 142.0.7444.60
Windows 11 Business 23H2
CPU i7-13700H
GPU RTX 4050 Laptop
The files are too large to upload them here, and the company cloud does not allow sharing links that are accessible to everyone. I think sharing via email works. Do you have an address where I can send them to?
While you are going over the logs, I tried a few more things. Maybe it is useless, maybe it points you into the right direction. I will let you be the judge:
I tried previous versions of Nsight Systems:
2025.4 - same result
2020.4.1 - same result
Then I made a Windows builds of our application (it is Unity based), with the graphics API forced to OpenGL (first the more current OpenGL ES3 option, then the deprecated OpenGL Core option). I tried to profile those with Nsight Systems and found that they crash too! No recovery here though, so I got the Unity logs. I have dropped one of each in your Google drive, but from skimming it, it appears to me that there is some issue with the injection trying to access an invalid address.
Than it got interesting. I repeated the same, but now set the build to Directx11… and that worked. No crash and Nsight Systems captured events as it should. Does not help with debugging our WebGL app, but looks like the injection is working there at least.
Updating the thread following the investigation, in case other users encounter the same issue:
The problem comes from the fact that launching Chrome from an elevated context, such as an Administrator Command Prompt or the agent launched by Nsight Systems’s GUI, will cause it to spawn a non-elevated chrome.exe process and perform the rendering on that process.
This results in the same problem as performing the trace when an instance of Chrome is already running on the computer: The rendering process is not part of the process tree launched by Nsight Systems, which means all injection-based data sources - specifically OpenGL API trace - will not work for that process.
The problem (with either root cause) can be diagnosed by the most active chrome.exe process (typically, the Chrome “GPU Process”) not being highlighted in green in the Nsight Systems report view process list.
To work around the issue, these steps can be followed:
Using the Windows task manager, verify no chrome.exe processes are currently running
Open a non-elevated Command Prompt
Run the command "C:\Program Files\NVIDIA Corporation\Nsight Systems 202x.x.x\target-windows-x64\nsys.exe" profile <nsys CLI options> chrome.exe <chrome command-line parameters>
It is recommended to enable --trace=opengl-annotations,wddm in the nsys CLI options for WebGL tracing.
Another update, because we found out some more info and a better workaround:
Apparently, Chrome is not allowing elevated processes anymore since May (source). One can still start an elevated process, but it then automatically gets de-elevated, which is probably the behaviour we see here. But, they also added a switch to enable that behavour. And it works! If I run the following command, it does hook and I am getting webGL events!
