I don’t doubt that I have shot myself in the foot with a series of commands but all I have is a stack trace I can’t decode that isn’t giving me any hints as to what in the pipeline caused the issue. Is there a way to get the PDB file for my particular version (actually, should be the latest) to help shed some light on the cause? Or does anyone have experience with this call that could explain common reasons it might trip int 27h? I know it seems to be related to rendering a relatively small triangle list but there is nothing obviously wrong with it.
Hello @ifrisbie and welcome to the NVIDIA developer forums.
I think for anyone to try and help you, you will need to share a bit more detail.
Maybe the stack trace? And your source if it is not confidential?
Then which file’s PDB are you interested in? We do have a symbol server, so that might be a start.
What OS/GPU/CPU are you on?
Things like that make it much easier to understand your issue.
Thanks!
nvoglv64.dll!000001d2412433f5() Unknown
nvoglv64.dll!000001d240c88d4a() Unknown
nvoglv64.dll!000001d240cdcdd7() Unknown
nvoglv64.dll!000001d240cdcf9e() Unknown
nvoglv64.dll!000001d240df2c6a() Unknown
nvoglv64.dll!000001d240df973b() Unknown
nvoglv64.dll!000001d240de0983() Unknown
nvoglv64.dll!000001d240de1750() Unknown
nvoglv64.dll!000001d240dffa2b() Unknown
nvoglv64.dll!000001d240c84fb6() Unknown
nvoglv64.dll!000001d240dc4d51() Unknown
nvoglv64.dll!000001d240d7abb9() Unknown
nvoglv64.dll!000001d24089573d() Unknown
nvoglv64.dll!000001d24089c3be() Unknown
nvoglv64.dll!000001d24083d45b() Unknown
nvoglv64.dll!000001d240a134e3() Unknown
nvoglv64.dll!000001d240a13067() Unknown
nvoglv64.dll!000001d240c8bcc8() Unknown
kernel32.dll!00007ffd8ecf26ad() Unknown
The symbol server would be a great start. I tried to “hook up to it” but I haven’t ever pulled in from an external server before so I have no experience setting it up. Tried what you see in the attached pic but nothing was found - so I assume it needs to be setup in a different way. I can post a proper stack trace once the symbols get exposed. I am Win11/GeForce RTX 3090/12th gen i9-12900.
The source is rather complex but when needed I’ll probably be able to pull out a snippet of the gl pipeline that seems to induce the issue. Its basically the following series of calls (lacking the context):
glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(size, type, stride, pointer);
where: size=3, type=5126 (GL_FLOAT), stride=36, pointer = 0x000002156ee22f60
glEnableClientState(GL_NORMAL_ARRAY);
glNormalPointer(type, stride, pointer);
where: type=5126 (GL_FLOAT), stride=36, pointer = 0x000002156ee22f6c
glEnableClientState(GL_COLOR_ARRAY);
glColorPointer(size, type, stride, pointer);
where: size=4, type=5121 (GL_UNSIGNED_BYTE), stride=36, pointer=0x000002156ee1e118
glClientActiveTextureARB(GL_TEXTURE0);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);
glTexCoordPointer(size, type, stride, pointer);
where: size=2, type=5126 (GL_FLOAT), stride=36, pointer=0x000002156ee22f7c
glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(size, type, stride, pointer);
where: size=3, type=5126 (GL_FLOAT), stride=36, pointer = 0x000001756f159b30
glEnableClientState(GL_NORMAL_ARRAY);
glNormalPointer(type, stride, pointer);
where: type=5126 (GL_FLOAT), stride=36, pointer = 0x000001756f159b3c
glEnableClientState(GL_COLOR_ARRAY);
glColorPointer(size, type, stride, pointer);
where: size=4, type=5121 (GL_UNSIGNED_BYTE), stride=36, pointer=0x000001756f1525b8
glClientActiveTextureARB(GL_TEXTURE0);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);
glTexCoordPointer(size, type, stride, pointer);
where: size=2, type=5126 (GL_FLOAT), stride=36, pointer=0x000001756f159b4c
glDrawElements( mode, count, type, indices)
where: mode=4, count=432, type=5123 (GL_UNSIGNED_SHORT), indices = 0x000001755d37e5a0
I assume there is some issue either with the buffers (although its not evident to me what) or the GL state prior to executing it that is causing the crash - but knowing the exception might lead me to what is broken.
Well the GL calls look correct enough. An I guess a subsequent glReadPixels causes the exception?
The symbol server is the right one, but we have soem issues with the Webview of it which also causes VS to not find the correct file.
If you do a dumpbin.exe /headers nvoglv64.dll and look for some lines like these
64AF3E20 time date stamp Thu Jul 13 02:58:24 2023
428D000 size of image
you can decipher the correct http address for the symbols file. Take the hex values, transform to lower case, merge and you get the responding sub-dir on the server. For the above example it would be
https://driver-symbols.nvidia.com/nvoglv64.dll/64af3e20428d000/nvoglv64.dll
But you might have a different driver version. This one was 536.67.
My Info:
64DAAA3A time date stamp Mon Aug 14 18:27:06 2023
4292000 size of image
In which I updated my driver yesterday - however when I look at the symbol server directory list I don’t see anything in that range
Do I need to be using an older driver? Perhaps server has not caught up yet?
So this link (https://driver-symbols.nvidia.com/nvoglv64.dll/64DAAA3A4292000/nvoglv64.dll) does directly download. I think perhaps I am including it incorrectly through VS - need to explore more. How is the associated PDB located from that link as specifying it directly in that link above just grabs the same DLL I already have - is there some hidden feature in VS that looks in a similar location for the pdb? Perhaps this is just an access restriction issue due to my noobness here?
C:\<path>dumpbin \<userpath>\Downloads\nvoglv64.dll /headers | find "Format:"
64DAAA3A cv 25 03BB3A04 3BB2004 Format: RSDS, {999F13EA-D206-49D1-802A-B5EDA17150F4}, 1, nvoglv64.pdb
%s\%s\%s%x\%s” % (serverPath, pdbName, guid, age, pdbName)
https://driver-symbols.nvidia.com/nvoglv64.pdb/999F13EA-D206-49D1-802A-B5EDA17150F41/nvoglv64.pdb
Following one of your old links I saw this which seemed to point me to where the files should be, but I’m not seeing it in that location but then again its hard to know if I have the syntax correct here as it does look odd.
I tried this as lower-case as well, with and without the dashes. No joy.
Please note, we are only hosting the driver binaries, no PDBs will be distributed on this server.
I think I have misunderstood something. I thought his was somehow pointing me to a PDB reference so the symbols can be resolved but according to this comment that is here: NVIDIA Driver Symbol Server | NVIDIA Developer the PDBs must exist elsewhere (no are not accessible) - so since I already had the DLL as part of my installation - not sure what this process is doing for me unless that is an old comment.
I decided to just downgrade to the specific version you mentioned here, but this did not change a thing. I’m starting to think there are no symbol files on this server anymore (or maybe never were, and I’m misunderstanding what you mean by symbols file). I’m expecting VS to find the relevant PDB file but there is no indication that any exist on this server. At least none you can access using wget. But the general specification of the symbol server (https://driver-symbols.nvidia.com/) with that specific version yields nothing.
Hi again,
I am sorry, I guess the misunderstanding is completely on my side. I think I mixed this thread up with a couple of roughly related ones where people needed to have access to specific driver versions of this file without necessarily downloading the whole driver package again.
You are correct, our symbol server only supplies binaries, not PDBs.