Summary
With Zen UV 5.3.3 enabled, Blender 5.2.0 LTS terminates silently part-way through loading one
particular .blend. There is no Python traceback, no .crash.txt, and no Windows Application
event — the process simply exits.
The failure is specific to the file-load path. The same scene loads fine with Zen UV disabled,
and — the key data point — enabling Zen UV on that scene once it is already open works
perfectly (254 classes register, Zen UV Library: REGISTERED, panels and operators all present).
Environment
| Blender | 5.2.0 LTS, build hash fbe6228777e7 |
| OS | Windows 11 Pro 10.0.26200 |
| GPU | NVIDIA GeForce RTX 5070 Ti, driver 32.0.16.1074 |
| Zen UV | 5.3.3, installed as an extension from superhivemarket.com (blender_version_min = "4.2.0") |
| Zen UV Core Library | zen_uv_lib_win_64_v2_0_0.dll installed; loads cleanly (Zen UV Library: REGISTERED) |
| Zen BBQ | 2.0.1 — enabled throughout, and not implicated |
| Other add-ons | 26 enabled (RBC Pro, Auto-Rig Pro, KeenTools, RetopoFlow, UVPackmaster 3.4.4, NijiGPen, Abnormal, BlenderKit, …) |
Steps to reproduce
- Enable Zen UV 5.3.3.
File ▸ Openthe scene described below (orbpy.ops.wm.open_mainfile(filepath=...)).- Blender exits during the load.
Isolation performed
Every row below was run in a live GUI session with all 26 add-ons enabled except where stated.
Nothing else was changed between rows.
| Test | Result |
|---|---|
| Scene + all add-ons, Zen UV and Zen BBQ disabled |  loads — 165 objects |
| ↳ then Zen BBQ re-enabled (2.0.1, 41 classes), reload | loads — Zen BBQ is not involved |
| ↳ then Zen UV re-enabled (5.3.3, 254 classes), reload |  process dies mid-load |
| Zen UV enabled while the scene is ALREADY open | survives — full registration, no issue |
Scene loaded headless (blender -b --factory-startup) |
loads |
| Scene loaded headless with all add-ons incl. Zen UV | loads — does not reproduce |
Zen UV enabled, Core Library removed (both utils/clib/ and the %TEMP% cache) |
still crashes — library not implicated |
Why it never reproduces headlessly
ZenUV/ui/gizmo_draw.py:238
def init_depsgraph():
if zenuv_depsgraph_ui_update not in bpy.app.handlers.depsgraph_update_post and not bpy.app.background:
bpy.app.handlers.depsgraph_update_post.append(zenuv_depsgraph_ui_update)
The and not bpy.app.background guard means this handler is never installed in background
mode, which is exactly why the scene loads without complaint under blender -b and only fails
in the GUI. Worth knowing if this is being chased with headless tests.
Suspected mechanism (partial — offered as a lead, not a conclusion)
zenuv_depsgraph_ui_update (gizmo_draw.py:261) ends by scheduling a timer:
if bpy.app.timers.is_registered(zenuv_despgraph_delayed):
bpy.app.timers.unregister(zenuv_despgraph_delayed)
bpy.app.timers.register(zenuv_despgraph_delayed, first_interval=0.1)
and zenuv_despgraph_delayed (gizmo_draw.py:247) then calls update_areas_in_uv(ctx).
A 0.1 s timer scheduled from a depsgraph update, firing across a file-load boundary, looks
like a candidate for touching mesh data that has since been freed — which would match the silent
process exit with no Python-level error.
One hypothesis was tested and did not hold. The guard in zenuv_despgraph_delayed is:
if ((p_scene.zen_uv.ui.draw_mode_UV in {'UV_OBJECT', 'OBJECT_SEAMS'}) or
('DATA_PT_UVL_uv_texture_advanced' in get_prefs().combo_panel.combo_UV_edit_mode)):
update_areas_in_uv(ctx)
combo_UV_edit_mode did contain 'DATA_PT_UVL_uv_texture_advanced' (while draw_mode_UV and
draw_mode_3D were both 'NONE'). Clearing that entry and reloading still crashed. So either
there is another route into update_areas_in_uv, or the fault lies elsewhere — the other
load-time handler, zenuv_tool_load_scene_handler (ui/tool/__init__.py:301, registered on
load_post at line 390), has not been ruled out.
Scene characteristics
Offered because the trigger is likely a property of the data.
| Objects | 165 — 114 MESH, 38 EMPTY, 8 LIGHT, 2 CAMERA, 1 ARMATURE, 1 CURVE, 1 GREASEPENCIL |
| Geometry | 1,548,428 verts / 1,306,308 polys |
| UV maps per mesh | 33 meshes with ZERO UV maps, 79 with 1, 1 with 2, 1 with 3 |
| Largest meshes | ENV_SNOW_GROUND 363,350 v (1 UV) · VW_BODY 175,709 v (3 UV maps) · VW_BODY.HULL 175,709 v (2 UV) · ENV_SNOW_TRACK 128,310 v (0 UV) |
| Linked objects | none |
| Libraries | 3 linked node/asset libraries;  two point at a Blender 5.0 datafiles path that no longer exists (F:\Blender_5.0\5.0\datafiles\assets\nodes\geometry_nodes_essentials.blend) |
| Mode at save | OBJECT |
Two things worth pointing at first:
- 33 meshes carry no UV map at all. If any load-time pass assumes
uv_layers[0]or an active
UV layer exists, this scene will find it. - There is one Grease Pencil object (
VW_LINEART_GP). This may be relevant history: the
previously installed Zen UV 5.0.3 failed to register on Blender 5.2 entirely, because
ZenUV/utils/annotations_toolbox/math_visualizer.py:40annotatesbpy.types.GPencilFrame,
which was removed in Blender 4.3 (it isGreasePencilFramenow). Given that history, any
remaining Grease Pencil handling in 5.3.3 seems worth a look.
Core Library — tested and ruled out (with a caveat worth knowing)
Prompted by the existing thread
Installing Zen Library for ZenUV Crashes Blender
(Linux, Blender 4.4.3 / 5.0.0 — Zen Library v1.0.0 fails to register, v2.0.0 crashes Blender),
the Core Library was A/B’d out of the load path here. This machine has
zen_uv_lib_win_64_v2_0_0.dll.
Result: the crash still occurs with the Core Library completely absent. So the two issues
appear to be unrelated, and the library is not implicated in this one.
the first attempt at this A/B was a false negative, because Zen UV silently re-installed the
library from a cache in%TEMP%—clib/lib_init.py:72:def create_zenlib(): if not is_zenlib_present(): s_temp_lib = get_zenlib_temp_path() # %TEMP%\zen_uv_lib_win_64_v2_0_0.dll if os.path.exists(s_temp_lib): shutil.copy2(s_temp_lib, get_zenlib_path())Because
shutil.copy2preserves the timestamp, the restored file is indistinguishable from the
original by mtime — so the test looked like it had run without the library when it hadn’t.
A valid test requires removing bothutils/clib/zen_uv_lib_*.dlland
%TEMP%\zen_uv_lib_*.dll. Verified absent before and after the run reported above.
Ruled out
- Not file corruption. The scene opens cleanly with
--factory-startup, and again headless
with all add-ons enabled. - Not the Core Library — see the A/B directly above.
- Not a stale or duplicated install.
preferences.addonscontains no stale entries; the
earlier legacyscripts/addons/ZenUVcopy has been fully removed and only the 5.3.3 extension
is present. All 254 classes register. - Not Zen BBQ, and not any other add-on — the bisect above pins it to Zen UV alone.
- Not user scripts.
user_data/user_scripts/is untouched shipped content (all files
timestamped to the moment of install); none are active.
Still open: the specific code path. The depsgraph-timer route below is a lead, not a
conclusion — one hypothesis under it was tested and failed.
Workaround currently in use
Open the file with Zen UV disabled, then enable Zen UV from Preferences. The add-on then works
normally on that scene.
What I can provide
- The scene file, or a stripped-down version, if that helps — happy to try to produce a minimal
repro on request. - Any further probe output (RNA state, handler lists, timings) — the diagnosis above came from
scripted introspection in a live session, so specific questions are easy to answer.
