workflow_objc crashes below MediumLevelILInstruction::get_operand_list when analyzing large x86_64 dylib

[ssiebert-pg]

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

Field	Value
Binary Ninja version	5.3.9434 (stable)
OS	Windows 11 Business 64-bit (Build 26100)
RAM	64 GB
binaryninjacore.dll SHA256	413D295167A45B8FFDBE72CAD2E467E93B1A122DBF6ADA6A82F026CF234B28BE
workflow_objc.dll SHA256	667121E07B03C3E9DC1201F12D9C86532D0E89C1DF98AD983A587D8A01E9CF73

Target Binary

Field	Value
File	Microsoft Edge Framework (Mach-O dylib, no extension)
Origin	Microsoft Teams WebView.app — Microsoft Edge Framework.framework 145.0.3800.97
Architecture	x86_64 (macOS)
Size	510.3 MB
SHA256	1CF6016A74F4578A70FB1EF95536BB059EE8AC3E499D3CF1FCE19C499FF23E9B

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.

[bdash]

Can you please upload the minidumps via the portal and share their identifiers here?

[ssiebert-pg]

recursive amplitude bonds crucially
haven spear flows masterfully
scalar pattern talks supremely
single energy shines quickly

[bdash]

Thank you! I was able to match those to an existing crash report we have received that did not include information on how to reproduce.