Windows NT Versions BSoD on PCem

[Battler]

This is happening since rv199. The BSoD is:
STOP 0x000000BE
An attempt was made to write to read-only memory.
This occurs on Windows 2000 RTM, before even getting to the login screen.

Edit: According to SA1988, NT 5.0 Build 1877 BSoD's with Fatal System Error 0xc000021, while it worked fine on rv198 and earlier.
According to my own testing, Windows NT 3.1 and 4.0 work fine.

Edit #2: When trying to run Windows XP, it boots fine, but then I get a window saying:
userinit.exe
The application failed to initialize properly (0xc0000005). Click on OK to terminate the application.
And then it gets stuck there for a while until a screen appears saying NT AUTHORITY\SYSTEM has initiated a shutdown.

Edit #3: After applying revisions 200 to 202, it gets worse. Now the window in XP appears even earlier and says services.exe instead of userinit.exe.

[SarahWalker]

Should be fixed in rev 203.

[Battler]

At least XP works properly now, thank you. However, Windows 2000 RTM now causes PCem to crash. It happens after I successfully enter the correct password in the login screen. The login screen disappears, then it's stuck for a while, then the emulator crashes.

[SarahWalker]

Is this with recompiler or not? What emulator configuration? Windows 2000 seems to work okay for me here.

[SA1988]

recompiler actually

[SarahWalker]

What emulator configuration?

[SA1988]

Config:

Award 430VX, cpus set to Pentium (MMX and non-MMX count and variable Mhz), S3 Trio64, SB16, ram set to around 128-256MB.

[Battler]

I use the same, but AWE32 for sound. Windows 2000 worked fine in rv198 and earlier. Also, recompiler here too.

[SarahWalker]

Is RTM the final released Windows 2000 or is it some kind of beta? If the latter then I'm not going to spend too much time on it.

As I said though, Windows 2000 works okay for me, with pretty much the same configuration you're both using.

[nerd73]

Is RTM the final released Windows 2000 or is it some kind of beta? If the latter then I'm not going to spend too much time on it.

As I said though, Windows 2000 works okay for me, with pretty much the same configuration you're both using.

RTM is the final release before service packs.

[Battler]

- TomWalker: RTM is Release To Manufacturing. It is the final version of the product. What nerd73 said.

Edit: What graphics card are you using to emulate Windows 2000? I'm using the Phoenix S3 Trio64 with 4 MB video RAM.

[SarahWalker]

Paradise Bahamas 64

[SarahWalker]

When you say PCem crashes, does it actually crash or just exit? If the former, could you do a debug build, run GDB on it and disassemble around the crash address (which will probably be in generated code) and post it here (and also the current values of cs and pc)? If the latter, could you post pclog.txt here?

It would also help if you could do some more detailed investigation, if you're up for it. Go through codegen_ops_mov.h/codegen_ops_arith.h/codegen_ops_logic.h, disable each function one by one (by putting 'return 0;' at the start) until Windows 2000 starts working again, and post which one fixed it.

[Battler]

It actually crashes.

[SarahWalker]

Okay. Are you able to follow up on any of the suggestions in my post?

[Battler]

I am disabling the codegen functions on by one. I am going to report as soon as disabling one of them fixes the crash.

[SarahWalker]

Okay, thanks!

[Battler]

After disabling the following function:
static uint32_t ropMOV_b_imm(uint8_t opcode, uint32_t fetchdat, uint32_t op_32, uint32_t op_pc, codeblock_t *block)
Windows 2000 works again - the emulator no longer crashes.

[SarahWalker]

Great! Can you run the (crashing) emulator through GDB and perform the steps I mentioned in my previous post? You will probably need to disassemble around 100 bytes before and after the crash address.

[Battler]

I can't. My MingW Msys shell says command not found when I type gdb.

[SarahWalker]

Download GDB then? It's pretty useful to have.

[Battler]

OK, done. Now, when running the PCem executable with GDB, i get an unknown target exception immediately and that's it.

[SarahWalker]

Please post the entire output from GDB.

I've googled that error btw, and it suggests one possible cause is trying to debug a 32-bit application from a 64-bit GDB. You aren't doing that are you?

[Battler]

Here it is:

Code: Select all

OBattler@WIN-SB6JU9US3LM /i/ba_tools/pcem_201410
$ gdb PCem_D.exe
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from i:\ba_tools\pcem_201410\PCem_D.exe...done.
(gdb) run
Starting program: i:\ba_tools\pcem_201410/PCem_D.exe
[New Thread 1344.0xc5c]
[New Thread 1344.0x6c4]
gdb: unknown target exception 0x670debc0 at 0x770efcd0
During startup program exited with code 0x670debc0.
(gdb) exit
Undefined command: "exit".  Try "help".
(gdb) gdb32
Undefined command: "gdb32".  Try "help".
(gdb) mingw-get install gdb32
Undefined command: "mingw-get".  Try "help".
(gdb)

Edit: Yes, the folder name says October 2014, but the PCem executable is from the latest code. :p

[SarahWalker]

Maybe a DLL issue? Make sure that any directories containing required DLLs (eg MingW's bin and lib directories) are in the PATH. Also check you can run it okay from the command line...

[Battler]

The correct .DLL's are in the folder, and it's the folder from which I normally run PCem. I als ran the .exe from the command line, and it ran fine.

[Battler]

I just narrowed down the cause of the crash to somewhere in here:

Code: Select all

                x86seg *target_seg = FETCH_EA(op_ea_seg, fetchdat, op_ssegs, &op_pc, op_32);
                uint32_t imm = fastreadb(cs + op_pc + 1);
                int host_reg = LOAD_REG_IMM(imm);

                STORE_IMM_ADDR_L((uintptr_t)&oldpc, op_old_pc);
                CHECK_SEG_WRITE(target_seg);

                MEM_STORE_ADDR_EA_B(target_seg, host_reg);
                RELEASE_REG(host_reg);

Or:

Code: Select all

return op_pc + 2;

Because I just added a return 0; to the beginning of the block after else, and the crash went away.
I'm afraid I'll have to somehow make PCem run through GDB in order to narrow it down further.

[Battler]

OK, it seems ropMOV_b_imm, ropMOV_w_imm, and ropMOV_l_imm all have problems, and I think it's in the returned PC. From what I see, these are opcodes C6 and C7, for which the instruction length varies based on what the second byte is. C6 00 is followed by only 1 byte, but C6 04 and C6 85, for example, are followed by many more bytes.

Example of the C6 instructions:
- C6 00 62 which is MOVB $0x62,(%EAX);
- C6 85 2C FF FF FF 00 which is MOVB $0x0,-0xD4(%EBP).

In Intel syntax:
- C6 00 62 which is mov byte ptr[eax],62h;
- C6 85 2C FF FF FF 00 which is mov byte ptr [ebp-0d4h],0.

Edit: A bad memory corruption occurs. I just did a test program for DOS, which has C6 00 62 followed by C6 85 2C FF FF , after the first instruction, C6 85 2C FF FF becomes B6 85 2B EE EE ! This is definitely not right.

Edit #2: Nevermind, for some reason DEBUG is seeing completely wrong instructions! B8 4C 00 (mov ax,4C00h) becomes A8 4B 00, and CD 21 (int 21h) becomes BC 21. What the heck is going on?!

Edit #3: Note that this "corruption" only affects the displayed bytes, what is actually in memory is OK, and Debug executes the instructions correctly. I disabled every single recompiled instruction now, and it still does it, so I think it's because of the carry flag revision.

Edit #4: I just tested both the C6, C7, and 66 C7 instructions with DOS DEBUG and a .COM file I made, and they seem to work as they should. Though that's in real mode, I need to somehow test them in protected mode too.

Edit #5: Just tested 67 C6 in real mode, which makes it use long addresses, still works as it should.

Edit #6: At this rate, I suspect the crash is actually related to the carry bug. Maybe the carry bug causes a register to get an incorrect value at some point, then that instruction gets executed, which ends up reading at some spurious address, crashing the emulator. Maybe the interpreting version of the instruction is simply stable enough that the problem does not show with it. An interesting thing would be to test Windows 2000 on the latest revision of PCem with the carry-related revision (196) removed, to see if the emulator still crashes.

[SarahWalker]

OK, it seems ropMOV_b_imm, ropMOV_w_imm, and ropMOV_l_imm all have problems, and I think it's in the returned PC. From what I see, these are opcodes C6 and C7, for which the instruction length varies based on what the second byte is. C6 00 is followed by only 1 byte, but C6 04 and C6 85, for example, are followed by many more bytes.

Look at FETCH_EA(). The second byte is a MOD R/M byte, and FETCH_EA_16/32() will compensate for any additional address bytes by modifying op_pc (which is why it's passed as a pointer). The return address from the function only has to compensate for the constant offset - the length of the immediate, and the MOD R/M byte itself.

Edit #6: At this rate, I suspect the crash is actually related to the carry bug. Maybe the carry bug causes a register to get an incorrect value at some point, then that instruction gets executed, which ends up reading at some spurious address, crashing the emulator. Maybe the interpreting version of the instruction is simply stable enough that the problem does not show with it. An interesting thing would be to test Windows 2000 on the latest revision of PCem with the carry-related revision (196) removed, to see if the emulator still crashes.

That would probably be the most logical next step, aside from trying to figure out why GDB doesn't work (which I'm convinced is a problem with your setup).

[Battler]

I found what exactly the carry bug is about - the INC and DEC instructions do not set the carry flag even when they should.

Edit: That also happened before the carry flag revision. So the bug is elsewhere.

Edit #2: At this point, what's going on is a complete mystery. Here's what is knowing:
- It might or might not be carry-related, but instructions affecting or using that flag work correctly;
- It affects recompiler and interpreter alike;
- It might or might not be be responsible for recompiler causing the entire emulator to crash under certain circumstances yet to be defined.