Windows 95 build 224

Build 224 was the first known Beta 2 build of Windows 95 (Chicago). It can be found in both free and check/debug versions.

However, the Check/Debug version of the build is not usable and denies to boot into Windows GUI. And the reason might be figured by looking into files that comes in /SDK/DEBUG directory of the build's SDK. Yes, it's missing its USER32.DLL, which was the reason of the build being unusable and non-bootable.

Some people tried troubleshooting it, and discovered that it's doing something wrong in its memory management (VMM). But some tester has worked further with the build by kernel-debugging it for full control toward the build's behaviour, and discovered it's something to do with communication between USER32.DLL and USER.EXE, which we're going to discuss it.

What was the problem?
Before getting into the reason of the problem, let's first get some more information about both free USER.EXE and Check/Debug USER.EXE, since the Blue Screen Of Death (BSOD)'s error was occuring in USER.EXE's memory range.

It's worth saying that the debug files can operate and the system can boot without overwriting the free USER.EXE with Check/Debug one. But we're not going to get any statement mentioning that the build is (Debug), nor we'll see watermark which says "Debug Windows 4.00.224" at right-bottom side of the screen, since these strings are located in USER.EXE itself.

So, by measuring alot of activity happening in the system during booting using the checked/debug USER.EXE by attaching terminal to WDEB386, and tracing where it might be faulting in, we ended into the following code in USER32.DLL: 013F:BFF64320 MOV    EAX,DWORD PTR [BFF6614E] 013F:BFF64325 MOV     AX,WORD PTR [EAX+0000024E] 013F:BFF6432C SUB     AX,0EAA 013F:BFF64330 CMP     AX,0001 013F:BFF64334 SBB     EAX,EAX 013F:BFF64336 NEG     EAX 013F:BFF64338 RETD

Looking at the code in kernel-debugger, the area where it gets information from (i.e. address stored in DS:BFF6614E + 0x24E to it) was figured to be from a text: "Status = .Terminate =", and then substracting 0xEAA from it and negation? looks like it's where the issue is located, since before it returns, AX is 00000000. When we set it to 1 manually (r ax=1) and continuing booting the build, it showed the GUI.

But we still have encountered a Trap14 (0x0E). This time it was due to invalid address: Trap 14 (0EH) - Page Fault 0004, Not Present, Read Access, User Mode AX&#61;91EFA600 BX&#61;0066FA96 CX&#61;815E173C  DX&#61;00040990  SI&#61;00540494  DI&#61;0066FBA0 IP&#61;BFF6467E SP&#61;0066F7B8  BP&#61;0066FA18  CR2&#61;91EFA646  CR3&#61;003EE  IOPL&#61;0  F&#61;-- -- CS&#61;013F SS&#61;0147  DS&#61;0147  ES&#61;0147  FS&#61;1CBF  GS&#61;1B57 -- NV UP EI NG NZ NA PE NC 013F:BFF6467E  MOVZX   EAX,WORD PTR [EAX+46]                DS:91EFA646&#61;INVALID

Looking back into code that was prior to this line, we saw this: 013F:BFF6468D MOV    EAX,DWORD PTR [BFF6614E] So now we knew that this address (BFF6614E) has something important to do with the issue, if it's not even the cause.

This address was later recognized to be the Shared Table address of USER32.DLL, and its pointer is to code segment 21 in USER.EXE, so now we need to do comparison between the two USER.EXEs.

Thanks to Watcom Binary files dumper (wdump.exe) for its detailed report about USER.EXE. We've got the following information about this specific segment:
 * Segment 21h in free USER.EXE starts at offset 0x67440 in the file, and has a size of 0x452 and allocation of 0xEAA.
 * Segment 21h in check/debug USER.EXE starts at offset 0x7E080 in the file, and has a size of 0x992 and allocation of 0x13EA.

By the help also of HxD, we copy/pasted segments from the files and compared them, and we discovered that the beginning of reserved area for data in the segment itself in free USER.EXE starts at 0xAD, while at check/debug one is 0x37B. So now we have the following two clues:
 * The difference between allocations of free USER.EXE and check/debug is 0x13EA - 0xEAA = 0x540.
 * The difference between data locations between the two USER.EXEs is 0x37B - 0xAD = 0x2CE.

Now, by looking into the code, we can imagine the following: If all pointers between 0xAD and 0x452 in free USER.EXE should point to a location in the spare area in the segment, and between 0x452 and 0xEAA should point in the additional allocation by the operating system outside the segment's data, then in Check/debug USER.EXE should has its corresponding locations.

It's IDA time now. We loaded USER32.DLL into IDA and searched for all codes that have BFF6614E into it, and we got around 20 results. What we're going to do now is the following:

MOV reg, DWORD PTR [BFF6614E] ADD reg, offset Or MOV reg1, DWORD PTR [BFF6614E] MOV reg2, (D)WORD PTR [reg1+offset]
 * We look for any code with this layout:


 * Now we look into 'offset' value. If it was between 0xAD and 0x452 we need to add 0x2CE to it. If it was between 0x452 and 0xEAA we should add 0x540 to it, and if it's beyond 0xEAA (e.g. 0x10000 was one of our results) then this should left unchanged since it now points to another segment, which might be correct.


 * By using HxD to edit manually most of the results that can satisfy our needs, the build booted up completely without any issue. And functioning properly in all its ways.