Bug Report: workflow_objc crashes Binary Ninja with ACCESS_VIOLATION on large macOS x86_64 dylib

Summary

Binary Ninja crashes with an access violation (0xC0000005) inside binaryninjacore.dll when
analyzing Microsoft Edge Framework (macOS Mach-O x86_64, 510 MB) shortly after the
Objective-C workflow begins running. The crash is 100% reproducible and always occurs at
exactly the same code offset (binaryninjacore.dll+0x01636740), triggered by workflow_objc.dll.

Environment

Target Binary

Note: ARM64 slice was not tested — only x86_64 analysis was attempted.

Steps to Reproduce

1. Open Microsoft Edge Framework (510 MB x86_64 Mach-O dylib) in Binary Ninja 5.3.9434
2. Allow default analysis to run (full analysis with all workflows enabled)
3. Wait — Binary Ninja crashes during the Objective-C workflow phase (after some minutes of analysis)

The analysis database (.bndb, ~730 MB) is partially written before the crash occurs.

Crash Details

The crash was reproduced 4 times across 4 separate Binary Ninja sessions
(PIDs: 36436, 5996, 19540, 47248) on 2026-04-21/22. Every crash is identical:

Exception:   0xC0000005 ACCESS_VIOLATION (READ)
Fault offset: binaryninjacore.dll+0x01636740  (same in all 4 crashes)
Access type: READ

Exception Record (from minidump, PID 36436)

ExceptionCode:    0xC0000005 (ACCESS_VIOLATION)
ExceptionAddress: 0x00007FFE74F46740  → binaryninjacore.dll+0x01636740
Access type:      READ
Bad address:      0x000001A98BD05000  (= RDI, freed/unmapped page)

Registers at crash

RIP: 0x00007FFE74F46740  → binaryninjacore.dll+0x01636740
RSP: 0x0000001C8946E570
RBP: 0x000001A98BD05028  (= BAD_ADDR + 0x28, points into freed page)
RDI: 0x000001A98BD05000  = BAD_ADDR  ← being read from → CRASH

RAX: 0x000000000000003E
RCX: 0x000001991E881058
RDX: 0x000001991E880C08
RBX: 0x000001A9268C0EC8
RSI: 0x000001A9268C0E40

Pattern: RDI == BAD_ADDR — the crash instruction dereferences RDI (or an offset from it),
which points to a page-aligned heap address that is no longer mapped. RBP is an offset of
0x28–0x78 bytes into the same freed page. This is consistent with a use-after-free:
an object or buffer has been freed while the ObjC workflow still holds a live pointer to it.

Stack trace (reconstructed from minidump, PID 36436)

[RSP+0x0028] workflow_objc.dll+0x2129C    ← immediate caller before crash
[RSP+0x0088] workflow_objc.dll+0x237D8
[RSP+0x0118] workflow_objc.dll+0x67181
[RSP+0x0168] workflow_objc.dll+0x223D1
[RSP+0x0258] workflow_objc.dll+0x664CD
[RSP+0x0338] workflow_objc.dll+0x816D0
[RSP+0x0340] workflow_objc.dll+0x22A3D
[RSP+0x03A8] workflow_objc.dll+0x816D0
[RSP+0x03B0] workflow_objc.dll+0x22A3D
[RSP+0x0408] workflow_objc.dll+0xAE000
[RSP+0x0410] workflow_objc.dll+0x7B860
[RSP+0x04E8] workflow_objc.dll+0x54134
[RSP+0x0508] workflow_objc.dll+0x4FF17
[RSP+0x0588] workflow_objc.dll+0x63F05
[RSP+0x05F8] workflow_objc.dll+0x96668
[RSP+0x0628] binaryninjacore.dll+0xA7B5C5
[RSP+0x06D8] binaryninjacore.dll+0xA7B130
[RSP+0x06E8] binaryninjacore.dll+0xA8306B
[RSP+0x0718] binaryninjacore.dll+0xA7B176
[RSP+0x0748] binaryninjacore.dll+0xA7B204
[RSP+0x0778] binaryninjacore.dll+0x1BF72DB
[RSP+0x07B8] binaryninjacore.dll+0x1F8B071
[RSP+0x0808] binaryninjacore.dll+0x1BF7EF9
[RSP+0x0858] binaryninjacore.dll+0x1BE5FB0

workflow_objc.dll fills the entire top of the stack, with binaryninjacore.dll worker thread
infrastructure at the bottom — the ObjC workflow is clearly the direct trigger.

Crash offsets across all 4 sessions (confirming same code path every time)

PID 36436  binaryninjacore.dll+0x01636740  BAD_ADDR=0x000001A98BD05000  RBP offset=+0x28
PID 5996   binaryninjacore.dll+0x01636740  BAD_ADDR=0x00000208E8E85000  RBP offset=+0x08
PID 19540  binaryninjacore.dll+0x01636740  BAD_ADDR=0x000002B7D4CC5000  RBP offset=+0x28
PID 47248  binaryninjacore.dll+0x01636740  BAD_ADDR=0x0000016366455000  RBP offset=+0x78

The BAD_ADDR varies per session (ASLR / heap layout), but the code offset is always
+0x01636740, and the bad address is always a page-aligned heap pointer — strongly
suggesting a freed heap object.

Workaround

Disabling workflow_objc.dll (Settings → Plugins, or via settings.json) prevents the crash
and allows the file to be opened, at the cost of ObjC class/method recovery.

Crash Dump Availability

Four minidumps are available (%LOCALAPPDATA%\CrashDumps\binaryninja.exe.*.dmp, ~23–25 MB each)
and can be attached or shared on request.