Cxbx-reloaded: Emulation Project with C++ Exception Doesn't Always Work

[RadWolfie]

After thoroughly testing to find out what reason C++ exception doesn't work with loader's emulation project. It turns out C++ exception does work fine after add test try/catch after Emulate function. Plus GUI's internal emulation has the same issue as well.

However, without kernel console output. Emulation is working as intended.

---

Steps to reproduce:
1) Enable kernel console output
2) Run GTA 3 (best title to test with, since always will format the partition.)
3) Monitor which partition is formatted. (In my case it is partition 5.)
4) Stop emulation
5) Mark any files inside partition 5 as "read only".
6) Run GTA 3 again
7) Once get to "Calling XBE entry point..." from console window, silence crash occur or the error message Visual Studio caught below.
Unhandled exception at 0x75544192 in cxbxr-ldr.exe: Microsoft C++ exception: std::filesystem::filesystem_error at memory location 0x0D23F56C.

[gandalfthewhite19890404]

Maybe it a different behavior but:
Gun crashes with exception popup window (with EIP etc) without loader checkbox, but with using Loader just crashes silently.

[RadWolfie]

What has been verified on Windows platform:
NOTE: Windows' C++ exception is using SEH method.

• To the point of xbe's entry point was called, both SEH and VEH exceptions are 100% working.
• After xbe's entry point... (force exception in CxbxFormatPartitionByHandle function)
  
  
  
  • VEH exception is 100% working.
  
  
  • With kernel console opened:
    
    
    
    
    
    • C++'s exception is not working.
    
    
    
    • SEH exception is not working.
    
    
    
  
  
  • Without kernel console opened:
    
    
    
    
    
    • C++'s exception is working.
    
    
    
    • SEH exception is working.
    
    
    
  
  

While I was investigating C++'s thrown exception test, I have received unexpected invalid value in the process of throw exception.

Summary:
It seems there is some sort of corruption occur with kernel console opened. How exactly it happen remains unknown.

[PatrickvL]

The kernel console is writing to standard output (STD_OUT, or whatever the symbol is).
I few years ago (when I implemented the code that replaces the running Windows executable image header with the one from the XBE that we're going to emulate), I noticed that a few of the Windows API's that are used for writing to std out, rely upon fields from the Windows executable image header (for instance, TLS related fields).
Therefor, I hacked the code to be able to switch back and forth between 'pure' XBE image header and 'Windows+Xbox compatible' image header.

It's possible std-out Windows API use more fields than the few that I replaced up until now?

EDIT : See RestoreXbeImageHeader and RestoreExeImageHeader

[RadWolfie]

I notice something is off with IMAGE_DIRECTORY_ENTRY_TLS fields since it only return zero'd for loader project. I took a look with CFF Explorer software to verify it. It is confirm not in loader project.

Since I'm not able to resolve __tls_array and __tls_index symbols in loader project. I tried to use cxbxr-emu project's TLS directory. The result is the same.

Next thing I tried is completely disable console allocated block which was mainly used for old cxbx project. Loader project does have subsystem already set to console. With relative to STD_OUTPUT_HANDLE @PatrickvL was talking about. When I try again, I still get the same issue.

Even temporary freed and re-allocate console didn't do the trick either.

I'm back to square one and do not know what to do next.