Have been checking out NT 4.0 workstation's setup disks booting today.
So far, I saw the loading of addresses 0x40000 through 0x96000 page faulting.
Right after 0x96000 it seems to report the error of the PROCESS1_INITIALIZATION_FAILED BSOD.
So I'm getting closer to the actual problem?
Edit: Looking at the file size of NTDLL.DLL, it matches the amount of 4K blocks loaded exactly? So it's probably loaded the entire NTDLL.DLL file at the 0x40000-0x9650F memory range.
CR3 points to 0x30000 as usual on Windows NT it seems (perhaps 9x as well as far as I can remember)?
UniPCemu's new memory viewer functionality really comes in handy now! 😁 Although a simple memory dump which I've already taken also works (combined with a hex viewer).
Been thinking though... Perhaps an address converter would come in handy as well with this (a simple linear to physical memory address converter to convert addresses to use with the memory viewer).
NTDLL's final blocks seems to be at physical address 00846000 (linear address 0x96000).
Edit: Just implemented an extension to the memory viewer (with some extra functions added to the paging unit). It is now (in source control only so far) able to display virtual memory besides memory. This is triggered by the triangle button combined with the cross button on the PSP-style inputs (numpad 8 pressed, then using numpad 2(cross) when releasing numpad 8(triangle) as a trigger, working the same way as the other triggers for the triangle).
So it's triggered like the old memory viewer, but using cross instead of square. And circle behaves as the same kind of modifier, but triggers a memory dump instead.
So now you can use the debugger to view physical memory as well as virtual memory.
The virtual memory has a slight bonus feature, where the memory that's unmapped displays as unmapped memory(all ones), but if the cursor is placed on such an address, the color of it and the headers will become dark orange instead (indicating it's not mapped by the paging unit according to the paging tables in memory).
Memory is viewed using the virtual memory viewer with the CPL of the currently executing instruction. Beware that if the instruction transfers to a different kind of privilege level (user vs kernel), the memory addresses will display according to the memory in the changed privilege level (so for an return instruction it would be as viewed from the location after the return finished).
Using the virtual memory viewer with an address that's not RAM or ROM will cause state issues like the CPU accesses do (like for example being mapped to flash ROM that's not in ROM mode causing possible state changes in the connected hardware) for the address translation to RAM addresses. The RAM access itself only affects the RAM modules itself directly (it's not going through the entire memory controller, so it won't be able to properly read connected ROMs or video adapter memory, just as the physical address memory viewer does). So the ROM and VRAM accesses only happen when the page tables themselves are in ROM or VRAM. The memory pointed to be the page tables can only reside in RAM to view, otherwise returning unmapped memory or the memory below said chips (that's blocked by the memory mapped device usually, depending on the motherboard chipset).
Address 200 and onwards in the ntdll.dll file (Address 40200 in linear memory) seems to match what's in the file with what's in the emulator memory?
Edit: Just added some more support to the virtual memory viewer. It will now ask if it's to use kernel privilege (forcing CPL 0) for memory accesses. Otherwise, it will use the debugged instruction's privilege level (unless canceled, which returns to the debugged instruction).