protonscr

MBAACC mod expects D3D9 device vtable to be writable

dxvkopen d3d9
doitsujin/dxvk#5054 · opened 2025-06-27 by awaken1ng · updated 2025-06-29 · 1 comments · github
1 matching comments, n / p to jump
Aawaken1ng 2025-06-27 github

When mod attempts to hook into the game, it crashes with Unhandled page fault on write access.

Crash happens at this particular line.

It takes IDirect3DDevice9* from the game, and tries to hook the Reset, BeginStateBlock, EvictManagedResources functions by overwriting their entries in vtable.

Apparently native D3D9 allows that.

The more cursed part is that at some point it resets the vtable, which is what mod also expects, and it rehooks after BeginStateBlock.

WineD3D runs into the same issue.

With a couple of hacks, I was able to get it running on WineD3D, by removing the const from the D3D9 vtable; and copying the vtable on initialization and AddRef for resetting part.

Steps to reproduce:

  • open CCCaster
  • start the training mode by pressing [4] Offline and [1] Training
  • start the mod
  • it should attach itself without crashing the game

It's probably too cursed and niche to support properly, so mostly leaving it here for the sake of documenting an edge case.

Software information

Melty Blood Actress Again Current Code, community edition, with CCCaster and MBAACC-Extended-Training-Mode

System information

  • GPU: RX 6700 XT
  • Driver: Mesa 25.1.4-1
  • Wine version: 10.9
  • DXVK version: 2.6.2
  • MBAACC-Extended-Training-Mode version: f42627456d9c5ecc2dce00ae52f7a80ab1388781 (bleeding edge at the time of writing, same issue with 2.0)

Log files

wine-log-with-dxvk.txt

Ddoitsujin maintainer 2025-06-29 github

Think this is only supportable if we heavily abuse implementation details and allocate our own vtable, but we don't know the size of it since we don't have low-level access to it like a C implementation would.

I really don't want to do this, especially not for some obscure mod.

Nothing extracted yet.