[Bug] Opening Image Viewer And Media Player Crashes The App!

Thanks, the screenshot helps. That's Windows marking the VM window as not responding, so the display is hanging rather than the whole app crashing.

The fps difference is a useful clue. Automatic tries GPU rendering first, but if a GPU start ever fails it remembers that and uses CPU rendering from then on. So on your machine Automatic may actually be running on the CPU, and GPU mode is where the hang happens.

Could you reproduce it once more, then use Create diagnostics... from the tray icon and attach the ZIP here? Please tell me which rendering mode you were in for that run, and look through the ZIP before posting it since logs can include local details.

The next release also changes how images are handed to the host GPU driver, which is the path Image Viewer and Media Player use in GPU mode, so it's worth retrying once that's out. Your logs will help pin down anything that's left.

try-omarchy-diagnostics-20261004-204722.244902500.zip

@btsouth here it is, I was in auto

NOTE

Posted by an AI agent on behalf of Tyler.

Thanks, this is really helpful. It also rules out my CPU theory: Automatic was using GPU rendering, the same as GPU mode. The logs show the VM's display loop stopping a couple of minutes after the desktop came up, which matches the freeze you saw.

Your laptop has both Intel graphics and the RTX 5090, so the next step is finding out whether one of them is the trigger. Two things would help:

1. When the next release is out, try Image Viewer and Media Player again. It changes exactly how images are shared with the GPU driver.
2. If it still freezes, open Windows Settings > System > Display > Graphics, add qemu-system-x86_64w.exe from %LOCALAPPDATA%\TryOmarchy\runtime\bin, and set it to High performance. Try again, then set it to Power saving and try once more. Let me know which of those freeze.

NOTE

Posted by an AI agent on behalf of Tyler.

v0.9.0 is out now, so step 1 above is ready to try. Your launcher should update on its own within a few hours.

@btsouth I installed the new update, I am running my pc on ultimate mode. the display is handled by the discrete gpu. also additionally to be 100% sure I did step 2 as u mentioned. the issue is still there.

image viewer and video player are still broken.

also this time I tried automatic mode, cpu mode, and gpu mode. same issue in all of them

Thank you for testing and reporting back. I am digging into it now, will keep you updated.

@btsouth Does that mean nvidia gpus cant get the benefits of venus/vulkan renderer and how that affects performance? Also is the only solution is to turn it off?

0.10.0 is out with a fix for this: https://github.com/omacom/try-omarchy-windows/releases/tag/v0.10.0

When you have a chance, could you update and try Media Player and Files in GPU mode again? Let me know if it still freezes, and if it does, the diagnostics from the tray would help a lot.

@btsouth I updated It seems like the media player issue is fixed, it opens and it doesnt crash anymore.

I read in the commits u did that you turns off venus on nvidia gpus, does that mean nvidia gpus cant get the benefits of venus/vulkan renderer and how that affects performance? Also is the only solution is to turn it off?

also is it normal behavior to get a dark empty screen when I open the image viewer app?

NOTE

Posted by an AI agent on behalf of Tyler.

Glad Media Player works now, thanks for testing it.

Turning off Venus only affects Vulkan. The VM still renders on your GPU through OpenGL, which is what the desktop, browser, terminal and most apps use, so those keep their GPU acceleration. Apps that need Vulkan fall back to software Vulkan inside the VM and will be slower.

Turning it off was a stopgap, not the fix. Vulkan through Venus froze the display on several NVIDIA cards, including yours, and I'm now working on the underlying bug so Venus can come back on for NVIDIA. If you want to try it before then, set the Windows environment variable TRYOMARCHY_VENUS=on and restart Try Omarchy. Expect the same freezes you saw before.

The dark window is normal. Image Viewer is imv, and opening it from the launcher without a file shows an empty black window. Open an image from Files and it should display. If it doesn't, let me know.

@btsouth Okay please keep me updated, there are many programs that depend on vulkan and we need gpu acceleration for them.

NOTE

Posted by an AI agent on behalf of Tyler.

Will do. Could you try one thing that may bring Vulkan back on your NVIDIA GPU? It's a quick test.

1. In PowerShell, run:

[Environment]::SetEnvironmentVariable('TRYOMARCHY_VENUS', 'on', 'User')
[Environment]::SetEnvironmentVariable('WINQ_DMABUF_SHIM_OFF', '1', 'User')

2. Shut down Try Omarchy from the tray, then start it again.
3. In Omarchy, open Files and double-click a video so it plays in Media Player.

Let us know whether the video plays or the screen freezes. If it freezes, Shut down in the tray gets you out like before.

The second setting changes how Vulkan apps hand their frames to the desktop, so they skip the step that froze on NVIDIA. They still render on your GPU.

To undo both afterwards:

[Environment]::SetEnvironmentVariable('TRYOMARCHY_VENUS', $null, 'User')
[Environment]::SetEnvironmentVariable('WINQ_DMABUF_SHIM_OFF', $null, 'User')

@btsouth I wrote the 2 commands u gave in in poweshell and applied them. I tried to open media player, and it froze. I tried to play minecraft on vulkan and it froze too.

media player + minecraft over opengl was working fine.

so yes the problem with venus is still there. but my gpu supports vulkan 1.3 !

so this is the current status, do u need any new diagnostics files?

some maybe usefull pieces of information that may help fix the problem or /improve the experience:

• AI told me to check that the guest machine has the latest mesa drivers.

Some potentially useful debugging points for the NVIDIA Venus freeze:

• Since both Media Player and Minecraft freeze with Vulkan/Venus, while OpenGL works, this looks broader than an app-specific issue.
• I tested WINQ_DMABUF_SHIM_OFF=1 with Venus forced on and it still froze, so the DMA-BUF shim probably isn't the root cause.
• The Windows Venus path seems worth checking around VK_EXT_external_memory_host / VK_EXTERNAL_MEMORY_HANDLE_TYPE_HOST_ALLOCATION_BIT_EXT. A normal Vulkan image may be supported while the same format/usage/tiling combination with external-memory constraints is not.
• The RTX 5080 test hitting VK_ERROR_FORMAT_NOT_SUPPORTED around image creation may be an important clue. Logging the exact format/type/tiling/usage/flags/samples/handle-type tuple passed to vkGetPhysicalDeviceImageFormatProperties2 could help.
• It may also be useful to temporarily force plain Vulkan image/device-memory backing, disabling the host-imported alternate-image path entirely. If NVIDIA stops freezing, that would narrow it strongly toward the external-memory path.
• If image creation succeeds, instrument the later stages too: bind → image view → acquire → submit → fence/semaphore waits → present. Since this becomes a hang rather than always returning a Vulkan error, presentation/synchronization could be a separate issue.
• WINQ already needed VN_PERF=no_async_present for a Windows/AMD Venus deadlock, so testing a fully serialized/no-async presentation path on NVIDIA may also be useful.

A very small repro that progressively tests image creation → offscreen render → swapchain/present might help isolate the exact point much faster than testing full applications.

• Also he suggested to investigate a driver-level NVIDIA virtualization backend inspired by virtio-nvgpu, and see whether its virtio protocol/device model can be reused while replacing the Linux /dev/nvidia* backend with a Windows-native GPU backend.

NOTE

Posted by an AI agent on behalf of Tyler.

Thanks for testing, that rules out the dma-buf switch. You can remove it:

[Environment]::SetEnvironmentVariable('WINQ_DMABUF_SHIM_OFF', $null, 'User')

Two things would help next.

1. The launcher saved diagnostics at both freezes. They're in the diagnostics folder of your Try Omarchy data folder, named try-omarchy-diagnostics-20261007-120934...zip and try-omarchy-diagnostics-20261007-121239...zip. Could you attach those two?

2. Your laptop has both the RTX 5090 and Intel graphics, and we want to see which one Vulkan uses inside Omarchy. Keep TRYOMARCHY_VENUS=on, restart Try Omarchy, then in an Omarchy terminal run:

mpv --vulkan-device=help

This only lists devices and won't open a window. Please paste the output. If it lists more than one device, try playing a video on each one by name, for example:

mpv --vulkan-device='NAME FROM THE LIST' ~/Videos/some-video.mp4

and tell us which one freezes and which one plays.

tried running the command with the igpu, the omarchy guest machine itself froze, but the application didnt get into not responding state. with the dedicated gpu the omarchy guest machine seemed okay but froze, but this time the application got into not responding state and windows prompted me to close it.

Some potentially useful debugging points for the NVIDIA Venus freeze:

• Since both Media Player and Minecraft freeze with Vulkan/Venus, while OpenGL works, this looks broader than an app-specific issue.
• I tested WINQ_DMABUF_SHIM_OFF=1 with Venus forced on and it still froze, so the DMA-BUF shim probably isn't the root cause.
• The Windows Venus path seems worth checking around VK_EXT_external_memory_host / VK_EXTERNAL_MEMORY_HANDLE_TYPE_HOST_ALLOCATION_BIT_EXT. A normal Vulkan image may be supported while the same format/usage/tiling combination with external-memory constraints is not.
• The RTX 5080 test hitting VK_ERROR_FORMAT_NOT_SUPPORTED around image creation may be an important clue. Logging the exact format/type/tiling/usage/flags/samples/handle-type tuple passed to vkGetPhysicalDeviceImageFormatProperties2 could help.
• It may also be useful to temporarily force plain Vulkan image/device-memory backing, disabling the host-imported alternate-image path entirely. If NVIDIA stops freezing, that would narrow it strongly toward the external-memory path.
• If image creation succeeds, instrument the later stages too: bind → image view → acquire → submit → fence/semaphore waits → present. Since this becomes a hang rather than always returning a Vulkan error, presentation/synchronization could be a separate issue.
• WINQ already needed VN_PERF=no_async_present for a Windows/AMD Venus deadlock, so testing a fully serialized/no-async presentation path on NVIDIA may also be useful.

A very small repro that progressively tests image creation → offscreen render → swapchain/present might help isolate the exact point much faster than testing full applications.

• Also he suggested to investigate a driver-level NVIDIA virtualization backend inspired by virtio-nvgpu, and see whether its virtio protocol/device model can be reused while replacing the Linux /dev/nvidia* backend with a Windows-native GPU backend.

here are the two diagnositcs files:

try-omarchy-diagnostics-20261007-143317.130687700.zip

try-omarchy-diagnostics-20261007-120934.720152800.zip try-omarchy-diagnostics-20261007-121239.653903400.zip

NOTE

Posted by an AI agent on behalf of Tyler.

Thanks for the ZIPs and for testing both GPUs. Since both freeze, it isn't Vulkan picking the wrong GPU.

If you're up for one more test: keep TRYOMARCHY_VENUS=on, start Try Omarchy, and paste this into an Omarchy terminal:

VN_PERF=no_async_present,no_timeline_sync,no_semaphore_feedback,no_multi_ring mpv --no-config --hwdec=no --ao=null --gpu-api=vulkan --vulkan-device=c4e7fd27-2323-51d4-1dff-e9ee56a89165 av://lavfi:testsrc

It plays a moving test pattern on your RTX 5090, so you don't need a video file. Just tell us whether the pattern plays or the screen freezes. If it plays, we may be able to ship that setting as a fix.

@btsouth I tested the command, the screen freezes and the app crashes.

NOTE

Posted by an AI agent on behalf of Tyler.

Thanks for running it. That rules out the sync settings, so the freeze is deeper in how Vulkan work from Omarchy reaches the NVIDIA driver on Windows. We saw the same freeze on our own NVIDIA machine, so the next step is on our side: a build that logs each Vulkan call so we can see exactly where it stops.

For normal use, turn Venus back off so Vulkan apps don't freeze in the meantime:

[Environment]::SetEnvironmentVariable('TRYOMARCHY_VENUS', $null, 'User')

Then shut down Try Omarchy from the tray and start it again. I'll update here when there's something to try.