I know this has been asked before, but that was in 12/2025. I started my new class using Anaconda and struggled for 30 minutes with a student whose Anaconda install was doing very odd things and throwing weird errors (like not being able to find conda when using conda search conda?).
Finally it dawned on me that they are likely using a Snapdragon based system, which I confirmed. They cannot create a new environment with a functioning conda.
Is there a functional installer for Anaconda on Arm64? Or sometimes a 32 bit installer will work? Or is there any other work around that will allow this student to complete my class?
There is not an installer that works natively for Windows Arm64 today. However we are currently working on this as we speak and have the first Windows ARM release of miniconda planned for Q4 2026.
Tyler, I don’t have direct access to the student’s system However, based on the link you provided, emulation isn’t something we can turn on or off, it’s something the OS does automatically.
I’m not sure if you read through the link you provided, but it discusses how API calls to the OS like GetNativeSystemInfo, and IsWoW64Process2 will return info about the emulated processor details.
I’m not sure how Anaconda determines what platform it’s running on, but is it possible that it isn’t using one of those methods, so is detecting the architecture as Arm64?
Is it possible that Anaconda has been installed and is running in x64 emulation mode, but conda is detecting the platform as Arm64, and therefore searching for the wrong versions of packages? That would explain why it can find some packages, but not conda, if there is no Arm64 version of conda available.
If this is possible, how could we check what platform conda think it is running on, and if it is Arm64, can we override that setting so it checks repo for x64 packages that will run in emulation?
conda picks its package platform from the processor it detects, and on Windows on Arm it detects Arm64 even when it’s running under x64 emulation. So it goes looking for win-arm64 packages. We do publish a limited set of those on defaults, but conda itself isn’t among them yet. That’s exactly why conda search conda came back empty while other lookups partly worked.
To confirm. Have the student run:
conda info
and check the platform line. If it reads win-arm64, that’s the problem.
To fix. Create the class environment with the --platform flag:
conda records that choice on the environment, so later conda install commands into it keep using win-64 — they only need to get this right once. It’s documented under Specifying a different target platform for an environment. The worked example there is an Apple Silicon Mac creating an Intel environment to run under Rosetta, which is the same situation.
Any environment they created before this is worth deleting and recreating rather than repairing.
I had the student run “conda info”, and verified that it said “platform : win-arm64”, confirming the issue.
I will tell her to create a new environment using the --platform win-64 argument, that’s an easy fix. This is the first lab / environment we are creating (first week is getting everything working), so there are no past environments to fix. Other than the base environment of course, I presume that’s not fixable? Or, since we haven’t installed or updated any packages in it yet, can she just switch it to win-64?
The base environment should be fine as it stands. We do not have a Windows ARM64 Installer yet, so I assume she downloaded our Win-64 installer. If thats the case, then base should already contain win-64 binaries running correctly under emulation.
Hopefully this helps your student, but if there’s any more trouble, please have her run these and paste the output here:
conda info
conda config --show-sources
conda --version
conda info is the important one — it reports the detected platform, the conda version, the install location, and the active channels in a single block. conda config --show-sources shows whether any config file is overriding the defaults, which is worth ruling out.
Four other things that help:
The exact installer filename she downloaded — something like Anaconda3-2025.06-Windows-x86_64.exe. That confirms which build she’s on rather than us assuming.
The Windows version. Have her run winver and report what the dialog says. Anything below Windows 11 24H2 is worth knowing about, since emulation of certain CPU instructions only arrived in that release, and their absence can cause crashes inside numerical libraries that look unrelated to conda.
The full error text, copied and pasted rather than summarized or screenshotted. conda errors usually name the specific package and channel that failed, and that detail is normally what identifies the problem.
Which environment was active when it failed — the name in parentheses at the start of her prompt.
That’s enough for me to tell whether it’s the same platform detection issue or something new.
Ok, thanks! Yes, it was definitely the latest x64 installer, probably Anaconda3-2026.07-1 . This is a brand new computer, so it’s almost certainly on 25H2.
I’ll have her run conda info on the base environment and verify what the platform value is. I still expect an issue, because when we ran “conda update conda” on the base, the only update it offered was openssl, which we did NOT install because I suspect that was what caused her connection errors in the first place (after which we uninstalled / reinstalled Anaconda).
while the base environment was active, this seems to have fixed base (just to have all environments be correct). Since we didn’t install or update anything additional in base after the initial install, I don’t think we need to do anything else.
New environments created with the --platform win-64 argument seem to be working fine.
Until a native Arm64 installer is out, perhaps you should modify the conda platform detection to query the emulated cpu instead of the actual cpu to prevent this issue for all users? Microsoft indicates that using GetNativeSystemInfo or IsWoW64Process2 should return the correct emulated values.
After chatting with the team, this is actually already fixed in conda 26.7.0. The bug was in platform detection under emulation — conda was resolving to win-arm64 on an emulated x86-64 install and then selecting win-arm64 packages for a win-64 base environment (conda/conda#16416). Your suggestion about querying the emulated CPU is effectively what the fix does.
The cleanest path is a fresh install from a current installer. An in-place conda install -n base conda>=26.7.0 may work, but if the base environment has already picked up mismatched packages, reinstalling is less trouble than repairing it.
Perfect, so it was just the particular version of conda that was packaged with 2026.07-1 (26.5.3 ?) and earlier that had this issue?
Of course that makes an interesting issue, since while the problem exists, conda can’t update itself, until you switch the platform from Arm64 to Win-64!
But good to know that this has been fixed going forward, thanks for the update!