Nsight Graphics failed to capture for chrome

Platform: Windows 11 25H2
GPU: NVIDIA GeForce RTX 2060
GPU Driver Version: 581.57
Nsight Graphics Version: 2025.4.1
Chrome Version: 141.0.7390.123


Issue Description
I am attempting to profile a WebGPU renderer in Google Chrome using the Nsight Graphics GPU Trace Profiler. However, Nsight Graphics fails to detect and attach to the Chrome process after launch, preventing profiling.

Despite following the known procedure and ensuring all prerequisites are met, the tool cannot find the target process.


Steps to Reproduce

  1. LauncheNsight Graphics 2025.4.1, click “Start Actitivy” and select activity “GPU Trace Profiler”.

  2. Set chrome executable path, e.g. C:/Program Files/Google/Chrome/Application/chrome.exe

  3. Set command line arguments listed below (for readability I added new lines between each argument, you can remove them if there are issues).

    --disable-gpu-watchdog
    --no-sandbox
    --disable-gpu-sandbox
    --disable-features=RendererCodeIntegrity
    --gpu-startup-dialog
    --disable-direct-composition
    --enable-dawn-features=emit_hlsl_debug_symbols,disable_symbol_renaming
    
  4. Click “Launch GPU Trace”.

Chrome should start normally now, but Nsight Graphics will report “Launch process exited”, and I can’t find the pid mentioned by Nsight Graphics in my task manager (please see the image above).

Troubleshooting Performed

I have extensively tested potential causes:

  • Simplified Configuration: Tested with a minimal set of arguments and even with a clean Chrome & Nsight Graphics installation with no extra arguments. The issue persists.
  • Manual Attach: Set “Automatically Connect” to “NO”, and tried manually selecting process from the “Attach” Tab.
    • However, the process table under “Attach” Tab was empty.
  • System Reboot: Performed multiple system reboots, ensuring no background processes of chrome exist beforehand.
  • Chrome Version Analysis: Seemingly version-dependent, but I don’t fine any related issues on the Internet.
    • Chrome 133 - 138: Works as expected (i.e. Nsight can correctly attach to the chrome process).
    • Chrome 138+ (including 141): Fails with the described error.

The evidence suggests that a change in Chrome’s process management after version ~138 causes the initial process to terminate and spawn a new process with a different pid?

My application requires features from newer Chrome versions, so downgrading is not a viable solution. Could the NVIDIA team please investigate the compatibility between Nsight Graphics 2025.4.1 and Chrome versions 138 and newer?

Thank you for your time and assistance.

Hi 15532,

Thank you for using Nsight Graphics and providing us with your detail feedback. I am not an expert of Chrome, but there is no difference for Nsight Graphics to support Chrome/WebGPU.

The key here is the backend of Chrome/WebGPU is D3D11 and GPUTrace doesn’t support D3D11.

You don’t need to do system reboot, just make sure no Chrome process exist in taskmgr. WRT the graphics process of Chrome, did you try to use the command line: --gpu-startup-dialog?

Thanks
An

Hi An,

Thanks for the prompt response.

To clarify a few points:

  1. I confirmed that the --gpu-startup-dialog argument was used. However, in Chrome versions 138+, the PID shown in that dialog does not match the PID in the Nsight Graphics log window. This discrepancy did not occur in older Chrome versions (<138), where the PIDs matched and profiling worked correctly.

  2. Regarding the backend: My understanding is that Chrome’s WebGPU implementation uses google/dawn: Native WebGPU implementation, which defaults to a D3D12 backend on Windows. This is consistent with the fact that I can successfully capture D3D12 API calls from my renderer using Microsoft’s PIX.

Thank you for your time and support.

Best regards,
15532

I am also experiencing this issue.

My setup:

Platform: Windows 11 Pro 25H2
GPU: NVIDIA GeForce RTX 3080 Ti
GPU Driver Version: 32.0.15.6094
Nsight Graphics Version: 2025.4.1
Chrome Version: 142.0.7444.60 (Official Build) (64-bit)

Hi 15532 and riccardo5,

That’s weird, I can do GPU Trace on my Chrome as expected (using Nsight Graphics 2025.4.1), however there might be something different.

  • It seems Chrome have some update, the latest version of Chrome in my machine is 142.0.7444.60
  • I use the same command line arguments as 15532’s, just append some common WebGPU sample URL
  • I didn’t see the PID mismatch, I can get the correct PID from both --gpu-startup-dialog of Chrome and Attach panel of Nsight Graphics.
    • Please click on ‘OK’ button of the PID dialog box of Chrome at first, then refresh the Attach panel of Nsight Graphics.
  • After close Chrome window, it will clean itself, no persistent Chrome process. Maybe you need to do some check about your options of Chrome.

Here is my screen shot.

Thanks
An

Hi An,

Thank you for testing on your end.

The issue was indeed elusive, but I’m thrilled to share that I have some new progress.

Inspired by the PID mismatch clue, I used Process Monitor to trace the process creation. The initial process launched by Nsight Graphics (PID: 11904) immediately spawns a child process (PID: 14432) and then exits. PID 14432 is the actual Chrome process we interact with.

While one might expect Nsight Graphics to automatically attach to this child process, it does not in this scenario. The key was to investigate how the child process was being launched.

By inspecting the creation parameters of the child process, I discovered that Chrome automatically appended several new command-line arguments:

--flag-switches-begin --flag-switches-end --origin-trial-disabled-features=CanvasTextNg|WebAssemblyCustomDescriptors --do-not-de-elevate

So, I wonder, what if I append them to the original command-line arguments?

And…it just worked! 😂 Now, Nsight Graphics can correctly detect the new chrome process and connect to it!

However, a new issue has appeared. When I click “Collect” in the GPU Trace session, the capture fails almost immediately with the error:

I can confirm, as mentioned before, the backend is D3D12, and the “Collect GPU Trace” button indeed remained disabled until I entered the website of my renderer, that means Nsight Graphics was aware of the API. This is weird.

Thank you for your assistance in investigating this.

Best regards,
15532

Hi 15532,

Do you always choose ‘Yes’ for ‘Automatically Connect’ option? What if you choose ‘No’ and manually choose the same PID as the GPU process ID dialog box, then click on the ‘Collection’ button?

Thanks
An

Thanks for your quick reply.

I tried attaching manually but the issue persisted:

p.s. I used the beta version of chrome here, but the stable version also has the same issue.

We’re encountering the same issue

The PID in the “activity window”

does not match the Goolge Chrome Gpu box pid

it must be that Chrome respawns itself and Nsight fails to connect to the new process

One extra clue:

When adding the command-line argument “–use-angle=vulkan” to chrome, Nsight Graphics can correctly connect to it (the connection issue has been solved above, see Nsight Graphics failed to capture for chrome - #6 by 15532) and capture the frame of a WebGL renderer.

But still don’t know why it can’t work for WebGPU / Dawn / D3D12.

p.s. More accurately, it can work for D3D12, but only for native programs (I’ve tested this) - it can’t work for D3D12 in chrome.

Thanks all for the answers.

@15532 if I’m not mistaken, the command line that worked for you was:

--disable-gpu-watchdog
--no-sandbox
--disable-gpu-sandbox
--disable-features=RendererCodeIntegrity
--gpu-startup-dialog
--disable-direct-composition
--enable-dawn-features=emit_hlsl_debug_symbols,disable_symbol_renaming 
--flag-switches-begin --flag-switches-end --origin-trial-disabled-features=CanvasTextNg|WebAssemblyCustomDescriptors --do-not-de-elevate

Is that it? Because in my case it does not work, I still cannot see the process.

By checking with what args the process is launched on PIX (which fully works) the command line in my case was the following:

--type=gpu-process --disable-gpu-sandbox --disable-direct-composition 
--string-annotations=enrollment-domain=somedomain.io --no-pre-read-main-dll 
--start-stack-profiler --subproc-heap-profiling 
--gpu-preferences=SAAAAAAAAADkAAAEAAAAAAAAAAAAAGAAAwAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAIAAAAAAAAAAIAAAAAMAAAAYAAAAAAAAADAAAAAAAAAASAAAAAAAAAAfAAAAFwAAAGVtaXRfaGxzbF9kZWJ1Z19zeW1ib2xzAB8AAAAXAAAAZGlzYWJsZV9zeW1ib2xfcmVuYW1pbmcAFAAAAAwAAABkdW1wX3NoYWRlcnMAAAAACAAAAAAAAAA= 
--metrics-shmem-handle=2200,i,4557001725045463389,1685856038540948289,262144 
--field-trial-handle=2388,i,9025171400293513112,35909372674069815,262144 
--variations-seed-version=20251107-030043.468000 
--trace-process-track-uuid=3190708988185955192 
--mojo-platform-channel-handle=2384 /prefetch:2

I’ve also tried to use this last one as args for nSight with no success.

p.s. I’m launching Chrome Canary (nightly version) which again, fully works with PIX but not with nSight.

Yes, they are. And I’m sorry to hear that the arguments didn’t work for you. I’ve tested them OK on 2 different machines.

Have you removed the newlines between arguments? I recall (not very sure) that they won’t work correctly with newlines and you need to manually remove them (e.g. copy-paste them to a .txt file first, replace all ‘\n’ with ’ ', and copy-paste again to Nsight).

i.e. (I added a sample url for convenience)

--disable-gpu-watchdog --no-sandbox --disable-gpu-sandbox --disable-features=RendererCodeIntegrity --gpu-startup-dialog --disable-direct-composition --enable-dawn-features=emit_hlsl_debug_symbols,disable_symbol_renaming --flag-switches-begin --flag-switches-end --origin-trial-disabled-features=CanvasTextNg|WebAssemblyCustomDescriptors --do-not-de-elevate https://webgpu.github.io/webgpu-samples/?sample=instancedCube