Check https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/vkGetDeviceProcAddr.html for reference.
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.)
Using 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 )