I’m encountering an issue when using the NVIDIA Aftermath SDK 2.24 to process a GPU crash dump (.nv-gpudmp) and generate a JSON report using the matching debug information (.nvdbg). Specifically, I’m observing a discrepancy in shader binary hashing between the Aftermath SDK’s behavior and the results I see in Nsight Graphics.
In Nsight Graphics 2025.4.1, when I open the attached .nv-gpudmp file, the shader is correctly identified, showing a shader hash of 0xE6B385C8C8764DB8, and the corresponding shader binary file is found and associated. This successfully allows me to view the shader source file name and line number.
However, when processing the same dump file via a call to GFSDK_Aftermath_GpuCrashDump_GenerateJSON, the following sequence of events occurs in my provided callbacks, which suggests a potential hashing mismatch:
ShaderDebugInfoLookup Callback:
It is called with a GFSDK_Aftermath_ShaderDebugInfoIdentifier structure where the id property is {0xE6B385C8C8764DB8, 0x000001E018803560}.
I successfully look up and pass the debug info by calling setShaderDebugInfo with the contents of the file named 0xE6B385C8C8764DB8-0x000001E018803560.nvdbg.
ShaderLookup Callback:
It is then called with a GFSDK_Aftermath_ShaderBinaryHash structure whose value is 0xE6B385C8C8764DB8.
I’ve confirmed that none of the .dxil files in my project match this hash when processed using GFSDK_Aftermath_GetShaderHash.
Also I’ve made a key discovery that points to where the hash might be going wrong:
When I manually call GFSDK_Aftermath_GetShaderHash on the shader binary file that Nsight Graphics successfully found, it returns a different hash: 0x214e38c51d4862bb.
If I force ShaderLookup callback to call setShaderBinary with the contents of this known-good .dxil file (even though the hash requested was 0xE6B385C8C8764DB8), the process completes correctly: the subsequent ShaderSourceDebugInfoLookup callback is called, the shader mapping is resolved using the PDB, and the resulting JSON contains the proper source information.
My question is, is there a known difference or configuration that might cause a discrepancy in how the Aftermath SDK 2.24 hashes shader binaries compared to Nsight Graphics 2025.4.1 ?
It seems like the identifier hash (0xE6B385C8C8764DB8) correctly finds the .nvdbg debug info but fails to match the shader binary hash, which I suspect should be 0x214e38c51d4862bb.
Any guidance on how to properly resolve the shader binary hash within the Aftermath SDK workflow to match the correct .dxil file would be greatly appreciated.
Thank you for using Nsight Graphics/Aftermath SDK and providing your feedback. We are sorry for any inconvenience you have encountered.
Could you please provide a simple example that would allow us to reproduce the issue? This will help us in investigating and resolving the problem more efficiently.
The bundled Aftermath SDK with Nsight Graphics 2025.4.1 should be 2.25 (folder named 2025.4.0.250729 in the installment and 2.25 defined in GFSDK_Aftermath_Defines.h)
By the way, did you tried to use nv-aftermath-format.exe with --json option? I tried and without --json it will show me 0xe6b385c8c8764db8, and with --json it will show me 16623777746957782456 (correct value).
Please find the new attachment, which should allow you to reproduce the issue. It includes the Python script that utilizes the Foreign Function Interface (FFI) to call GFSDK_Aftermath_GpuCrashDump_GenerateJSON. My apologies that it is not in C++. You can find detailed usage instructions in the accompanying ReadMe.txt file.
As you suggested, I ran nv-aftermath-format.exe and confirmed that the shader hash 0xE6B385C8C8764DB8 was present and that all shader mappings were correctly resolved.
This suggests that the core problem may not be a discrepancy between the shader hashes in Nsight Graphics and the Aftermath SDK. Instead, it seems that none of the .dxil files in the project match the required shader hash 0xE6B385C8C8764DB8.
For context, the .nv-gpudmp, .nvdbg, .dxil, and .pdb files were all generated from the same code revision. However, there is one difference:
The .nv-gpudmp and .nvdbg files were collected from an end-user build where shaders were compiled with optimization enabled.
The available .dxil and .pdb files were collected by developers where shaders were compiled with optimization disabled.
Given that Nsight Graphics was still able to resolve the shader mappings, I am unsure if the difference in optimization levels is contributing to the issue.
I would greatly appreciate any guidance regarding the correct approach for mapping the shader hash to the shader binaries within the PFN_GFSDK_Aftermath_ShaderLookupCb callback.
My current understanding is as follows:
Calculate the hashes of all available .dxil files in advance using GFSDK_Aftermath_GetShaderHash.
In the callback, return the contents of the .dxil file that matches the provided shader hash.
Are there any specific considerations or best practices I should keep in mind for this lookup process, especially given the observed mismatch?
The internal case will show some help about the observed mismatch, I can’t give any internal information right now, but will let you know when the issue is OK.
Hi, I haven’t looked at the provided sample files, but regarding this point:
The .nv-gpudmp and .nvdbg files were collected from an end-user build where shaders were compiled with optimization enabled.
The available .dxil and .pdb files were collected by developers where shaders were compiled with optimization disabled.
It is not possible for Aftermath to accurately resolve source in this case. It needs to have an unbroken chain of shader source → DXIL (& pdb) → nvdbg, because it goes in reverse up that chain to show you the source line that crashed. The nvdbg is essentially pointing to a line # of DXIL that crashed, but that line # is only valid for the DXIL that it actually came from.
(Since the pdb contains the shader source, you don’t actually need a separate source file lying around.)
That’s a very helpful point, thank you! To ensure my understanding is accurate, are you suggesting that the .dxil and .pdb files collected by developers need to be compiled using the same optimization settings as the final end-user build?
Hi. I just wanted to share that .dxil and .pdb files compiled with the same optimization settings as the final end-user build did resolve shader symbols. Especially, our development build was compiling shaders with additional arguments /Zi /Qembed_debug , so I assume it made difference in shader binary hashes.
