I’ve added some additional details. So, the value is an undefined, division by zero.
Unhandled exception at 0x0000000075AEC620 (nvoglv64.dll) in vlkTriangle.exe: 0xC0000094: Integer division by zero.
It is strange that vulkaninfo fails and vkcube works, that makes me wonder if there is indeed some configuration/installation issue lurking. It may be worthwhile to get this resolved before looking more into why your program fails. On the other hand, if vkcube run that means your system is able to render and present with Vulkan. Clean re-installation of graphics drivers or the SDK might help, but it is all a bit of a shot in the dark.
Have you tried running vulkaninfo from the command line? Perhaps it prints some more info about what causes it to fail?
Did you find the division by zero while running in a debugger? If so you should be able to get a stacktrace for the division by zero error to determine on which call in your program it happens? When you have that location you should place a breakpoint there and examine the values in the function arguments - at runtime createInfo.imageFormat has a location in memory and some value has to be in that memory location, even if it is not deterministic and changes from program run to program run.
From there go backwards in your program to where the value comes from.
Oh no, a reinstall? No problem. I’ll try it and get back.
Yes, it was in the VS 2019 debugger. Ah, a slightly more complicated example. Could you show me an example of how to look for the stacktrace? A Youtube video would be best. I’ve tried looking at the functions in vulkan.h but it just leads me to a Win32 API call and I’m not sure how to proceed from there?
Sorry, I don’t use VS much myself and I don’t have a link to a tutorial on debugging with it handy.
Do you mean you re-installed the Vulkan SDK? I think the first step in resolving the problem is finding out what exactly is wrong. I just remembered that the Vulkan SDK comes with a tool to check a system for Vulkan installation issues, vkvia - the SDK comes with a built a binary, so you don’t have to build from source.
Hi Carsten,
I want to upload a mp4 of vkvia.exe.
Is that possible?
I’m afraid I don’t know. Did you read the page describing the tool and particularly this paragraph (emphasis mine):
Does the tool report any errors with your Vulkan installation in the .html file it writes?
So, after trying with the above methods, I tried copying the code directly from
https://vulkan-tutorial.com/code/12_graphics_pipeline_complete.cpp
This shouldn’t have an issue, right?
Nope, error below.
Why is the error always with GOG(dot)com?
It’s already uninstalled from my PC.
Right, so the only problem vkvia can find is the same one that started this thread, the vulkan loader is attempting to load an implicit layer that is no longer there (because you uninstalled the program the layer came with, but the uninstall procedure did not remove the reference to the implicit layer).
Do you see the GOG layer in the Vulkan Configurator aka vkconfig? Can you exclude it there?
If you cannot disable the layer with vkconfig I suppose you could edit the registry key that vkvia mentions and remove it from there - only do this if you are confident that you know what you are doing.
Nope, I don’t see the GOG layer at all.
“C:\ProgramData\GOG.com\Galaxy\redists\overlay\injected\galaxy_overlay_vklayer_x64.json” just doesn’t exist in my computer.
If you can solve this problem, you can solve it for thousands of Vulkan users.
The Vulkan loader and .json is quite a common problem actually.
“### #863 - Issue opening JSON files when enabling validation layers”
Right, hence the loader complains about not being able to read a JSON file. The loader consults keys in the windows registry to learn about installed implicit layers (see Layer Discovery in the Vulkan Loader docs for details):
HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\Vulkan\ExplicitLayers
HKEY_CURRENT_USER\SOFTWARE\Khronos\Vulkan\ExplicitLayers
HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\Vulkan\ImplicitLayers
HKEY_CURRENT_USER\SOFTWARE\Khronos\Vulkan\ImplicitLayers
I would expect that one of these registry keys points at the (now) non-existent JSON file from GOG. At this point it seems like you’d have to remove the entry that points at the GOG layer by hand. As mentioned before the usual warnings about manually editing the registry apply: be certain about what you are doing and its consequences and have backups of your system in case something goes wrong.
Why should I remove a registry key?
This is the loader’s fault, the Vulkan SDK is designed to search for non-existent files.
Could you update the SDK to not look for registry keys?
This is going to trigger multiple times for multiple Vulkan developers/learners.
Alternatively, I’ve thought of an interesting workaround.
What if I reinstall GOG?
Your system is in an inconsistent state: The registry says there is an implicit layer JSON file at C:\ProgramData\GOG.com\Galaxy\redists\overlay\injected\galaxy_overlay_vklayer_x64.json, but it is no longer there. Editing the registry is one way of getting it back in sync with reality - there may well be other, better ways of getting things working again, but I don’t know them.
If you really want to point fingers I would blame the GOG uninstaller that failed to remove that registry key when it removed all the rest of GOG, but maybe it is more productive to get your system working?
Since some layers can be (and are) provided by third parties outside of the SDK, the vulkan loader needs some way to learn about which layers are installed on your system. The Layer Discovery section I linked previously describes how that works for each platform. On Windows the mechanism uses the registry. Changing to a different mechanism is unlikely to fix incorrect uninstall procedures that do not clean up removed layers.
That might work. You’d have to install it to the same location as previously (but I think that was probably the default install location anyway?) and hope GOG has not changed the sub-directory where it keeps the layer. You might also end up with two registry entries that point at the GOG layer (the existing one and one from the new install), I have no idea how the vulkan loader copes with that, it may be benign.
Reinstalling GOG seems to have removed the loader issue.
However, now I have a new issue, what file has failed to open?
Hmm, I’m not sure there is a way for me to know the answer to this one 
One thing you can do to find out is search through your program code for a line that prints that error message. If that does not help, try to find places where the code attempts to open files. You can set breakpoints in the debugger and see what file it wants to open or improve the error handling to include the file name in the error message.
Ah, I found the issue. Due to the reinstall, the Vulkan SDK is in a different folder. So, same steps again on page 104;
- Create compile.bat with
C:\VulkanSDK\1.2.162.1\Bin32\glslc.exe shader.vert -o vert.spv
C:\VulkanSDK\1.2.162.1\Bin32\glslc.exe shader.vert -o vert.spv
pause
- Create shader.frag in the same folder
#version 450
#extension GL_ARB_seperate_shader_objects : enablelayout (location = 0) in vec3 fragColor;
layout (location = 0) out vec4 outColor;
void main()
{
outColor = vec4(fragColor, 1.0);
}
- Create shader.vert in the same folder
#version 450
#extension GL_ARB_seperate_shader_objects : enablelayout (location = 0) out vec3 fragColor;
vec2 positions[3] = vec2
(
vec2( 0.0,-0.5),
vec2( 0.5, 0.5),
vec2(-0.5, 0.5)
);vec3 colors[3] = vec3
(
vec3(1.0, 0.0, 0.0),
vec3(0.0, 1.0, 0.0),
vec3(0.0, 0.0, 1.0)
);
- Run and execute compile.bat
However, this time I get a new error related to GL_ARB.
C:\VulkanSDK\1.2.162.1\Bin32>C:/VulkanSDK/1.2.162.1/Bin32/glslc.exe shader.vert -o vert.spv
shader.vert:2: warning: ‘#extension’ : extension not supported: GL_ARB_seperate_shader_objects
1 warning generated.C:\VulkanSDK\1.2.162.1\Bin32>C:/VulkanSDK/1.2.162.1/Bin32/glslc.exe shader.frag -o frag.spv
shader.frag:2: warning: ‘#extension’ : extension not supported: GL_ARB_seperate_shader_objects
1 warning generated.C:\VulkanSDK\1.2.162.1\Bin32>pause
Press any key to continue . . .
Sigh, it’s a silly mistake.
It’s a filepath issue, replace “shaders” with the actual filepath.
auto vertShaderCode = readFile(“shaders/vert.spv”);
auto fragShaderCode = readFile(“shaders/frag.spv”);
auto vertShaderCode = readFile(“C:/VulkanSDK/1.2.162.1/Bin32/vert.spv”);
auto fragShaderCode = readFile(“C:/VulkanSDK/1.2.162.1/Bin32/frag.spv”);