Windows 95 build 224

Windows 95 build 224 is the official Beta 2 build of Windows 95. It is available in both free and check/debug versions. However, the Check/Debug version of the build is not usable and refuses to boot due to a missing.

In spite of date printed on CDs which were sent to testers, as well as content files' timestamp are set to 1994-10-28, however the  file in   suggests that the build was actually built on 1994-11-03, and thus it is possible that Microsoft decided to intentionally change the timestamps of the media files for an unknown reason.

Checked/Debug version
Before getting into the reason of the problem, let's first get some more information about both free and checked/debug, since the blue screen of death error is occurring in  's memory range.

It is worth saying that all other debug files operate properly and the system can boot with the checked/debug  being replaced with the free/retail one. But we're not going to get any statement mentioning that the build is (Debug), nor we will see a desktop watermark saying "Debug Windows 4.00.224" at the right-bottom side of the screen since these strings are located in  itself.

So, by measuring alot of activity happening in the system during booting using the checked/debug  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 subtracting 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=91EFA600 BX=0066FA96  CX=815E173C  DX=00040990  SI=00540494  DI=0066FBA0 IP=BFF6467E SP=0066F7B8  BP=0066FA18  CR2=91EFA646  CR3=003EE  IOPL=0  F=-- -- CS=013F SS=0147  DS=0147  ES=0147  FS=1CBF  GS=1B57 -- NV UP EI NG NZ NA PE NC 013F:BFF6467E  MOVZX   EAX,WORD PTR [EAX+46]                DS:91EFA646=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 is not even the case.

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

Thanks to Watcom Binary files dumper (wdump.exe) for its detailed report about. We have got the following information about this specific segment:
 * Segment 21h in free  starts at offset 0x67440 in the file and has a size of 0x452 and allocation of 0xEAA.
 * Segment 21h in check/debug  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 the free  starts at 0xAD, while in the check/debug one, it starts at 0x37B. So now we have the following two clues:
 * The difference between allocations of free and checked/debug  is 0x13EA - 0xEAA = 0x540.
 * The difference between data locations between the two s is 0x37B - 0xAD = 0x2CE.

Now, by looking into the code, we can imagine the following: If all pointers between 0xAD and 0x452 in free  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   should has its corresponding locations.

Now we switch over to IDA. We loaded USER32.DLL into it and searched for all codes that have BFF6614E into it, and we got around 20 results. What we are 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 the '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 be 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, this build can be brought to boot and work without any issue.