[BUG] AMD iGPU driver crashes

[sedlund]

Bug Description

Handy will cause my AMD iGPU driver to crash. Occurs when pressing the activation key that ends transcription.

It occurs during normal use, usually if I start quickly after stopping. But I can reliably trigger it by repeatedly retranscribing the same clip in the history dialogue .

Screenshot of the AMD bug reporting tool over handy triggered during filling this bug report .

The screen will blank, the mouse will stop moving, I'll get garbage on the display, and then the driver resets . I can still trigger handy to start and stop, it sounds like, from the audible sounds, But it won't actually transcribe, so I have to quit and restart it .

This crash is with Parakeet Unified 0.6B In the screenshot. I just caused it to happen again using Nemotron Three Point Five streaming. By clicking retranscribe on each of the five in my history sequentially and rotating about seven different times and waiting for each transcription to complete, and then it crashed again. The log file will have both crashes.

System Information

App Version:

Currently 0.9.6 but occured in prior versions like 0.9.5 I think before as well, but I wasn't sure that it was handy before.

Operating System:

Win 11 - up to date with current AMD drivers.

CPU:

Ryzen 6900HS (laptop). The system has 40 gigabytes of RAM And Windows currently says it's 42% in use .

GPU:

running on the iGPU 680M --- Laptop has RTX 3600 disabled in eco mode.

Logs

handy.log

here is a windows event from an earlier crash of stock 0.9.6:

Faulting application name: handy.exe, version: 0.0.0.0, time stamp: 0x6a8bf2b2
Faulting module name: ggml-base.dll, version: 0.0.0.0, time stamp: 0x6a8bee83
Exception code: 0xc0000005
Fault offset: 0x0000000000002019
Faulting process id: 0x2750
Faulting application start time: 0x1DD379A8F74EB89
Faulting application path: C:\Users\Scott\scoop\apps\handy\current\handy.exe
Faulting module path: C:\Users\Scott\scoop\apps\handy\current\ggml-base.dll
Report Id: e2b86611-74f5-4185-b369-620906edf6b2
Faulting package full name: 
Faulting package-relative application ID: 

[cjpais]

@sedlund are you still running the debug build from the other thread, just curious if it has helped at all with the driver crashes or has made them worse. That code actually should contain a mitigation for the issue you have but I might have some ideas in addition.

If you're able, also run this in powershell after quitting handy. It might help us get some more diagnostics and potentially resolve your issue

$env:GGML_VK_MAX_NODES_PER_SUBMIT="1" & "$env:ProgramFiles\Handy\handy.exe" --debug

[sedlund]

Still running the debug build. The attached log is from that build and the command you gave above (with a semi colon) like:

$env:GGML_VK_MAX_NODES_PER_SUBMIT="1"; & "$env:ProgramFiles\Handy\handy.exe" --debug

handy.log

and another

handy.log

I can still cause the driver crash in the stock build and the debug build Indistinguishably.

Here are two recordings that I found were problematic. Retranscribing them multiple times helped force the issue also switching between parakeet and nemotron . These are recordings of a YouTube video playing through laptop speakers and recorded through the mic.

handy-1788170203.wav
handy-1788165751.wav

I keep History limited to 5, but my recordings directory had older entries than the 5, and realized these were the recordings that the driver crashed on, although I deleted these before I realized what they were. Still don't know if it's recording related or if it's something else .

[cjpais]

Okay would you mind trying a few more things? Of course to get around this in totality you can turn on the experimental settings and change to CPU based inference and should avoid this. But if you don't mind I'm quite curious to get to the root of everything as well.

  $env:GGML_VK_MAX_NODES_PER_SUBMIT="1"
  $env:TRANSCRIBE_NO_FLASH="1"
  & "$env:ProgramFiles\Handy\handy.exe" --debug

and if it still crashes

  $env:GGML_VK_MAX_NODES_PER_SUBMIT="1"
  $env:TRANSCRIBE_NO_FLASH="1"
  $env:GGML_VK_SERIALIZE_SUBMISSIONS="1"
  & "$env:ProgramFiles\Handy\handy.exe" --debug

[sedlund]

Tried both. Got both to crash the driver.

Attached:

handy.log

[cjpais]

@sedlund I'm kind of running out of ideas at the moment. What is the version of your driver and is it the latest version of the driver? Does this happen with other (non-nvidia streaming models?)

Basically, the operation the driver crashes on seems extremely benign, so it's not exactly clear.. I do have more tests if you're willing. Basically just trying to disable optimizations to see if we can avoid it.

  $env:GGML_VK_MAX_NODES_PER_SUBMIT="1"
  $env:TRANSCRIBE_NO_FLASH="1"
  $env:GGML_VK_SERIALIZE_SUBMISSIONS="1"
  $env:GGML_VK_DISABLE_FUSION="1"
  & "$env:ProgramFiles\Handy\handy.exe" --debug

and again if it still crashes

  $env:GGML_VK_MAX_NODES_PER_SUBMIT="1"
  $env:TRANSCRIBE_NO_FLASH="1"
  $env:GGML_VK_SERIALIZE_SUBMISSIONS="1"
  $env:GGML_VK_DISABLE_FUSION="1"
  $env:GGML_VK_DISABLE_INTEGER_DOT_PRODUCT="1"
  & "$env:ProgramFiles\Handy\handy.exe" --debug

[sedlund]

I tried Qwen3 ASR 0.6B - no issues after hammering on it. After searching the differences the AI's led me to these, and smells the same as this issue.

leejet/stable-diffusion.cpp#1340
ggml-org/ggml#1437

AMD iGPUs in the ggml Vulkan backend have known crash issues (shared memory limits of ~32 KB, workgroup size mismatches, DeviceLost from GPU job timeouts). The FastConformer encoder + transducer decoder used by Parakeet and Nemotron generates Vulkan compute kernels that hit these limits, while Qwen3-ASR's standard LLM decoder does not.

If you still think it's worthwhile for me to test those env args above, or have a specific one in mind, let me know

[cjpais]

I think it's not the quite same issue, but I will come back with probably some more things to test

[sedlund]

What is the version of your driver and is it the latest version of the driver?

Latest: 32.0.21045.5002

I will come back with probably some more things to test

I appreciate your help.