Could you please tell me why matplotlib plotting crashes (exit code 0xC06D007F) in conda envs with parcels v4 on Windows.

[angchhh]

Question

Question

On Windows, any matplotlib plotting in the conda environments where I installed Parcels (both v4 and v3) terminates the Python process with exit code -1066598273 (0xC06D007F), with no Python traceback. The same kind of plotting script works normally in my other conda environments.I’ve tried several things but still can’t figure out what’s wrong.

Supporting code/error messages

# Paste your code within this block

import matplotlib.pyplot as plt
plt.plot([1,2,3])
plt.savefig('test.png')
print("ok")

# Paste your error message within this block

-1066598273 (0xC06D007F)

[erikvansebille]

Dear @angchhh, thanks for reaching out - but I don't think that this is a Parcels issue. You didn't import parcels in your example, so this error is probably related more to Matplotlib itself. I don't think we can help...

[angchhh]

thanks for your help

[Maksum867]

The exit code is the useful part here, and it rules out both "a Parcels bug" and "a matplotlib bug" before anyone opens a debugger.

-1066598273 is the signed view of 0xC06D007F, and 0xC06D007F is Windows' delay-load / loader failure ERROR_PROC_NOT_FOUND. Its sibling is 0xC06D007E = ERROR_MOD_NOT_FOUND. The distinction matters:

• 0xC06D007E → a required DLL is not on the search path.
• 0xC06D007F → the DLL was found, but it does not export a symbol that something in the process was linked against.

A process that dies this way is terminated by the Windows loader, not by Python — which is exactly why you get a bare exit code and no traceback, and why faulthandler prints nothing. So the fault is neither Parcels nor matplotlib: it's two incompatible copies of the same native library resolving inside one process. A version mismatch, not a missing file.

Why a Parcels environment in particular

Activating a conda env puts %CONDA_PREFIX%\Library\bin near the front of PATH, and that directory holds conda-forge's netCDF, hdf5, mkl, zlib, libcurl, libpng, freetype, libxml2 DLLs. Meanwhile the PyPI wheels that pip install drops in — numpy (numpy.libs), scipy (scipy.libs), matplotlib, pillow, h5py — each ship their own copies of several of those same DLLs and use delay-loading for the BLAS stack. If the env was assembled with a mix of conda install and pip install (or one of them was upgraded in place later), you end up with hdf5-2.x.dll on PATH and an extension module built against hdf5-1.x.dll — or the reverse. The symbol is missing, the loader aborts, and no Python-level exception is ever raised.

import parcels is enough to get the conda-forge DLLs loaded; matplotlib.pyplot on a Windows backend (Tk/Qt) then pulls in the rest. parcels is therefore the trigger, not the cause — which is, in fairness, what the maintainer said, but the consequence isn't "nothing to fix", it's "the environment is inconsistent and can be repaired".

Narrowing it down in a few commands

First, name the offending module instead of guessing. Windows Event Viewer does it for you:

Event Viewer → Windows Logs → Application → the Application Error entry → Faulting module name.

Then:

python -m pip check
conda list --show-channel-urls | findstr /I "mkl hdf5 netcdf zlib libpng freetype libxml2 libcurl"
where.exe hdf5.dll netcdf.dll mkl_rt.dll zlib.dll

If several different directories come back from where.exe, you have the classic duplicate-DLL situation. To see what the process actually loaded and from where:

python -c "import psutil; [print(m.path) for m in psutil.Process().memory_maps()]"

The reliable tool, though, is Process Monitor (Sysinternals): filter Process Name is python.exe, Operation is Load Image, and look at Result is NAME NOT FOUND / PATH NOT FOUND. The last Load Image before the crash is your culprit, and the NAME NOT FOUND lines show which paths were probed.

Then bisect the environment — that's the part that actually resolves it:

conda create -n mplonly -c conda-forge python=3.12 matplotlib=3.10
conda activate mplonly
python -c "import matplotlib.pyplot as plt; plt.plot([1,2]); plt.savefig('t.png'); print('ok')"

• Crashes here too → the conda-forge matplotlib stack is broken for this channel/OS combination (on Windows this is usually an mkl / libblas mix). Pin the stack — conda install -c conda-forge "mkl<2025" or switch to libblas=*=*openblas — and report it to conda-forge/matplotlib-feedstock with conda list --explicit.
• Works here → add Parcels' own dependencies one at a time (netcdf4, xarray, cftime, scipy) until it breaks; the step that breaks it names the library pair.

Two extra checks that cost nothing:

• MPLBACKEND=Agg python script.py — if this survives where the default backend didn't, the conflict is in the GUI toolkit DLLs (Tk/Qt), not in the numerics.
• Never pip install into a conda env that already provides the same package. Build the env from one source only: either conda env create -f environment.yml, or a clean venv + pip install -r requirements.txt. conda doctor (conda ≥ 24.4) catches missing or corrupted files in the prefix, though not version skew.

On the package side

Two things would genuinely help, and neither is "blame the user's env":

1. The parcels recipe and the recommended environment.yml are the natural place to prevent this. If the recipe leaves matplotlib unpinned while pulling pinned netcdf4/hdf5 from conda-forge, a later conda update can move one side of the ABI. A stricter pin — or dropping matplotlib from the recipe and listing it as an optional extra — removes a whole class of these reports.
2. A short troubleshooting note in the docs — "on Windows, exit code 0xC06D007F / -1066598273 means a duplicate DLL, not a Parcels failure; here's how to confirm" — sends future reporters to the fix instead of to the issue tracker.

@erikvansebille's reading of the symptom was right, but "you're not importing parcels" describes when it happens, not what it is. If someone can paste conda list --explicit and the Faulting module name from Event Viewer, this becomes a two-line diagnosis.