Windows 7: Dump files not created for boot crash

Hi. Okay, my reasons for needing to get a crash dump may seem kind of funny... but, anyway here's what's going on. I'm trying to patch Windows 7 to work on a Pentium 1 MMX. Now that you're laughing, no my main computer is an 8 core FX-8150.

I just want to see this happen, because it would be interesting to see how it runs. Anyway, I have an old socket 7 motherboard that is late-model so it has ACPI support. Windows 7 runs fine on it when I have an AMD K6 installed. The K6's instruction set is identical to the Pentium 1 MMX, being 5x86 + MMX support.

However, when swapping the CPU out with a P1 MMX Windows 7.. it crashes during the boot phase shortly after showing the Windows logo on the "Starting Windows" screen. There is a STOP 0x5C blue screen. 0x5C code means HAL init failed.

Considering that the CPU instruction sets are totally identical, I am led to believe that this is an artificially generated error because MS just doesn't want it to run on a CPU as old as the Pentium 1 MMX.

Anyway, I have it all set up to create dump files on a blue screen and I'm using the "bootdebug" option when it starts. It just doesn't create any dumpfiles though. It also doesn't create ntbtlog.txt if I tell it to, or when trying safe mode.



I need the dump files so I can figure out what part of the HAL init fails with WinDbg, so that I can analyze the HAL library in IDA pro and patch the code to skip the (what I think is) artificial error generation.

Does anybody know why it may possibly not be creating a dump? Maybe I could figure it out without these dumps, but man that would make this take so much less time. Or if anybody knows for sure that it's not an artificial error, please let me know so I am not completely wasting my time.

Thanks.

Here's my DRAFT page on BSOD generation: BSOD Crash Dump Generation
It's a draft because I'm pretty sure there's some missing info, but I can't seem to locate it.

As such, I'm going to try attaching a live debugger (with another system) to the machine.
And, I'd expect that that is what you'll need to do also.

From what I've seen, there is no 'secret' block for Pentiums in place. I suspect the HAL spit out the error because the hardware changed - which is what it's supposed to do. Have you tried to install it with the Intel CPU already mounted? If so, what do the error logs look like?

Yes the exact same BSOD happens when I boot the install DVD with the Pentium installed. It has the same bugcheck parameters too. I think I have actually found what part of the HAL library is causing it, based on the first parameter after 0x5C. (which is 0x10B)

I found this code in the disassembly:

Hex editing that JGE instruction to a JMP might just take care of the problem. This code is called after another section that does a comparison of the value returned in EAX by a call to HalGetProcessorIdByNtNumber. So, I think I might be right about it being an artificial error.

Also, I've actually changed CPUs on already-installed Windows 7 systems several times in the past without any HAL problems.

I'm going to ask a friend to have a look at this. He's very busy, but if he can check in it'll be much more helpful than my inept fumblings.

Yes, there are artificial restrictions set into the HAL as safety mechanisms to catch hardware that may be incompatible with the OS, because it sure beats the system trapping unexpectedly due to an incompatible instruction set or some other legacy restriction and having the victim scratching their head over the conundrum.

I highly, completely doubt the legitimacy that the HAL is open to any sort of patching by end users. While I would venture to guess that OCers and all those people that love pressuring systems to their limits enjoy dabbling in this kind of stuff for kicks, and while it's really a harmless attempt, it still is disassembling and reverse engineering the HAL, which is part of the undocumented and restricted code of the Windows OS. We can go into a debate about "blah blah I bought it I have rights blah blah entitlement blah blah" but the reality is there's a EULA to uphold too, which goes against this for whatever reason. If you really want to do this kinda stuff without the guilt of doing something illegally, get an MSDN account and get access to the old Windows source code and have fun, or wait until Windows 7 source code is released to the public through MSDN before tampering with it.

The only way I can see this even being close to legitimately approached is to noninvasively feed a false proc ID to the HAL. Again, even that attempt is pretty iffy (if it even works).

Oh, and the only reason why different CPUs work after installation is that the Windows kernel will resort to whatever necessary executable to run it, be it ntkrnlmp.exe, ntoskrnl.exe, or ntkrnlpa.exe. That's only because it's already performed the proc ID check to verify it's a supported CPU.

I am aware of the reasons that they would do it, and they are valid. It's strange that they allow the K6 to work which has the same instruction set as the P1 MMX though. (As opposed to the K6-2, which is 5x86+MMX+3Dnow) In the end though, they're both ancient so I don't really expect them to put the effort into it.


I'm not worried about the legality in any way, so I'm not even going to argue. I will just say that I don't plan to distribute this to anybody, so it's pretty much a moot point but I understand it is technically against the EULA.


Yes, I know. I was just clarifying because usasma suggested the HAL will cause a bugcheck exception upon the CPU being swapped out.

Sorry but we cant support anything in violation of the EULA.

Thread closed.