Build freezes at "main: ZBIC -> plain NSO" on v2.0.14 (fresh full build, worker python.exe at 0% CPU) #1876

Closed

opened 2026-11-10 19:12:17 +00:00 by SebasHT15 · 2 comments

SebasHT15 commented

2026-11-10 19:12:17 +00:00

(Migrated from github.com)

Builder version

2.0.14

How you built

Hookshot Builder app (Windows)

Game files given to it

A .nup

The error

**Builder:** v2.0.14 (fresh clean install)
**OS:** Windows 11 Pro (build 26200)
**GPU:** NVIDIA GeForce RTX 4090 Laptop GPU (Vulkan 1.4)
**Game:** The Legend of Zelda: Ocarina of Time (title 0400486024dec000, v131072)
**Build target:** a plain local folder (C:\Games\OOT), source = local .nup

### Background / how I got here
- The day before, I had a **working OoT build made with HookshotBuilder v2.0.11** —
  it built and ran fine. The only problem was the known **floating-trees** bug
  (#994 / #352 / #422) around Hyrule Castle and Kakariko.
- To get the floating-trees fix (merged for v2.0.12, PR #1334), I updated the
  builder. It auto-updated **v2.0.11 → v2.0.13 → v2.0.14**.
- After updating, the first thing I tried was the in-app **"update existing game"**
  flow. That froze at **"Reading your game files"** (0% CPU, no progress).
- My game/output folder was originally inside a **OneDrive-synced folder** (with the
  OneDrive client not running). Moving the output to a **plain local path (C:\Games)**
  got the build *past* the unpack stage — so OneDrive is not the root cause — but it
  then froze at the next stage ("ZBIC -> plain NSO").
- I then did a **full clean reinstall** (deleted %LocalAppData%\HookshotBuilder and the
  game output, re-downloaded the .nup, fresh builder install, full from-scratch build).
  It still freezes at the same "ZBIC -> plain NSO" line, as described below.

**Summary:** v2.0.11 built fine; freezing began only after updating to v2.0.13/v2.0.14,
and reproduces on a completely clean install.

### What happens
On a fresh, from-scratch build the unpack stage completes fine — it writes all
**186,588 files (26.27 GB)** — then the build reaches ~4% and **freezes at**:

It never progresses past this line. No compiler processes ever start.

### Key detail (what's actually hung)
The GUI (`HookshotBuilder.exe`) is idle, but the real worker is the bundled
**`...\versions\v2.0.14\HookshotBuilder\tools\python\python.exe`**, which sits at
**0% CPU and 0 bytes/s disk I/O indefinitely** — it's deadlocked, not slow.
Killing `HookshotBuilder.exe` does NOT kill this python worker; it keeps running.

### Reproducibility
- Happens every time, including after a **completely clean reinstall** of the builder
  (deleted `%LocalAppData%\HookshotBuilder` and reinstalled).
- Tried output folders both inside OneDrive and on a plain local path (C:\Games) — same.
- Retrying (kill + rebuild, incremental) advances one stage at a time but keeps
  re-freezing.

### Possibly relevant
- `%LocalAppData%\HookshotBuilder\system_headers.txt` is **0 bytes** after setup.
- A **v2.0.11** incremental update built fine the day before; freezing started only
  after the builder auto-updated to v2.0.13 → v2.0.14 and I did a full from-scratch build.

Visual Studio or Build Tools version, and Windows SDK version

No response

Operating system and free space on the output drive

Windows 11

Before you send it

I'm on the newest release, or it still fails on it.
I searched the open issues for this error.
I'm not attaching game files or anything built from them.

### Builder version 2.0.14 ### How you built Hookshot Builder app (Windows) ### Game files given to it A .nup ### The error ```text **Builder:** v2.0.14 (fresh clean install) **OS:** Windows 11 Pro (build 26200) **GPU:** NVIDIA GeForce RTX 4090 Laptop GPU (Vulkan 1.4) **Game:** The Legend of Zelda: Ocarina of Time (title 0400486024dec000, v131072) **Build target:** a plain local folder (C:\Games\OOT), source = local .nup ### Background / how I got here - The day before, I had a **working OoT build made with HookshotBuilder v2.0.11** — it built and ran fine. The only problem was the known **floating-trees** bug (#994 / #352 / #422) around Hyrule Castle and Kakariko. - To get the floating-trees fix (merged for v2.0.12, PR #1334), I updated the builder. It auto-updated **v2.0.11 → v2.0.13 → v2.0.14**. - After updating, the first thing I tried was the in-app **"update existing game"** flow. That froze at **"Reading your game files"** (0% CPU, no progress). - My game/output folder was originally inside a **OneDrive-synced folder** (with the OneDrive client not running). Moving the output to a **plain local path (C:\Games)** got the build *past* the unpack stage — so OneDrive is not the root cause — but it then froze at the next stage ("ZBIC -> plain NSO"). - I then did a **full clean reinstall** (deleted %LocalAppData%\HookshotBuilder and the game output, re-downloaded the .nup, fresh builder install, full from-scratch build). It still freezes at the same "ZBIC -> plain NSO" line, as described below. **Summary:** v2.0.11 built fine; freezing began only after updating to v2.0.13/v2.0.14, and reproduces on a completely clean install. ### What happens On a fresh, from-scratch build the unpack stage completes fine — it writes all **186,588 files (26.27 GB)** — then the build reaches ~4% and **freezes at**: It never progresses past this line. No compiler processes ever start. ### Key detail (what's actually hung) The GUI (`HookshotBuilder.exe`) is idle, but the real worker is the bundled **`...\versions\v2.0.14\HookshotBuilder\tools\python\python.exe`**, which sits at **0% CPU and 0 bytes/s disk I/O indefinitely** — it's deadlocked, not slow. Killing `HookshotBuilder.exe` does NOT kill this python worker; it keeps running. ### Reproducibility - Happens every time, including after a **completely clean reinstall** of the builder (deleted `%LocalAppData%\HookshotBuilder` and reinstalled). - Tried output folders both inside OneDrive and on a plain local path (C:\Games) — same. - Retrying (kill + rebuild, incremental) advances one stage at a time but keeps re-freezing. ### Possibly relevant - `%LocalAppData%\HookshotBuilder\system_headers.txt` is **0 bytes** after setup. - A **v2.0.11** incremental update built fine the day before; freezing started only after the builder auto-updated to v2.0.13 → v2.0.14 and I did a full from-scratch build. ``` ### Visual Studio or Build Tools version, and Windows SDK version _No response_ ### Operating system and free space on the output drive Windows 11 ### Before you send it - [x] I'm on the newest release, or it still fails on it. - [x] I searched the open issues for this error. - [x] I'm not attaching game files or anything built from them.

NotRexed commented

2026-11-11 01:15:38 +00:00

(Migrated from github.com)

v2.1.0-rc.1 is out as a pre-release (https://github.com/NotRexed/Hookshot/releases/tag/v2.1.0-rc.1) and carries #1885 (no reopening of ~100k files after the unpack, which is where the Builder sat at "main: ZBIC -> plain NSO" / reading). If you can, try a build with it and say whether it gets past that stage. This stays open until 2.1.0 is final.

**v2.1.0-rc.1 is out as a pre-release** (https://github.com/NotRexed/Hookshot/releases/tag/v2.1.0-rc.1) and carries #1885 (no reopening of ~100k files after the unpack, which is where the Builder sat at "main: ZBIC -> plain NSO" / reading). If you can, try a build with it and say whether it gets past that stage. This stays open until 2.1.0 is final.

NotRexed commented

2026-11-11 02:32:14 +00:00

(Migrated from github.com)

Fixed in v2.1.0. The long silent stop after "ZBIC -> plain NSO" was the damaged-texture check reopening about 100,000 extracted files. It now uses what the extraction already saw (#1885) and shows its progress while it runs. If a build still stops there on 2.1.0, reopen with the Builder's log.

Fixed in [v2.1.0](https://github.com/NotRexed/Hookshot/releases/tag/v2.1.0). The long silent stop after "ZBIC -> plain NSO" was the damaged-texture check reopening about 100,000 extracted files. It now uses what the extraction already saw (#1885) and shows its progress while it runs. If a build still stops there on 2.1.0, reopen with the Builder's log.

Commenting is not possible because the repository is archived.