VOGONS


Reply 40 of 46, by Stenzek

User metadata
Rank Newbie
Rank
Newbie

My usual process for debugging these sorts of issues was to look at the instructions executed around exceptions - usually the error was there. Or, looking for places where it ends up executing code at 0000:0000 after a return, which could indicate a stack issue.

Reply 41 of 46, by superfury

User metadata
Rank l33t++
Rank
l33t++

Well, the main problem is that the only workable huge file editor I've managed to find so far(Liquid Studio 2018) doesn't support line numbers, so all I can do is search operations(which take some time) without any line number support(oddly enough disabled for huge files). One good point is that it doesn't hog memory like all others(with 8GB RAM installed it gets filled around the 2-2.5GB text file loaded mark, at which point hard drive trashing starts to occur immediately slowing the whole system to a halt).

Tried KDiff with said log and win30_s.txt, but somewhere after loading the file(confirmed 25% loaded yesterday), looking at the loading proccess a few hours later(about 8-10 hours later this morning) showed Windows having a crash report on KDiff. So it just crashed trying to load said file(memory shortage), even though up to a theoretical 64GB swapfile(on a seperate partition) is available(autosize swapfile on Windows 10 up to 64GB). Atm it's set up for 1910-65384MB swapfile(entire swap partition).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 42 of 46, by superfury

User metadata
Rank l33t++
Rank
l33t++

Hmmm... Odd. Tried using the shareware version of Total commander to compare the two files(ran fine yesterday), now after replacing the "CR0: X" value with "CR0: 8" or "CR0: 0" for 80386 compatiblity in the win30_s.txt log file(for comparing the two on a 80386), now total commander just crashes after loading the entire file in memory and comparing 20% of said file?

Edit: MinGW(MSYS2)'s diff tool is pretty useless as well: It just gives the entire file as being different(because some registers start out differerently(EAX)):S

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 43 of 46, by superfury

User metadata
Rank l33t++
Rank
l33t++

Can you make those two logs(win3.0 standard&enhanched(386) and win3.1 enhanced) again with 80386 emulation? The 80486+ logs diverges too much to be compared during diff(entire logs diverges due to startup register states having wrong registers(e.g. EAX having high bits set(0x40000)).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 44 of 46, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just a little question: what emulator did you create those logs with?

Edit: Just improved my emulator's CR0 reset and write behaviour to only keep the defined bits(clearing the others, with 80486 setting bit 4). I've also improved the 80486 to keep bits 29/30 during reset(as documented).

Edit: Now logging on a 80486. But I see all kind of triple faults from an INT3 instruction on that(Windows 3.0 in Standard mode)?

It's the usual Windows 3.0 with MS-DOS 6.22 boot menu(only HIMEM.SYS loaded from the Windows directory) on a 80486 in Standard mode.

Edit: I see the INT3 triple fault keeps occurring on 0110:0AB3
Edit: I see INT 31h with AX=0002? Apparently mapping a real-mode segment to a LDT descriptor?

DPMI interrupt 31h calls: http://www.delorie.com/djgpp/doc/dpmi/ch5.n.html

Edit: The DPMI interrupt does end up at the correct 0051:2832 address.

Edit: UniPCemu's latest 80486(improved CR0 register to handle undefined bits and reset/init state better) running far into the Windows 3.0 booting(a few disk reads before crashing into the MS-DOS prompt), having aborted it since it took so long to log:
https://www.dropbox.com/s/hy28hu1pr94vubd/deb … 10_1736.7z?dl=0

Still running a diff against win30_s.txt, which takes a long time("diff -u --speed-large-files win30_s.txt debugger.log>win30_s.diff").

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 45 of 46, by Stenzek

User metadata
Rank Newbie
Rank
Newbie

Logs were created with my emulator: https://github.com/stenzek/pce

I'm not sure if diffing the traces in their entirety would be the best way to figure out what's going on - there will be a lot of noise, and timings for interrupts being dispatched can differ and cause the trace to be misaligned for large blocks of instructions at a time. If you can find a point in time where things start to go bad, e.g. executing code at offset 0, invalid instructions, etc, I'd suggest trying to find the corresponding IP in my/another emulator's trace, and examine the execution up to it. Or, at least that's how I've solved issues in the past anyway 😀

Reply 46 of 46, by superfury

User metadata
Rank l33t++
Rank
l33t++

Well, it for one SHOULD be able to tell me the places that actually divert(except IRQs).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io