Windows: mise upgrade aborts in aws-lc jent_entropy_switch_notime_impl starting with v2026.8.9

[ramhaidar]

Summary

mise upgrade crashes on Windows with a non-unwinding panic inside AWS-LC.

I tested multiple mise releases and found a clear regression boundary:

• 2026.8.8 - works
• 2026.8.9 - crashes
• 2026.8.16 - crashes

The crash happens during mise upgrade. Since I normally run:

mise upgrade && mise prune --yes --silent

mise prune is never reached because mise upgrade aborts first.

Reproduction

On 2026.8.9:

PS C:\Users\FishyPasta> mise --version
2026.8.9 windows-x64 (2026-08-19)

PS C:\Users\FishyPasta> mise upgrade

Result:

=== Async Backtrace (panic occurred in tokio runtime) ===
[no accessible async backtrace]
------- TASK DUMP TREE -------

=== End Async Backtrace ===

The application panicked (crashed).
Message:  panic in a function that cannot unwind
Location: /rustc/8bab26f4f68e0e26f0bb7960be334d5b520ea452/library\core\src\panicking.rs:225

thread caused non-unwinding panic. aborting.

With:

$env:RUST_BACKTRACE=1
mise upgrade

I get:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 1: aws_lc_0_44_0_jent_entropy_switch_notime_impl<unknown>
    at <unknown source file>:<unknown line>
 2: aws_lc_0_44_0_jent_entropy_switch_notime_impl<unknown>
    at <unknown source file>:<unknown line>
 3: aws_lc_0_44_0_jent_entropy_switch_notime_impl<unknown>
    at <unknown source file>:<unknown line>
 4: aws_lc_0_44_0_jent_entropy_switch_notime_impl<unknown>
    at <unknown source file>:<unknown line>
 5: _CxxFrameHandler3<unknown>
    at <unknown source file>:<unknown line>
 6: is_exception_typeof<unknown>
    at <unknown source file>:<unknown line>
 7: _C_specific_handler<unknown>
    at <unknown source file>:<unknown line>
 8: is_exception_typeof<unknown>
    at <unknown source file>:<unknown line>
 9: _CxxFrameHandler3<unknown>
    at <unknown source file>:<unknown line>
10: _chkstk<unknown>
    at <unknown source file>:<unknown line>
11: RtlUnwindEx<unknown>
    at <unknown source file>:<unknown line>
12: RtlUnwind<unknown>
    at <unknown source file>:<unknown line>
13: _report_gsfailure<unknown>
    at <unknown source file>:<unknown line>
14: aws_lc_0_44_0_jent_entropy_switch_notime_impl<unknown>
    at <unknown source file>:<unknown line>
15: BaseThreadInitThunk<unknown>
    at <unknown source file>:<unknown line>
16: RtlUserThreadStart<unknown>
    at <unknown source file>:<unknown line>

thread caused non-unwinding panic. aborting.

The same aws_lc_0_44_0_jent_entropy_switch_notime_impl crash also occurs with 2026.8.16.

Expected behavior

mise upgrade should complete normally, as it does with 2026.8.8.

For example, after downgrading to 2026.8.8:

mise WARN  newer uv release 0.12.8 (...) ignored by minimum_release_age (24h)
mise WARN  newer aube release 2.2.4 (...) ignored by minimum_release_age (24h)
mise All tools are up to date
mise Newer versions are available outside the configured version ranges. Use `mise upgrade --bump` to upgrade them.

No panic occurs.

Regression

The first failing release I found is 2026.8.9.

v2026.8.8

2026.8.8 windows-x64

mise upgrade works normally.

v2026.8.9

version: 2026.8.9 windows-x64 (2026-08-19)

build_info:
  Target: x86_64-pc-windows-msvc
  Features: rustls-native-roots, self_update
  Built: Wed, 19 Aug 2026 18:07:53 +0000
  Rust Version: rustc 1.97.1 (8bab26f4f 2026-07-14)
  Profile: release

shell:
  pwsh
  PowerShell 7.6.5

mise upgrade crashes.

v2026.8.16

version: 2026.8.16 windows-x64 (2026-08-31)

build_info:
  Target: x86_64-pc-windows-msvc
  Features: rustls-native-roots, self_update
  Built: Mon, 31 Aug 2026 13:57:39 +0000
  Rust Version: rustc 1.98.0 (88d9e12ae 2026-08-18)
  Profile: release

shell:
  pwsh
  PowerShell 7.6.5

The same crash occurs.

Since 2026.8.9 already crashes while using Rust 1.97.1, this does not appear to require the Rust 1.98.0 build used by 2026.8.16.

Possible related change

I noticed that #12139 was merged between 2026.8.8 and 2026.8.9:

#12139

It updated several AWS SDK / Smithy dependencies.

I am not claiming this PR is the cause, but it seems potentially relevant because:

• 2026.8.8 works
• 2026.8.9 is the first version where I can reproduce the crash
• the backtrace is inside AWS-LC
• the AWS SDK / Smithy stack changed in that release window

Interestingly, aws-lc-rs / aws-lc-sys themselves appear to remain on the same versions, so it may instead be a change in how the updated AWS stack reaches or initializes AWS-LC.

mise doctor

mise doctor output from v2026.8.9

version: 2026.8.9 windows-x64 (2026-08-19)
shims_on_path: yes
self_update_available: yes

build_info:
  Target: x86_64-pc-windows-msvc
  Features: rustls-native-roots, self_update
  Built: Wed, 19 Aug 2026 18:07:53 +0000
  Rust Version: rustc 1.97.1 (8bab26f4f 2026-07-14)
  Profile: release

shell:
  pwsh
  PowerShell 7.6.5

aqua:
  baked in registry: aquaproj/aqua-registry@9b7652faaca0903a3110bfc111d8227d703f89b8
  baked in registry tools: 2277

dirs:
  cache: D:\Mise\cache
  config: D:\Mise\config
  data: D:\Mise
  shims: D:\Mise\shims
  state: D:\Mise\state

config_files:
  D:\Mise\config\config.toml

env_files:
  (none)

ignored_config_files: (none)

backends:
  aqua
  asdf
  cargo
  conda
  core
  dotnet
  forgejo
  gem
  github
  gitlab
  go
  npm
  pipx
  pkgx
  spm
  http
  s3
  ubi
  vfox

plugins:
  php  https://github.com/verzly/mise-php#1325cdf

toolset:
  aqua:astral-sh/uv@0.12.7
  aqua:gradle/gradle@8.9.0
  aqua:jdx/aube@2.2.0
  aqua:pnpm/pnpm@11.25.0
  core:bun@1.4.0
  core:dotnet@10.0.400
  core:go@1.27.0
  core:java@temurin-21.0.12+8.0.LTS
  core:node@24.20.0
  core:rust@1.98.0
  github:anomalyco/opencode@1.18.25
  github:can1357/oh-my-pi@18.0.11
  github:google-antigravity/antigravity-cli@1.1.22
  github:niXman/mingw-builds-binaries@16.2.0-rt_v14-rev1
  vfox:php@8.5.10

settings:
  npm.package_manager  "pnpm" D:\Mise\config\config.toml

1 warning found:

1. new mise version 2026.8.16 available, currently on 2026.8.9

No problems found

I can provide additional diagnostics or test specific commits/builds if that would help narrow down the regression.

[BurtHarris]

Confirming this crash also reproduces outside of mise upgrade — same signature hits during mise install whenever a backend shells out to an external installer process (in my case, the community winget backend). So the trigger looks like "any operation that spawns a subprocess / does network+TLS work" on Windows, not something specific to upgrade.

Environment

version: 2026.9.1 windows-x64 (2026-09-02)
build_info:
  Target: x86_64-pc-windows-msvc
  Features: rustls-native-roots, self_update
  Built: Wed, 2 Sep 2026 12:45:05 +0000
  Rust Version: rustc 1.98.0 (88d9e12ae 2026-08-18)
  Profile: release
shell:
  pwsh
  PowerShell 7.6.5
winget --version: v1.30.130-preview

Reproduction

mkdir C:\temp\mise-repro; cd C:\temp\mise-repro
mise plugin install winget https://github.com/Yuzu02/mise-winget
@'
[tools]
"winget:Microsoft.PowerShell" = "latest"
'@ | Set-Content mise.toml
$env:RUST_BACKTRACE = "full"
mise install

Output

mise winget:Microsoft.PowerShell@7.6.5.0 [1/3] install
mise [winget] [winget] Installing Microsoft.PowerShell@7.6.5.0
=== Async Backtrace (panic occurred in tokio runtime) ===
[no accessible async backtrace]
------- TASK DUMP TREE -------
╼ mise::cli::install::Install::run::{{closure}} at src\cli\install.rs:135:5
  └╼ mise::toolset::toolset_install::<impl mise::toolset::Toolset>::install_all_versions::{{closure}} at src\toolset\toolset_install.rs:249:5
=== End Async Backtrace ===

The application panicked (crashed).
Message:  panic in a function that cannot unwind
Location: /rustc/88d9e12ae178fab0fb5cc050a94da85685d449ea/library\core\src\panicking.rs:225

  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   1: aws_lc_0_44_0_jent_entropy_switch_notime_impl<unknown>
   2: aws_lc_0_44_0_jent_entropy_switch_notime_impl<unknown>
   3: aws_lc_0_44_0_jent_entropy_switch_notime_impl<unknown>
   4: _CxxFrameHandler3<unknown>
   5: is_exception_typeof<unknown>
   6: _C_specific_handler<unknown>
   7: is_exception_typeof<unknown>
   8: _CxxFrameHandler3<unknown>
   9: _chkstk<unknown>
  10: RtlUnwindEx<unknown>
  11: RtlUnwind<unknown>
  12: _report_gsfailure<unknown>
  13: BaseThreadInitThunk<unknown>
  14: RtlUserThreadStart<unknown>

thread caused non-unwinding panic. aborting.

Identical aws_lc_0_44_0_jent_entropy_switch_notime_impl non-unwinding-panic signature as the original report, just triggered via mise install + a plugin backend instead of mise upgrade. Still crashing on 2026.9.1, so the regression is still present well past 2026.8.16.

mise doctor (trimmed)

version: 2026.9.1 windows-x64 (2026-09-02)
backends: aqua, asdf, cargo, conda, core, dotnet, forgejo, gem, github, gitlab, go, npm, pipx, pkgx, spm, http, s3, ubi, vfox
plugins:
  winget  https://github.com/Yuzu02/mise-winget#f342b1d
toolset:
  aqua:astral-sh/uv@0.12.9
  core:node@24.20.0
  core:python@3.12.14
No problems found

Happy to test specific builds/commits if that helps bisect further, since install is a much easier repro path than upgrade (no need to wait for an actual new release to test against).

[Its-Just-Nans]

Another report: zip-rs/zip2#965

I'm not on windows so I cannot reproduce

Maybe a git bisect would be useful for that bug

[Siradankullanici]

Wow that's why my project broken. I get similar issue but more more complex one.
owlyshield_ransom!aws_lc_0_44_0_jent_entropy_switch_notime_impl+0x20bd0 this my one (Owlyshield is anti ransom project but contains almost everything so it's bloatware).
When I testing my mitm proxy it get broken after cargo.lock changed(?)
I also using Rust 1.97.1
Does I need upgrade Rust version?

Sorry if this unrelated.

[Siradankullanici]

owlyshield_ransom!aws_lc_0_45_0_jent_read_entropy still same

[ramhaidar]

@Siradankullanici try downgrading to 2026.8.8 version of mise

[Siradankullanici]

I did but I realized my problem is different because other sdk files causing that.
Sorry for confusion.

[drawliin]

this is bigger than mise.. same exact crash signature (jent_entropy_switch_notime_impl, non-unwinding panic) shows up across totally unrelated rust projects on windows: zed-industries/zed#42524, tauri-apps/tauri#12864, and it's also been reported hitting codex cli. it's spanned multiple aws-lc-sys versions too (0.32.3 in the zed report, up through 0.44.0 here), so it's not a fresh regression in one release, it's a recurring bug in aws-lc-sys's jitterentropy subsystem on windows specifically.

jitterentropy is aws-lc's supplementary entropy source, it runs a self-test/calibration routine that this crash happens inside of. the "non-unwinding panic" part is because that C code hits some abort/failure path that crosses the ffi boundary in a way rust's unwinder can't handle on windows (aws-lc uses SEH internally, rust panic=abort doesn't play nice with it there), so instead of a normal error you get a hard process abort.

there's actually a real build-time escape hatch already: AWS_LC_SYS_NO_JITTER_ENTROPY=1 disables compiling the jitterentropy code entirely (mentioned in aws/aws-lc-rs#1146, different symptom there but same subsystem). it wouldn't meaningfully weaken security either.. jitter entropy is one of several sources aws-lc pulls from, windows still has a solid OS-level CSPRNG (CryptGenRandom/BCryptGenRandom) as the primary source, jitter entropy is more relevant on embedded/low-entropy systems than a normal windows desktop.

so two separate things worth doing:

• immediate workaround: pin back to 2026.8.8 like you already found, since that's confirmed still working
• for a real fix, worth mise maintainers considering AWS_LC_SYS_NO_JITTER_ENTROPY=1 when building release binaries, since this is clearly not a one-off and won't fix itself upstream anytime soon given how long it's been showing up across different projects

[ramhaidar]

Well, it is what it is i guess

[ramhaidar]

Tested on latest v2026.9.12 still same behaviour ran mise upgrade && mise prune --yes --silent

mise 2026.9.12 by @jdx  ██████░░░░░░░░░░░░░░░░░░  4/15 · 250ms
 github:aubepkg/aube@2.2.17                             resolving                                                                              250ms ◝
=== Async Backtrace (panic occurred in tokio runtime) ===
[no accessible async backtrace]
------- TASK DUMP TREE -------

=== End Async Backtrace ===

The application panicked (crashed).
Message:  panic in a function that cannot unwind
Location: /rustc/48a229ceaefd4985c50990b14116b6d856af0985/library\core\src\panicking.rs:225

  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   1: aws_lc_0_45_0_jent_entropy_switch_notime_impl<unknown>
      at <unknown source file>:<unknown line>
   2: aws_lc_0_45_0_jent_entropy_switch_notime_impl<unknown>
      at <unknown source file>:<unknown line>
   3: aws_lc_0_45_0_jent_entropy_switch_notime_impl<unknown>
      at <unknown source file>:<unknown line>
   4: aws_lc_0_45_0_jent_entropy_switch_notime_impl<unknown>
      at <unknown source file>:<unknown line>
   5: _CxxFrameHandler3<unknown>
      at <unknown source file>:<unknown line>
   6: is_exception_typeof<unknown>
      at <unknown source file>:<unknown line>
   7: _C_specific_handler<unknown>
      at <unknown source file>:<unknown line>
   8: is_exception_typeof<unknown>
      at <unknown source file>:<unknown line>
   9: _CxxFrameHandler3<unknown>
      at <unknown source file>:<unknown line>
  10: _chkstk<unknown>
      at <unknown source file>:<unknown line>
  11: RtlUnwindEx<unknown>
      at <unknown source file>:<unknown line>
  12: RtlUnwind<unknown>
      at <unknown source file>:<unknown line>
  13: _report_gsfailure<unknown>
      at <unknown source file>:<unknown line>
  14: aws_lc_0_45_0_jent_entropy_switch_notime_impl<unknown>
      at <unknown source file>:<unknown line>
  15: BaseThreadInitThunk<unknown>
      at <unknown source file>:<unknown line>
  16: RtlUserThreadStart<unknown>
      at <unknown source file>:<unknown line>

Run with COLORBT_SHOW_HIDDEN=1 environment variable to disable frame filtering.
thread caused non-unwinding panic. aborting.

[philippe-granet]

Same problem on latest v2026.9.12, even with MISE_JOB=1

[philippe-granet]

Hi @jdx,

Would you mind taking a look at this regression when you have a chance?

This issue is unfortunately blocking for us, as it currently prevents us from using mise as expected in our environment. We’ve tried to investigate it on our side, but we haven’t been able to find a suitable workaround.

I really appreciate the work you’re putting into mise, and I know maintaining such a large project is a significant effort. If you could take a look at this regression, it would be greatly appreciated.

Thank you very much for your time and for maintaining mise! 🙏

[jdx]

This should be fixed by #13503, which was merged after 2026.9.12 was released. It will ship in the next release, 2026.9.13.

Cause: in 2026.8.9, #12146 switched the Windows release build to a profile that uses panic = "abort". When a vfox plugin calls a Rust-backed Lua function that returns an error, Lua uses longjmp to report it. On Windows (MSVC), longjmp is implemented as an SEH unwind (RtlUnwindEx), and with panic=abort that unwind aborts the process as soon as it crosses a Rust frame. That produces panic in a function that cannot unwind. All of the reports here involve a vfox plugin (vfox:php, winget).

The aws_lc_…_jent_entropy_switch_notime_impl frames are misleading. The release binary ships without debug symbols, so each address resolves to the nearest exported symbol. AWS-LC and jitter entropy aren't involved, so AWS_LC_SYS_NO_JITTER_ENTROPY wouldn't help.

Fix: Windows release builds now use panic=unwind. Linux and macOS are unaffected. Release builds also run a smoke test on the packaged Windows binary that exercises this Lua error path.

Until 2026.9.13 is out, stay on 2026.8.8 as a workaround. Please report back here if you still see the crash after upgrading.

AI-assisted — Tool: Claude Code; model: anthropic/claude-opus-5-5; version: unavailable.

[ramhaidar]

Oqie, waiting for v2026.9.13

[philippe-granet]

I confirm that the problem is fixed in v2026.9.13, thanks !

[ramhaidar]

Tested v2026.9.13 no more error, thanks