Environment: Anki 26.9.2, Windows x64, MSI install upgraded in place over an earlier 26.x.
Summary: After upgrading, Anki won’t start. The traceback ends in:
AttributeError: module 'charset_normalizer.md' has no attribute 'CharInfo'
It’s raised while requests is imported from aqt/__init__.py, so the app dies before Qt is initialized.
Fix
An old compiled module is shadowing the correct one. Deleting it resolves the crash — no reinstall or data changes needed. C:\Program Files requires an admin terminal (Win+X, then A):
Remove-Item -Force "C:\Program Files\Anki\app_packages\charset_normalizer\cd.cp313-win_amd64.pyd"
Then start Anki normally.
Alternative if you’d rather not use a terminal: uninstall, delete C:\Program Files\Anki, reinstall.
Note: delete only that one file. Everything else in the folder is correct.
Why it happens
Files from the previous version were left behind in app_packages during the upgrade, and Python prefers a compiled extension over bytecode. So the old cd.cp313-win_amd64.pyd was loaded instead of the cd.pyc that 26.9.2 ships.
26.9.2 bundles charset-normalizer 3.4.2, which defines no CharInfo anywhere. The leftover compiled cd expects that name to exist in md, so importing it fails immediately.
Evidence
On my install, app_packages contains several generations side by side: charset_normalizer 3.4.2 / 3.4.9 / 3.5.1, and aqt/anki 26.8.1 / 26.9 / 26.9.2. The stale cd.pyd is dated 2026-09-14, while everything 26.9.2 wrote is 2026-09-15.
Verified: with the file present the traceback reproduces exactly; after removing only that file, charset_normalizer (3.4.2) and requests both import cleanly.
Root cause
Two changes collided.
qt/tools/build_installer.py only gained dependency pinning (uv export --frozen passed as --constraints) in 26.09.1. Earlier releases resolved dependencies freshly at build time, so the installers shipped different versions:
| Anki | charset-normalizer in payload |
|---|---|
| 26.8.1 | 3.4.9 |
| 26.9 | 3.5.1 |
| 26.9.1 | 3.4.2 (first pinned release) |
| 26.9.2 | 3.4.2 |
uv.lock pins 3.4.2 in every tag back to 25.06b4, so 26.9.2 was a downgrade from 26.9’s 3.5.1.
3.4.9 and 3.5.1 ship a compiled cd extension and define CharInfo in md. 3.4.2 ships cd as pure Python and defines no CharInfo at all.
The installer then didn’t remove 26.9’s files, so 3.5.1’s compiled cd.pyd remained next to 3.4.2’s cd.pyc — and Python prefers the compiled extension. So 3.5.1’s cd loaded against 3.4.2’s md.
A fresh 26.9.2 install is fine, which is why this only hits people who upgraded in place from 26.8.x/26.9.
How the per-version mapping was determined: dist-info directory creation times (actual install time) line up to the second with each upgrade’s aqt/anki dist-infos — 8/6 = 26.8.1+3.4.9, 9/15 = 26.9+3.5.1, 9/16 = 26.9.2+3.4.2. File mtimes inside app_packages are the CI build machine’s, preserved through the MSI, which is also why the traceback shows D:\a\anki.
Fix options: remove the stale file on upgrade, or force app_packages to be replaced rather than written over.
