Cxbx-reloaded: EmuX86 Read/Write Not Verifying Address Before Set Value

[RadWolfie]

Since Cxbx-Reloaded has made numerous of silent crashes in the past. It has been a mystery until recent discover from loader project with kernel console enabled cause increase chance of crash. This crashes led to EmuX86 not checking the address if it is a valid pointer. Yet, it try to repeatedly set the value at invalid address.

So, we need add checks for the address EmuX86 try to set. If the address is not valid, then we should produce a fatal crash. Allowing increase chance for developers to find the fault easier and correct them. Plus reduce false positive for the work had been done which could be correct instead of discard it.

[gandalfthewhite19890404]

Tested with WWF Raw, happens here:

[RadWolfie]

With WWE RAW 2 title, random exceptions would be EmuX86_Mem_Read/EmuX86_Mem_Write and xbox's breakpoint (op code 0x33 0xcc, INT 3h). I had not verified the xbox breakpoint. However, I can confirm both EmuX86_Mem_Write and hardware breakpoint occur in last known ExecuteDpcQueue from call stack inspection. However, it is likely not relative to ExecuteDpcQueue process. More likely an issue with incomplete implement within the API/LLE work.

Working example of EmuX86_Mem_Write's fatal exception:

EIP address is 0x001aaafb, which is from D3D section. It does not have symbol detected for the function. Yet is in-between CMiniport symbols class.

[gandalfthewhite19890404]

I have got in WWF RAW (not WWE RAW 2), and I should take (I don't have VS2019 at my home PC, so not many test-cases at current time) more games for testing.

[PatrickvL]

As for ExecuteDpcQueue, that's a kernel level function that might lead to Xbox code getting executed, so it's not uncommon that could lead to EmuX86_DecodeException getting hit.

In there, when we detect the exception is due to an Xbox instruction accessing guarded memory, we assume this memory is under control of a hardware device on Xbox, and thus emulate that instruction using memory access functions (read or write) instead of accessing the given address directly. These functions make it possible to emulate Xbox hardware devices that aren't present on the host machine.

Until here, nothing special.

What's special however, is that some of the accessed addresses don't belong to hardware devices, so instead we pass those addresses on to reading or writing regular (host) memory, assuming that this address wasn't the address that caused the exception.

This, because some instructions trigger multiple memory reads and/or writes, so it's not clear which one of those accesses was the one that caused the exception. (It might even be that the instruction itself is forbidden, while all memory accesses are otherwise just fine.)

So that's why we pass on to EmuX86_Mem_Read/EmuX86_Mem_Write, even when there's big warning in the header comment of those functions, reading :
// Only allowed to be called outside our EmuException exception handler, // to prevent recursive exceptions when accessing unallocated memory.

Now, what can happen, is that the exception is actually caused by accessing a memory address that's not readable or writable, like addresses that reside in the zero page (which is a common mistake), or addresses in pages that weren't allocated or are already released, or whatever else a rogue Xbox memory pointer could reference to.

So, sometimes it's just bad Xbox code acting up, sometimes it's the result of our patches skipping some sort of initialization that would have taken place otherwise, and yet other times it's a bug in our emulation that caused this.

In general, we'd have to investigate every occurrence for the actual root cause, and handle it accordingly.

[PatrickvL]

As for the 0xcc (INT 3h) opcode - if our exception handler hits that in Xbox code, we'd better emulate that just like how the Xbox would behave. But if it's hit in emulation code, then it'd have to be passed on to the host (debugger).

[RadWolfie]

When I got an exception for 0xcc opcode, it was end of the function with multiple of 0xcc op code. So, something didn't go right.

[LukeUsher]

When Xbox hits a breakpoint opcode, on a retail Xbox it causes a crash/kernel panic because there is no debugger there to catch it.. It is not recoverable except on Debug units.

Any breakpoint occurrence (int 3) needs to be hooked and investigated, but we should not make it a fatal error, because doing so would prevent us manually inserting breakpoint in Xbox code via the assembly view in Visual Studio.