Creality Scan 4.3.2 crashes during 3D calibration on pre-Haswell CPUs (BMI1 / #UD)

Software
,
1

Creality Scan 4.3.2 crashes during 3D calibration on pre-Haswell CPUs (BMI1 / #UD)

TL;DR: 4.3.2 ships native plugins compiled for Haswell+. On my Ivy Bridge-E Xeon the calibration computes fine (score 98.1) and then the app dies with STATUS_ILLEGAL_INSTRUCTION on an ANDN instruction. No error dialog, no event log entry, result is lost. 3/3 attempts.

What happens

  1. Connect CR-Scan Raptor, run Calibrate, capture all 20 poses.
  2. Progress reaches “computing calibration result”.
  3. App closes by itself ~2 s later. No error, no dialog. Next launch says “Previous application crashed”.

Wasted three full calibration runs this way.

Why

  • Exception: 0xC000001D = STATUS_ILLEGAL_INSTRUCTION (#UD)
  • Module: line_laser_param_preprocessing.dll at RVA 0x11348
  • Instruction: andn ecx, r10d, ebx

ANDN is BMI1, introduced with Haswell (2013). My CPU doesn’t have BMI1, so the opcode is invalid and the process is killed. The DLL has 28 ANDN instructions, all in the same TEA-style block decryption routine.

The calibration itself succeeds — the native log shows score 98.14, rms fine — then dies in the [Line Trans] stage right after refresh_linelaser_params(). So the scanner, board and algorithm are all fine.

My CPU

Intel Xeon E3-1230 V2 (Ivy Bridge-E, 2012)
CPUID leaf 7.0 EBX = 0x00000281
  BMI1 : NO   <-- ANDN undefined here -> #UD
  AVX2 : NO
  BMI2 : YES

Fully meets the Windows 11 x86-64 baseline. Just older than 2013.

It’s not only this plugin

Audited every 64-bit plugin in Plugins\x86_64:

Plugin BMI1
line_laser_param_preprocessing.dll 28 ← crash
soc_linelaser_param_processing.dll 28 ← same routine, crashes next
soc_depth_engine.dll 30
mx6600_depth_engine.dll 32

So patching just the crashing DLL won’t help — the next one has the byte-identical function.

What would fix it

Rebuild the native plugins for baseline x86-64:

MSVC  : /arch:SSE2   (or drop /arch)
clang : -march=x86-64 -mtune=generic   (no -mbmi/-mavx2/-march=native)

…or runtime CPUID check for BMI1 with a scalar fallback.

Also: the calibration result is thrown away silently. Persisting it (or at least showing an error) before the line-laser step would save users a lot of grief.

Ruled out

RAM (1.5/24 GB), disk (191 GB free), GPU, USB/cable, firmware (1.5.7 current), bad poses, antivirus. Same exception, same module, same RVA, 3 out of 3. No Application Error in Event Log — Crashpad eats the exception before Windows sees it.

Question

Anyone else on a pre-2013 CPU hitting this? And does anyone know if Creality is aware / planning a rebuild for baseline x86-64? Rolling back to an older version seems like the only workaround right now — happy to hear if someone found another one.

Build hashes and minidumps available if a dev wants them.