whisper-cli / parakeet-cli: any non-ASCII -m path aborts with 0xC0000409 on MSVC Windows builds

[hiros0921]

Summary

On the official Windows release binary, whisper-cli.exe terminates with
STATUS_STACK_BUFFER_OVERRUN (0xC0000409) instead of printing failed to open ...,
when -m points to a file that does not exist and whose ANSI representation contains a
byte >= 0x80. No error message is printed at all.

Reproduction

Japanese Windows 11 (ACP 932), official b4938 whisper-bin-x64.zip:

whisper-cli.exe -m あ.bin -f samples\jfk.wav

where あ.bin does not exist. A single non-ASCII character is enough.

Observed:

load_backend: loaded CPU backend from ...\ggml-cpu-haswell.dll
whisper_init_from_file_with_params_no_state: loading model from '...\??.bin'

and the process then exits with 3221226505 (0xC0000409). Nothing further is printed.

Expected — what an ASCII path does (-m a.bin):

whisper_init_from_file_with_params_no_state: loading model from '...\a.bin'
whisper_init_from_file_with_params_no_state: failed to open '...\a.bin'
error: failed to initialize whisper context

exit code 3.

Reproduced 3/3, both through a normal PowerShell launch and through CreateProcess.

What decides whether it happens

The trigger is whether the path, after conversion to the ANSI code page for argv,
contains a byte >= 0x80 — not whether the character is Japanese.

model path	representable in CP932	argv bytes	official b4938	own MinGW build
nonexistent	yes	ASCII	exit 3	exit 3
あ (U+3042)	yes	82 a0	0xC0000409	exit 3
日本語モデル	yes	93 fa 96 7b 8c ea 83 82 83 66 83 8b	0xC0000409	exit 3
Ω (U+03A9)	yes	83 b6	0xC0000409	exit 3
é (U+00E9)	no → best-fit e	65	exit 3	exit 3
한글	no → ??	3f 3f	exit 3	exit 3
😀 (U+1F600)	no → ??	3f 3f	exit 3	exit 3

Characters that the ANSI code page cannot represent are converted to ASCII before
argv is formed, so they never produce a high byte and do not trigger it.

Additional observations

• Building the same commit (97811330) locally with MinGW-w64 GCC 16.2.0 exits 3
  cleanly in every row above, so I only observe this with the released MSVC build.
• -f with a missing non-ASCII path exits 2 cleanly. Only -m is affected.
• An existing non-ASCII model or audio path works normally (exit 0, correct
  transcription), so this is specific to the missing-file path.

Environment

Windows 11 Pro 10.0.26200.9168, system ANSI code page 932, chcp 932,
official release b4938 (whisper-cli.exe reports whisper.cpp version: 1.9.3).

What I did not determine

• The cause. I did not attach a debugger or determine which call fails.
• Whether this reproduces on Windows installations with a different ANSI code page.
  My data only shows the trigger is a high byte in the ANSI argv; which characters
  produce one depends on the code page, and I could only test CP932.
• Whether earlier releases behave the same way.

[principia-trinity]

The cause is the UTF-8 conversion applied to the model path, and it runs before the file is ever opened.

whisper_init_from_file_with_params_no_state (src/whisper.cpp:3706-3712, master at c4ac0012):

    WHISPER_LOG_INFO("%s: loading model from '%s'\n", __func__, path_model);
#ifdef _MSC_VER
    // Convert UTF-8 path to wide string (UTF-16) for Windows, resolving character encoding issues.
    std::wstring_convert<std::codecvt_utf8<wchar_t>> converter;
    std::wstring path_model_wide = converter.from_bytes(path_model);
    auto fin = std::ifstream(path_model_wide, std::ios::binary);
#else

from_bytes throws std::range_error when its input is not valid UTF-8. Nothing between that call and main catches it, so it reaches std::terminate, and MSVC ends the process through __fastfail(FAST_FAIL_FATAL_APP_EXIT). That is reported as 0xC0000409. The log line above it has already been flushed, which is why output stops exactly where you saw it stop.

This also explains the shape of your table. -m is affected because it goes through this conversion; -f is not, because the audio path does not. The rows that survive are the ones the ANSI code page could not represent, so best-fit conversion had already reduced them to ASCII before argv was formed. MinGW is unaffected because the conversion sits inside #ifdef _MSC_VER.

I reproduced it on Windows 11 26200, ACP 1252, building master c4ac0012 locally with MSVC 14.44 rather than using a release binary, so this is not specific to b4938:

-m missingmodel.bin -f samples/jfk.wav
  whisper_init_from_file_with_params_no_state: loading model from 'missingmodel.bin'
  whisper_init_from_file_with_params_no_state: failed to open 'missingmodel.bin'
  error: failed to initialize whisper context
  exit=3

-m é.bin -f samples/jfk.wav          (argv byte e9, missing file)
  whisper_init_from_file_with_params_no_state: loading model from '?.bin'
  exit=-1073740791 (0xC0000409)

Your rule that the trigger is a high byte in the ANSI argv rather than any particular script holds here: CP1252 é is a single byte e9, and it aborts the same way your CP932 82 a0 does. Checking the conversion in isolation on this machine:

ascii        bytes: 61 2e 62 69 6e        -> OK, wide len=5
cp1252 e9    bytes: e9 2e 62 69 6e        -> THROWS bad conversion
cp932 82a0   bytes: 82 a0 2e 62 69 6e     -> THROWS bad conversion
valid utf8   bytes: c3 a9 2e 62 69 6e     -> OK, wide len=5

One thing in your report does not hold up, and it matters for how this gets closed. You note that an existing non-ASCII model path works normally, and conclude the bug is specific to the missing-file case. The conversion happens before std::ifstream is constructed, so existence cannot affect whether it throws. I tested that directly by creating a file actually named é.bin and passing it:

-m é.bin   (file exists, 18 bytes, invalid model)   exit=-1073740791 (0xC0000409)
-m bad_ascii.bin (file exists, 18 bytes, invalid)   whisper_model_load: invalid model data (bad magic)
                                                    exit=3

The existing non-ASCII path aborts identically, while the existing ASCII path reaches the model parser and reports bad magic. So this is not a missing-file bug; it is a non-ASCII-argv bug, and the missing-file case is just where you happened to meet it. If your working setup really does load a non-ASCII model, the bytes reaching path_model in that run were valid UTF-8 or plain ASCII. It would be worth re-running that case with the same あ.bin name that crashes and reporting chcp, since whatever normalises them there is the difference.

There is already an open fix for the two src/whisper.cpp sites. #3650 (opened 2026-02-06) replaces both with MultiByteToWideChar, attempting UTF-8 and falling back to CP_ACP, and its description names this same 0xC0000409 mechanism. It has not been reviewed.

That PR no longer covers the whole surface. src/parakeet.cpp:3049-3054 carries the same construct verbatim, comment included:

struct parakeet_context * parakeet_init_from_file_with_params_no_state(const char * path_model, struct parakeet_context_params params) {
    PARAKEET_LOG_INFO("%s: loading model from '%s'\n", __func__, path_model);
#ifdef _MSC_VER
    // Convert UTF-8 path to wide string (UTF-16) for Windows, resolving character encoding issues.
    std::wstring_convert<std::codecvt_utf8<wchar_t>> converter;
    std::wstring path_model_wide = converter.from_bytes(path_model);

src/parakeet.cpp first appears in the history on 2026-06-16, four months after #3650 was opened, so the PR predates the file and touches only src/whisper.cpp (+32/-9). The site is reachable exactly the way this report is: examples/parakeet-cli/parakeet-cli.cpp takes -m at line 58 and calls parakeet_init_from_file_with_params at line 137. Building parakeet-cli from the same tree reproduces it:

-m missing_ascii.bin -f samples/jfk.wav
  parakeet_init_from_file_with_params_no_state: loading model from 'missing_ascii.bin'
  parakeet_init_from_file_with_params_no_state: failed to open 'missing_ascii.bin'
  error: failed to load Parakeet model from 'missing_ascii.bin'
  exit=1

-m é_pk.bin -f samples/jfk.wav       (argv byte e9)
  Loading Parakeet model from: ?_pk.bin
  parakeet_init_from_file_with_params_no_state: loading model from '?_pk.bin'
  exit=-1073740791 (0xC0000409)

So merging #3650 as it stands closes whisper-cli and leaves parakeet-cli aborting identically.

tests/test-parakeet.cpp:62 already has a test_invalid_model_load that exercises this branch with an ASCII path, so a regression test for the non-ASCII case has somewhere natural to go.

Verification

• Line numbers and quotes checked against master c4ac0012 in this pass.
• whisper-cli crash, existing-file control, ASCII control, and the parakeet-cli pair all reproduced locally on Windows 11 26200 / ACP 1252 / MSVC 14.44, built from source.
• Not tested on CP932. I do not have a Japanese-locale machine, so the CP932 rows above come from converting those bytes directly, not from running whisper-cli under ACP 932.

[hiros0921]

@principia-trinity You are right and my statement was wrong. Thank you for testing it directly, and for the source-level trace.

Correction

I wrote:

An existing non-ASCII model or audio path works normally (exit 0, correct
transcription), so this is specific to the missing-file path.

I never ran that case for -m. Going back through my logs, the run that sentence was based on is:

whisper-cli.exe -m ggml-tiny.bin -f 日本語音声.wav -l ja

The model path there is ASCII and only the audio path is non-ASCII. I then compressed it into "model or audio path" as a single clause, which turned a measurement of -f into a claim about both. The "missing-file" framing in the title and in the summary follows from that same mistake. You asked whether something was being normalised differently in my working case — there was nothing to find, I simply had not run it.

Re-measured on ACP 932

chcp 932, ACP 932, Windows 11 Pro 26200.9168, official b4938 release binary
(whisper-bin-x64.zip; whisper-cli.exe md5 3d60aed4cc8692e894dff49388596938,
reports whisper.cpp version: 1.9.3).

To remove any doubt about the file being real, I copied the working model to a non-ASCII name — identical bytes:

ab7280bbcf29e334f7e3b2a9ac0ca386  ggml-tiny.bin
ab7280bbcf29e334f7e3b2a9ac0ca386  あ.bin

-m argument	file state	exit
ascii_ok.bin	exists, valid model	0
あ.bin	exists, byte-identical to the above	-1073740791 (0xC0000409)
bad_ascii.bin	exists, 18 bytes, invalid	3
あ_bad.bin	exists, 18 bytes, invalid	-1073740791
missing_ascii.bin	missing	3
あ_missing.bin	missing	-1073740791

Console output for the existing, valid あ.bin, read back from the console screen buffer:

load_backend: loaded CPU backend from ...\ggml-cpu-haswell.dll
whisper_init_from_file_with_params_no_state: loading model from 'C:\...\あ.bin'

and then nothing — the same stop point as the missing-file case. With ascii_ok.bin, the same bytes under an ASCII name, it loads and transcribes normally (exit 0).

So file existence is irrelevant, exactly as your reading of from_bytes predicts. This is a non-ASCII argv bug; the missing-file case is just the one I happened to test.

For completeness, the -f branch — the one I actually measured:

	exit
-f 日本語音声.wav exists, valid	0
-f あ_missing.wav missing	2

And my own MinGW build of the same source on the same machine: -m あ.bin (exists) exits 0, -m あ_missing.bin exits 3 — consistent with the conversion sitting inside #ifdef _MSC_VER.

CP932, since you could not run it

Your conversion table matches what the binary actually does under ACP 932. 82 a0 crashes, and the é row does not, because CP932 cannot represent it and best-fit mapping turns it into e before argv is formed — no high byte, so no throw. The rule holds on both code pages.

parakeet-cli

Your src/parakeet.cpp finding reproduces here too, on the release binary under ACP 932
(parakeet-cli.exe md5 630b76a818930c31e1f6dfe89bec0c51):

parakeet-cli -m	exit
missing_ascii.bin	1
あ_missing.bin	-1073740791
あ_bad.bin (exists, invalid)	-1073740791

So both sites are affected on this locale as well, and your point that merging #3650 as it stands would close whisper-cli while leaving parakeet-cli crashing holds here. That connection, and the fact that src/parakeet.cpp postdates the PR, is new information — thank you for digging it out.

Title

The current title is wrong in two ways: it says "missing path", which you have shown is not the condition, and it names only whisper-cli. I have retitled the issue to:

whisper-cli / parakeet-cli: any non-ASCII -m path aborts with 0xC0000409 on MSVC Windows builds

so that anyone arriving here starts from the corrected scope rather than from my original framing. Happy to change it again if a maintainer prefers something else.

What I did not determine

• I did not test with the system ACP set to UTF-8 (the "Beta: Use Unicode UTF-8" option), where argv would already be valid UTF-8.
• I did not attach a debugger; the exception path is your analysis, not my measurement. My measurements only show which inputs crash.