It clearly states that
vkGetDeviceProcAddr must return
NULL if the requested function pointer belongs neither to a device level extension nor to device level core commands.
If you use
vkGetDeviceProcAddr from the Vulkan loader to load e.g.
vkGetPhysicalDeviceSurfaceFormatsKHR, it’s forwarded all the way to
nvoglv64.dll::vkGetDeviceProcAddr. (All other components in the resolve chain correctly rejected.)
vkGetDeviceProcAddr must return NULL in this case (that is well defined!). While it shouldn’t be used in the first place, that’s actually happening in the real world: https://github.com/KhronosGroup/Vulkan-Hpp/issues/314 (At least with older versions of that header, as little as 6 months old.)
In the case of
vkGetPhysicalDeviceSurfaceFormatsKHR, nvoglv64.dll is faulting even worse, at it doesn’t even return a valid entry point - instead it’s returning the entry to the first layer / terminator.
This then triggers additional bugs, as it means that non-trivial trampolines are straight out skipped. E.g. for
vkGetPhysicalDeviceSurfaceFormatsKHR the loader would first be unwrapping the
VkPhysicalDevice handle in the skipped trampoline code. (See also https://github.com/KhronosGroup/Vulkan-Loader/issues/162 )