OA4/WIN7 The NTVDM CPU has encountered an illegal instruction.

leecher · 08.05.2024, 18:07

Regarding your question about the safe mode video driver: It should be the same as the fallback driver that gets activated when disabling video output, so the observation with safe mode is quite interesting. I don't really have an explanation for it.

To further diagnose the issues, you may want to debug your video BIOS to find potentially problematic code.
For that I first recommend to dump the video BIOS to have a copy of it for urther research.
I did my debugging with the enhanced DEBUGX from Freedos (for just dumping, the normal debug.com that ships with Windows is also enough):

Code:

-r cs
CS 15EF
:c000
-r cx
CX 0000
:ffff
-n video.bin
-w 0
0FFFF Bytes werden geschrieben.
-q

Afterwards, you may want to debug the mode switch to mode 13h with debugx.
First, let's get the BIOS entry point for mode switch:

Code:

-a
17A2:0100 mov ax,3516
17A2:0103 int 21
17A2:0105
-p
DPMI entry hooked, new entry=10C0:0128
AX=3516 BX=0000 CX=0000 DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000
DS=17A2 ES=17A2 SS=17A2 CS=17A2 IP=0103 NV UP EI NG NZ NA PO NC
17A2:0103 CD21              INT     21
-p
AX=3516 BX=09C4 CX=0000 DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000
DS=17A2 ES=0214 SS=17A2 CS=17A2 IP=0105 NV UP EI NG NZ NA PO NC
17A2:0105 0000              ADD     [BX+SI],AL                       DS:09C4=00

Now depending on your Windows version, you need to dump the appropriate address. I'm currently on Windows XP, so I have es:950, but on Windows 7, you need ES:969 !
Here for illustration purposes, I show mine on XP, you should issue a "d es:969" instead!

Code:

-d es:950
0214:0950  EA C9 17 00 C0 56 57 55-BA 46 00 52 0E BB 6C 09 .....VWU.F.R..l.
0214:0960  53 BB 07 00 B4 0E 26 8A-05 47 EB E4 E2 EA 5D 5F S.....&..G....]_
0214:0970  5E B8 01 00 EB 9F 2E 80-3E A7 08 02 75 05 E8 85 ^.......>...u...
0214:0980  FE 72 F1 2E 80 3E A7 08-01 74 06 C4 C4 10 E9 BB .r...>...t......
0214:0990  FC 80 FC 13 75 04 3C FF-74 BB EA 65 F0 00 F0 CD ....u.<.t..e....
0214:09A0  10 C4 C4 FE C4 C4 11 E9-A2 FC C4 C4 12 E9 9C FC ................
0214:09B0  C4 C4 14 E9 96 FC 87 DB-00 00 00 00 18 00 00 00 ................
0214:09C0  32 00 00 00 1E 53 BB 40-00 8E DB 80 FC 10 E8 E8 2....S.@........

As can be seen, there is a JMP (EA) followed by a segment : offset address, (C000:17C9 in my example).Now we know the entry point in video bios, take note of this address!

Now try a mode switch to mode 13h and trace it:

Code:

-a
17A2:0105 mov ax,13
17A2:0108
-p
AX=0013 BX=09C4 CX=0000 DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000
DS=17A2 ES=0214 SS=17A2 CS=17A2 IP=0108 NV UP EI NG NZ NA PO NC
17A2:0108 0000              ADD     [BX+SI],AL                       DS:09C4=00
-t =C000:17C9 
AX=0013 BX=09C4 CX=0000 DX=0000 SP=FFFC BP=0000 SI=0000 DI=0000
DS=17A2 ES=0214 SS=17A2 CS=C000 IP=17CA NV UP EI NG NZ NA PO NC
C000:17CA 50                PUSH    AX

Continue tracing with just pressing return or use t <Number of instructions>
to trace multiple instructions at once (Makes sense, as video BIOS
normally is huge and you may need to isolate the point where it possibly
fails or at least see where it tries to write to).
i.e.: t 1000

Maybe you can spot the issue by tracing the call. I still think, it may be a port access issue, but as you already patched the VIDEOPRT driver in the same manner as I would have done it (correcting redirected exports) and it still doesn't pass through the ports, you may need to check with windbg kernel debugger if it gets called properly and unlocks the correct ports.
What you can do is verify the "AllocConfig" key in registry (enum HKEY_LOCAL_MACHINE/CurrentControlSet/Enum/PCI and check for device with Class=Display and a "Control" subkey where there is the AllocConfig key which can be clicked on and then it displays the port ranges.
Verify that this key is present and maybe verify with kernel debugger that patched videprt.sys really exposes all these ports).

08.05.2024, 18:07	#25
leecher Moderator	Regarding your question about the safe mode video driver: It should be the same as the fallback driver that gets activated when disabling video output, so the observation with safe mode is quite interesting. I don't really have an explanation for it. To further diagnose the issues, you may want to debug your video BIOS to find potentially problematic code. For that I first recommend to dump the video BIOS to have a copy of it for urther research. I did my debugging with the enhanced DEBUGX from Freedos (for just dumping, the normal debug.com that ships with Windows is also enough): Code: -r cs CS 15EF :c000 -r cx CX 0000 :ffff -n video.bin -w 0 0FFFF Bytes werden geschrieben. -q Afterwards, you may want to debug the mode switch to mode 13h with debugx. First, let's get the BIOS entry point for mode switch: Code: -a 17A2:0100 mov ax,3516 17A2:0103 int 21 17A2:0105 -p DPMI entry hooked, new entry=10C0:0128 AX=3516 BX=0000 CX=0000 DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000 DS=17A2 ES=17A2 SS=17A2 CS=17A2 IP=0103 NV UP EI NG NZ NA PO NC 17A2:0103 CD21 INT 21 -p AX=3516 BX=09C4 CX=0000 DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000 DS=17A2 ES=0214 SS=17A2 CS=17A2 IP=0105 NV UP EI NG NZ NA PO NC 17A2:0105 0000 ADD [BX+SI],AL DS:09C4=00 Now depending on your Windows version, you need to dump the appropriate address. I'm currently on Windows XP, so I have es:950, but on Windows 7, you need ES:969 ! Here for illustration purposes, I show mine on XP, you should issue a "d es:969" instead! Code: -d es:950 0214:0950 EA C9 17 00 C0 56 57 55-BA 46 00 52 0E BB 6C 09 .....VWU.F.R..l. 0214:0960 53 BB 07 00 B4 0E 26 8A-05 47 EB E4 E2 EA 5D 5F S.....&..G....]_ 0214:0970 5E B8 01 00 EB 9F 2E 80-3E A7 08 02 75 05 E8 85 ^.......>...u... 0214:0980 FE 72 F1 2E 80 3E A7 08-01 74 06 C4 C4 10 E9 BB .r...>...t...... 0214:0990 FC 80 FC 13 75 04 3C FF-74 BB EA 65 F0 00 F0 CD ....u.<.t..e.... 0214:09A0 10 C4 C4 FE C4 C4 11 E9-A2 FC C4 C4 12 E9 9C FC ................ 0214:09B0 C4 C4 14 E9 96 FC 87 DB-00 00 00 00 18 00 00 00 ................ 0214:09C0 32 00 00 00 1E 53 BB 40-00 8E DB 80 FC 10 E8 E8 2....S.@........ As can be seen, there is a JMP (EA) followed by a segment : offset address, (C000:17C9 in my example).Now we know the entry point in video bios, take note of this address! Now try a mode switch to mode 13h and trace it: Code: -a 17A2:0105 mov ax,13 17A2:0108 -p AX=0013 BX=09C4 CX=0000 DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000 DS=17A2 ES=0214 SS=17A2 CS=17A2 IP=0108 NV UP EI NG NZ NA PO NC 17A2:0108 0000 ADD [BX+SI],AL DS:09C4=00 -t =C000:17C9 AX=0013 BX=09C4 CX=0000 DX=0000 SP=FFFC BP=0000 SI=0000 DI=0000 DS=17A2 ES=0214 SS=17A2 CS=C000 IP=17CA NV UP EI NG NZ NA PO NC C000:17CA 50 PUSH AX Continue tracing with just pressing return or use t <Number of instructions> to trace multiple instructions at once (Makes sense, as video BIOS normally is huge and you may need to isolate the point where it possibly fails or at least see where it tries to write to). i.e.: t 1000 Maybe you can spot the issue by tracing the call. I still think, it may be a port access issue, but as you already patched the VIDEOPRT driver in the same manner as I would have done it (correcting redirected exports) and it still doesn't pass through the ports, you may need to check with windbg kernel debugger if it gets called properly and unlocks the correct ports. What you can do is verify the "AllocConfig" key in registry (enum HKEY_LOCAL_MACHINE/CurrentControlSet/Enum/PCI and check for device with Class=Display and a "Control" subkey where there is the AllocConfig key which can be clicked on and then it displays the port ranges. Verify that this key is present and maybe verify with kernel debugger that patched videprt.sys really exposes all these ports).