Access violation 0xC0000005 during Vulkan GPU initialization on Windows with RTX 5060 + Intel Graphics

[yianzhou]

error log | 日志或报错信息 | ログ

Calling ncnn::create_gpu_instance() / ncnn::get_gpu_count() during application startup triggers a Windows native access
violation:

17:14:29.973: [NcnnVulkanProbe] Start probing Vulkan GPU instance
17:14:30.081: [NcnnVulkanProbe] Vulkan probe triggered exception 0xC0000005, falling back to CPU
17:14:30.081: [NcnnVulkanProbe] Probe completed, use_vulkan_compute=false (CPU)

0xC0000005 is STATUS_ACCESS_VIOLATION.

The relevant code is:

  #include <ncnn/gpu.h>
  #include <windows.h>

  static bool probe_ncnn_vulkan()
  {
      int gpu_count = 0;

      __try
      {
          const int ret = ncnn::create_gpu_instance();
          if (ret != 0)
          {
              return false;
          }

          gpu_count = ncnn::get_gpu_count();
      }
      __except (EXCEPTION_EXECUTE_HANDLER)
      {
          printf("Vulkan probe exception: 0x%08lX\n", GetExceptionCode());
          return false;
      }

      return gpu_count > 0;
  }

There is no normal error return from create_gpu_instance() before the exception is caught.

The application does not terminate because the call is protected by Windows SEH. After catching the exception, all ncnn
networks use:

net.opt.use_vulkan_compute = false;

context | 编译/运行环境 | バックグラウンド

• OS: Windows 11 25H2, 64-bit
• OS build: 10.0.26200.8875
• Computer: Dell Pro Tower Plus QBT1250
• ncnn version: 20260526
• ncnn package: Windows x64, VS2022, shared library
• ncnn DLL: ncnn.dll
• Vulkan is enabled in the ncnn build
• Application architecture: x64
• Application is not running as administrator

GPU configuration:

Adapter 0:
NVIDIA GeForce RTX 5060
vendor ID: 0x10DE
device ID: 0x2D05
dedicated VRAM: approximately 8 GB

Adapter 1:
Intel(R) Graphics
vendor ID: 0x8086
device ID: 0x7D67

Adapter 2:
Microsoft Basic Render Driver

NVIDIA driver information:

NVIDIA-SMI: 595.95
Driver Version: 595.95
CUDA Version: 13.2
Driver Model: WDDM
GPU: NVIDIA GeForce RTX 5060

Intel driver information reported by Vulkan:

Driver Version: 101.8132
Driver ID: DRIVER_ID_INTEL_PROPRIETARY_WINDOWS

vulkaninfo --summary succeeds and enumerates both physical devices:

Vulkan Instance Version: 1.3.301

GPU0:
apiVersion = 1.4.329
driverVersion = 595.95.0.0
vendorID = 0x10de
deviceID = 0x2d05
deviceType = PHYSICAL_DEVICE_TYPE_DISCRETE_GPU
deviceName = NVIDIA GeForce RTX 5060
driverID = DRIVER_ID_NVIDIA_PROPRIETARY

GPU1:
apiVersion = 1.4.325
driverVersion = 101.8132
vendorID = 0x8086
deviceID = 0x7d67
deviceType = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU
deviceName = Intel(R) Graphics
driverID = DRIVER_ID_INTEL_PROPRIETARY_WINDOWS
driverName = Intel Corporation
driverInfo = 101.8132
conformanceVersion = 1.4.0.0

A full vulkaninfo run also completes successfully. It queries device properties, features, extensions, memory properties,
queue families, formats, and video capabilities for both GPUs without crashing.

The NVIDIA device exposes 276 device extensions, including:

VK_KHR_cooperative_matrix revision 2
VK_NV_cooperative_matrix revision 1
VK_NV_cooperative_matrix2 revision 1
VK_NV_cooperative_vector revision 4
VK_KHR_shader_float16_int8 revision 1
VK_KHR_8bit_storage revision 1
VK_KHR_16bit_storage revision 1
VK_KHR_buffer_device_address revision 1

The Vulkan instance layers are:

VK_LAYER_NV_optimus
VK_LAYER_NV_present

vulkaninfo --summary also prints these loader warnings:
Registry lookup failed to get layer manifest files.

WARNING: [Loader Message] Code 0:
vkGetPhysicalDeviceSurfaceCapabilities2KHR:
Emulation found unrecognized structure type in
pSurfaceInfo->pNext - this struct will be ignored.

However, Vulkan device enumeration and the full vulkaninfo run still complete successfully.

how to reproduce | 复现步骤 | 再現方法

1. Use a Windows 11 x64 machine with both of the following GPUs enabled:

   NVIDIA GeForce RTX 5060, driver 595.95
   Intel(R) Graphics 0x7D67, driver 101.8132

2. Link an x64 VS2022 application against the shared Vulkan-enabled ncnn 20260526 package.

3. Run the following code during application startup:

     #include <ncnn/gpu.h>
     #include <cstdio>

     int main()
     {
         std::puts("before create_gpu_instance");

         const int ret = ncnn::create_gpu_instance();

         std::printf("after create_gpu_instance, ret=%d\n", ret);

         if (ret == 0)
         {
             std::puts("before get_gpu_count");

             const int count = ncnn::get_gpu_count();

             std::printf("after get_gpu_count, count=%d\n", count);
         }

         return 0;
     }

4. On the affected machine, the application triggers native exception 0xC0000005 during the Vulkan initialization/probe
   instead of returning a normal Vulkan error code.

In the production application, the calls are currently placed in the same SEH block, so we cannot yet distinguish with
certainty whether the exception is inside create_gpu_instance() or get_gpu_count(). Based on the missing successful
creation log and the work performed by ncnn during GPU instance initialization, create_gpu_instance() is the more likely
location.

more | 其他 | その他

The system Vulkan installation appears generally functional because both vulkaninfo --summary and the full vulkaninfo
command complete successfully and enumerate both GPUs.

This may be related to one of the following:

• An ncnn GPU capability/extension query performed after basic physical-device enumeration.
• The NVIDIA VK_NV_cooperative_vector or cooperative matrix query path.
• Interaction with the new NVIDIA Vulkan 1.4 driver and the older Vulkan Loader version 1.3.301.
• Interaction with VK_LAYER_NV_optimus or VK_LAYER_NV_present.
• NVIDIA and Intel physical devices being enumerated in the same process.

Could you please advise:

1. Which Vulkan properties and extensions are queried inside create_gpu_instance() for this ncnn version?
2. Whether there are known issues involving RTX 50-series GPUs, NVIDIA driver 595.95, or VK_NV_cooperative_vector.
3. Whether there is an existing option to disable cooperative vector/matrix capability probing.
4. How to enable detailed ncnn Vulkan initialization logs to identify the exact query that triggers the access violation.
5. Whether create_gpu_instance() can be changed to skip a faulty physical device or unsupported extension instead of
   terminating with an access violation.

A full vulkaninfo log and the application probe log can be attached if needed.

nvidia-smi.log

vulkaninfo.log

[dosubot]

Hi @yianzhou! I'm Dosu and I'm helping the 腾讯开源's Org team.

I looked into the create_gpu_instance() initialization flow and the most likely crash location is the VK_NV_cooperative_vector property query. Here's a breakdown addressing your questions:

1. Vulkan extensions queried during create_gpu_instance()

After enumerating physical devices, ncnn runs a per-device probing loop that queries device extensions, then extension features, then extension properties [1]. The cooperative-related extensions it detects include VK_KHR_cooperative_matrix, VK_NV_cooperative_matrix, VK_NV_cooperative_matrix2, and VK_NV_cooperative_vector [2]. After detection, it calls into the driver to query features and properties for each — notably calling vkGetPhysicalDeviceCooperativeVectorPropertiesNV twice (once for count, once for data). This is the most likely crash point, as it's a relatively new Vulkan extension and RTX 5060 with driver 595.95 may have a buggy implementation of this entry point.

2. Known issues with RTX 50-series / driver 595.x

This appears to be a new issue — no prior reports involving RTX 50-series or NVIDIA driver 595.x were found in the ncnn issue tracker. However, ncnn already maintains device-specific workarounds for AMD RDNA2 [3] and Qualcomm Adreno [4] to disable cooperative matrix on those vendors, so adding a similar workaround for this NVIDIA GPU+driver combination would follow established patterns.

3. Disabling cooperative vector/matrix probing

There is currently no runtime option or environment variable to disable this probing. It's hardcoded in the initialization path. As a source-level workaround, you can force-disable the extensions after the detection loop by adding something like this around line 869 in src/gpu.cpp:

support_VK_NV_cooperative_vector = 0;
support_VK_NV_cooperative_matrix2 = 0;
// optionally also:
// support_VK_NV_cooperative_matrix = 0;
// support_VK_KHR_cooperative_matrix = 0;

Then recompile ncnn.

4. Enabling detailed Vulkan initialization logs

There is no runtime log-level environment variable. Most initialization log lines in src/gpu.cpp are commented out [5]. To get verbose output you need to:

• Uncomment the NCNN_LOGE statements in query_extensions(), query_extension_features(), and query_extension_properties()
• Optionally set ENABLE_VALIDATION_LAYER to 1 at line 30 of src/gpu.cpp to enable Vulkan validation layer callbacks
• Recompile

Adding a log line just before the vkGetPhysicalDeviceCooperativeVectorPropertiesNV call at line 1621 would confirm whether that's the exact crash point.

5. Graceful degradation / skipping faulty devices

Currently, the extension query functions check VkResult return codes and log errors but do not use any structured exception handling [6]. If the driver crashes (access violation) rather than returning an error code, ncnn has no way to recover. A possible improvement would be to either add SEH guards (on Windows) around the cooperative vector/matrix query calls, or to add a device-ID-based blacklist similar to the existing AMD RDNA2 pattern — skipping these extension queries for known-buggy device+driver combinations.

Suggested next steps:

• Try updating to the latest NVIDIA driver (if a newer one is available) to see if this is fixed on NVIDIA's side
• If you can build ncnn from source, add a log line before line 1621 and force support_VK_NV_cooperative_vector = 0 to confirm the crash location and work around it
• Attaching a minidump or stack trace from the SEH exception would help pinpoint the exact Vulkan call

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.