And trying to run the Windows 3.1 setup.exe under MS-DOS 6.22 running a CD-ROM driver (OAKCDROM) and EMM386 loaded, I see the CPU get into the hang condition trying to #GP(0) fault for a IN AL,DX instruction. Though this should have worked properly.
Edit: Managed to fix the issue.

Windows 3.x's EMM386 somehow doesn't detect all RAM? It only shows 256KB of EMS memory available, unlike MS-DOS EMM386's 50ish MB (all HIMEM extended memory).
Edit: Checked Windows 3.1 EMM386.SYS without parameters. It only reports 256K (262144 bytes) of EMS memory? That's of 640K EMS memory total, as reported by the driver to MEM.EXE.
So there's definitely going something wrong with it's execution.

I do notice something interesting with Windows 3.1.
Running it in Standard mode, even with EMM386 loaded, runs fine. I can run apps fine.
But when in calc.exe I try to perform any of the buttons, it gives a beep and does nothing (except give a beep).
Only the C (clear) button works, which causes the text "Invalid value for this" to flash a few times before resetting to 0.
Opening the app also gives said value inside the current output box. Using the Edit and View menu items gives a beep also, doing nothing.
So does 'Search for help on...'. The other help menu items function as they should (opening the help, which seems fully functional).

Just found an issue with the segment write function detecting if it's active or not. It increments a variable to indicate it's active and is supposed to decrease it when it terminates (keeping track of if it's recursively called or not executing for internal state reset purposes). When it was executing a stack access that was pending or faulting, it would mistakenly increase the counter before returning to the calling function (the opcode handler) instead of properly decreasing the counter.
So that would cause future segment (and descriptor) handling to correctly increase it, where the level of the handler was always 1 (or for multiple calls) even higher. A bit like Windows' IRQL getting stuck on a higher level instead of properly decreasing, with some calls increasing the level even further (which isn't supposed to happen).
So in that case, even handling that isn't using said function is behaving as if it's called by the recursive handler, resetting instruction state (changed registers, changed descriptor caches etc.) upon being handled, instead of handling it like a non-resetting instruction (or task switch-specific behaviour failing becauseo of this, as it runs some things without said resetting behaviour (which is required for it to function properly)).

Fixed some issues with the latest TSS reads/writes in protected mode. The accesses were using the privilege level of the running application instead of being performed at proper privilege level 0 (causing TLB misses due to the accesses when being done at privilege level 3 context to not translate the memory accesses, effectively accessing unmapped RAM locations for higher half kernels, for example linear memory location past the amount of physical memory or BIOS ROM accesses at FFFF0000+).

Improved the logging of the memory transactions a bit.
It now uses various text lookup tables to determine how to log the data of a bus transaction, which depend on the type of bus transaction being logged as well as various other settings.
It will now also log 64-bit addresses on the memory bus itself (new behaviour), while only using 32-bit addresses for paged or segmented (actually offset) addresses (called Normal in the logs) and log the IO addresses using 16-bit numbers (4 hexadecimal digits) like it did before.
Thus the complexity of the function has increased a bit due to the extra text strings being used, but reduced due to the many duplicate code being merged into one common case (just various text values change depending on the logging mode after all).

Ok. Windows still crashes in 386 mode and calc still fails in all CPU/windows modes(real, standard and even 386 enhanced mode before the paging and protected mode through BIU changes). But somehow the diagnostics from hiren's bootcd 7.1 don't fail (the troubleshooter tested as well as pc doctor), both reporting no errors on the cpu somehow? Perhaps protected mode through BIU-with-paging only issues somehow? But EMM386+standard mode runs, so it at least works partially? Why would win.exe terminate itself to MS-DOS prompt? I don't see any page faults (that happen when the GUI starts)? So paging probably isn't the issue itself somehow?
Checked the BIU using my simple testbiu test program (aligned and unaligned reads and writes are checked), but it checks out without errors. Perhaps another fault is occurring?
According to AI it's probably memory read/write issues, seeing as either calc.exe or the FPU emulation driver is failing (with 10 byte data somehow)?