Repository navigation
EBolt_DrawArcs possible incompatibility with Antares #2361
Description
Description
From Claude, take with grain of salt but whatever:
Subject: Antares + Phobos co-load — null deref in EBolt_DrawArcs crashes on every electric bolt
Environment
Syringe 0.7.2.0 (CnCNet branch), gamemd-spawn.exe, injection order Antares.dll, CnCNet-Spawner.dll, Phobos.dll, …. Antares reports "Yuri's Revenge 1.001 (modified). Applying Ares 3.0p1."
Symptom
C0000005 at 0x778F65CB (Phobos.dll base 0x778C0000, RVA 0x365CB = EBolt_DrawArcs), ECX = 0. Reproduced identically in three crash dumps over four days. Fires on the first electric bolt drawn — any Tesla Coil / Tesla Trooper / Tesla Tank shot.
Faulting code — Phobos EBolt_DrawArcs, hook site 0x004C20BC (11 bytes, replaces vanilla cmp [esp+0x28],8 / jge 0x4C2400):
Root cause
BoltTemp::ExtData has exactly one writer in Phobos .text: the hook at 0x004C1F33 (EBolt_Draw_Colors), which caches the lookup for the consumer at 0x004C20BC.
Antares hooks the same address 0x004C1F33 with its own EBolt_Draw_Colors (Ares-parity [Weapon] Bolt.Color1/2/3). That hook replaces the vanilla colour-init loop at 0x4C1F33–0x4C1F64 and therefore must return 0x4C1F66. Under Syringe, a non-zero return is a jump target and suppresses the remaining hooks at that address — so Phobos's EBolt_Draw_Colors never runs, and the global stays zero from BSS.
0x004C20BC is hooked by Phobos only. Antares has nothing there, so the consumer runs against the null producer.
Antares' colour hooks at 0x4C24BE/0x4C25CB/0x4C26CF return targets that jump past Phobos's 0x4C24C3/0x4C25D0/0x4C26D5, so those Phobos hooks are also inert — they'd have dereferenced the same null. EBolt_DrawArcs is the sole survivor of the shadowing, and the sole crash.
Evidence
Minidump ModuleList → EIP resolves into Phobos.dll; export table → EBolt_DrawArcs + 0x1B.
Live value read from the dump: BoltTemp::ExtData @ 0x779F4FA8 = 0x00000000. Symbol name from Phobos.pdb (S_GDATA32, .data-relative 0x1FA8).
.syhks00 diff across all loaded DLLs confirms 0x004C1F33 is the only contested site in the EBolt range, and that 0x004C20BC is uncontested.
Antares source src/Ext/WeaponType/Hooks.Bolt.cpp:31 confirms the unconditional return 0x4C1F66.
Assessment
Antares' behaviour at 0x4C1F33 is correct and its return value is forced by the instruction range it replaces. The fragility is on the Phobos side: one feature split across a producer hook and a consumer hook, with no guard if the producer is shadowed. Any framework legitimately claiming 0x4C1F33 turns 0x4C20BC into a null deref.
Suggested fix (Phobos)
Guard the consumer so a shadowed producer degrades to vanilla instead of crashing:
Same guard applies to EBolt_DrawFirst/Second/ThirdColor, which read the identical global and are currently only saved by Antares jumping over them.
Structurally: the producer/consumer pair is only safe if both sites are uncontested. Merging into a single hook, or reading the per-bolt BoltExt map directly at 0x4C20BC instead of via the cached global, removes the coupling — the map itself is populated correctly, since Phobos's EBolt_CTOR (0x4C1E42) and TechnoClass_FireEBolt_SetExtMap_AfterAres (0x6FD494) both run without interference.
Broader note
Antares and Phobos share 144 hook addresses. Most are CTOR/DTOR/SaveLoad_Prefix observers returning 0, which chain safely. The risk set is the feature hooks that return jump targets — worth an automated .syhks00 diff in CI flagging addresses hooked by both projects where either side returns non-zero.
Phobos Version
b48
Conditions to reproduce
Antares. I never had this with Ares.
https://drive.google.com/file/d/1Zzj79-sTxU2PcrTV5NQpBVkFYLF-GB4e/view?usp=sharing
syringe.log
except.txt
debug.log
INI code
Literally vanilla [SHK]Steps to reproduce
- AI builds SHK
- SHK attacks
- GG
...
Expected behaviour
bzzt bzzt
Actual behaviour
Fatal Error
Additional context
No response
Checklist
- The issue happens on the latest official version of Phobos and wasn't fixed yet.
- I agree to elaborate the details if requested and provide thorough testing if the bugfix is implemented.
- I added a very descriptive title to this issue.
- I used the GitHub search and read the issue list to find a similar issue and didn't find it.
- I have attached as much information as possible (screenshots, gifs, videos, debug and exception logs, etc).
Activity
DeathFishAtEase commentedon Sep 12, 2026
Phobos has not yet been made compatible with Antares, and testing after Antares completes its refactoring of 3.0p1 has also not been completed (currently there is only some discussion on Discord about its performance being inferior to Ares 3.0p1).
In addition, Phobos has a large amount of content that interacts with Ares implemented through patch ares; they require the exact addresses of Ares 3.0(p1), while Antares obviously is not completely identical to Ares at the binary level (otherwise there would be no need to test the refactoring results). Therefore, using Phobos together with Antares will inevitably have a large number of incompatibility issues, not just EBolt.
If you want to test Antares, I suggest doing so without using Phobos; as mentioned above, many Phobos features will inevitably not work / be executed incorrectly. If Antares is tested to be sufficient to replace Ares, then merging Phobos with Antares is also a better choice than maintaining compatibility between DLLs. You can also try porting Phobos to Antares yourself to avoid such compatibility issues.
SethGekco commentedon Oct 4, 2026
I was merely leaving feedback in case the information is of some use for people. As for suggesting I don't use phobos, absolutely not. I already fixed the bugs here with a third dll, I just shared information so whoever cares doesn't have to find it themselves.
DeathFishAtEase commentedon Oct 4, 2026
No one is suggesting that you don't use Phobos; we are merely reiterating a basic fact: Antares and Ares have numerous inconsistencies in binary addresses - it is not completely equivalent to the open-source version Ares3.0p1, and some implementations of Phobos will inevitably fail to work when used together with Antares in the same way Phobos works when used together with Ares.
So, if you are going to test Antares to assist us in improving, then you should focus on the performance in the two Phobos-free environments: YR+Ares and YR+Antares. If you want to use Phobos, then you should use Ares rather than Antares - the latter has not provided and does not plan to provide an alternative option in this regard.
Of course, we would only be glad to learn that you resolve these conflicts through a third DLL. Nevertheless, our plan is, after ensuring that Antares has no errors in the details of each feature reimplementation and no obvious performance defects, to port all content in Phobos that needs to interact with Ares to Antares, or to merge them into 1 DLL in the future, or some other future plan.
As for feedback information, I can only say that having it is better than not having it, but based on the basic facts mentioned above, users should not have expected Antares to be able to replace the Ares option in the YR+Ares+Phobos combination...