[Bug]: core.available_devices crashes with microsoft OpenCLOn12

[hughsando]

OpenVINO Version

2025.4.1

Operating System

Windows System

Device used for inference

GPU

Framework

None

Model used

No response

Issue description

GPU device enumeration (eg, core.available_devices) crashes with the most recent "OpenCL™, OpenGL®, and Vulkan® Compatibility Pack" installed from the Microsoft App store.

This creates a new OpenCL platform, "OpenCLOn12" and it appears that the GPU plugin is compiling some program during the enumeration, and this compilation is failing.

It would be handy to have an explicit list of vendors for GPU enumeration since we are only generally interested in the Intel vendor.

Step-by-step reproduction

Install OpenCL™, OpenGL®, and Vulkan® Compatibility Pack from Microsoft App store
Run the Python:

from openvino import Core
core = Core()
print(core.available_devices)

Relevant log output

Issue submission checklist

• I'm reporting an issue. It's not a question.
• I checked the problem with the documentation, FAQ, open issues, Stack Overflow, etc., and have not found a solution.
• There is reproducer code and related data files such as images, videos, models, etc.

[hlevring]

This is a highly critical issue.
We have had several report of our app crashing in the last week due to this issue

As soon as you install Microsoft's latest update of OpenCL™, OpenGL®, and Vulkan® Compatibility Pack
https://apps.microsoft.com/detail/9nqpsl29bfff
core.available_devices crashes

Also happens with openvino 2025.4.0 which is the lowest version we can use. (most likely happens with any version of openvino).

Perhaps a popular game started installing this?

If OpenCLOn12 enumerates as a separate OpenCL platform with "Vendor: Microsoft" why is this not easily handled by Openvino?

[hlevring]

It look like Openvino 2025.3 does not crash because it does not instantiate non-intel platforms.

[jenatali]

Sorry about that, I missed that there was an interface update that needed to be accounted for. Version 1.2602.1.0 should roll out later today and resolve this.

[hlevring]

Version 1.2602.1.0 should roll out later today and resolve this.

@jenatali thanks for resolving this. Can you let us know how the roll out process for existing installations will be? Will it happen automatically without user intervention ? User who have downloaded the exe installer directly from https://apps.microsoft.com/detail/9nqpsl29bfff will they also get updated automatically without user intervention (I think some games may also be bundling the exe installer) ? (ok seems to always get from the store)

Basically I want to figure out how long time we could potentially be dealing with the aftermath and if we may need to take further actions on our end.

[jenatali]

No further actions on your end should be needed. Systems should check for updates ~daily, so the issue should be completely resolved shortly.

[krgkaushik]

Hi @hlevring,

Great to see the fix is incoming!

For your immediate "aftermath" concern: Since this crash occurs during driver enumeration (which can cause a hard segfault that kills the main process), standard exception handling might not catch it.

Advice: Run your device discovery (core.available_devices) in a separate subprocess (using Python's multiprocessing or subprocess module) with a short timeout.

If the subprocess returns successfully: You know it's safe to use the GPU.

If the subprocess crashes/times out: You detect the bad driver environment safely. You can then automatically fallback to CPU or NPU for that session without your main application crashing.

This "canary" check protects your users regardless of when the Microsoft Store update hits their machine.