dotnet/runtime · error · Exception
Could not determine JIT-EE version
Error message
Could not determine JIT-EE version
What it means
Raised by superpmi_diffs_setup.py build_partitions() at src/coreclr/scripts/superpmi_diffs_setup.py:232 when `mcs -printJITEEVersion` returns a non-zero exit code. mcs (method context sorter) is expected to print the JIT-EE version string used to locate the matching baseline collection in Azure blob storage.
Solutions
- Confirm mcs exists at bin_path (and the osx.x64.Checked override path on macOS).
- Rebuild coreclr Checked for the target OS/arch so mcs is fresh.
- Run `mcs -printJITEEVersion` manually to see the real failure (missing .so/.dll, segfault).
- Ensure bin_path matches the build output layout.
Defensive patterns
Strategy: try-catch
Validate before calling
import os, subprocess
mcs_path = os.path.join(bin_path, 'mcs.exe' if is_windows else 'mcs')
if not os.path.isfile(mcs_path):
raise SystemExit(f'mcs not found at {mcs_path} — build coreclr Checked first')
rc = subprocess.run([mcs_path, '-printJITEEVersion']).returncode
if rc != 0:
raise SystemExit(f'mcs -printJITEEVersion exited {rc} — inspect the binary') Try / catch
try:
jit_ee_version = subprocess.check_output([mcs_path, '-printJITEEVersion'], text=True).strip().lower()
except subprocess.CalledProcessError:
raise RuntimeError('Could not determine JIT-EE version') Prevention
- Run `mcs -printJITEEVersion` manually on the agent before relying on build_partitions().
- Confirm mcs is built for the host OS/arch.
When it happens
Trigger: The mcs binary is missing/corrupt, fails to run on the host, or returns non-zero from -printJITEEVersion; bin_path points to the wrong directory.
Common situations: CoreCLR Checked build not produced for the target; wrong bin_path; running an mcs built for a different OS/arch; missing shared libraries required by mcs.
Related errors
- Cannot find System.Private.CoreLib.dll at
- Collection 'smoke_tests' is only available for 'nativeaot'…
- {coreclr_args.mode}
- Invalid arch.
- Pass only one tiering option.
AI-assisted analysis of dotnet/runtime@60108ba66e (2026-08-10).
Data as JSON: /api/errors/4259c911243a558f.
Report an issue: GitHub.
Appendix: source
Thrown at src/coreclr/scripts/superpmi_diffs_setup.py:232
return 1
def build_partitions(partitions_dir, do_asmdiffs, bin_path, host_bitness):
mcs_path = os.path.join(bin_path, "mcs.exe" if is_windows else "mcs")
if is_macos:
# Hack: the target is arm64, but the build machine is x64. We build SPMI for x64 because of that,
# but it exists at a different path.
mcs_path = os.path.join(bin_path, "..", "osx.x64.Checked", "mcs")
assert(os.path.exists(mcs_path))
command = [mcs_path, "-printJITEEVersion"]
proc = subprocess.Popen(command, stdout=subprocess.PIPE)
stdout_jit_ee_version, _ = proc.communicate()
return_code = proc.returncode
if return_code == 0:
jit_ee_version = stdout_jit_ee_version.decode('utf-8').strip()
jit_ee_version = jit_ee_version.lower()
else:
raise Exception("Could not determine JIT-EE version")
print("JIT-EE version determined to be {}".format(jit_ee_version))
az_account_name = "clrjit2"
az_superpmi_container_name = "superpmi"
az_blob_storage_account_uri = "https://" + az_account_name + ".blob.core.windows.net/"
az_blob_storage_superpmi_container_uri = az_blob_storage_account_uri + az_superpmi_container_name
az_collections_root_folder = "collections"
prefix = az_collections_root_folder + "/" + jit_ee_version
prefix_urlencoded = urllib.parse.quote(prefix)
list_superpmi_container_uri = az_blob_storage_superpmi_container_uri + "?restype=container&comp=list&prefix=" + prefix_urlencoded + "/"
try:
contents = urllib.request.urlopen(list_superpmi_container_uri).read().decode('utf-8')
except Exception as exception:
raise Exception("Didn't find any collections using %s", list_superpmi_container_uri)
elem = ET.fromstring(contents)View on GitHub (pinned to 60108ba66e)