Dump files not created for boot crash


  1. Posts : 3
    Windows 7 Ultimate 32-bit
       #1

    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.
      My Computer


  2. Posts : 5,705
    Win7 x64 + x86
       #2

    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?
      My Computer


  3. Posts : 3
    Windows 7 Ultimate 32-bit
    Thread Starter
       #3

    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:

    Code:
    .text:8001C896 ; =============== S U B R O U T I N E =======================================
    .text:8001C896
    .text:8001C896
    .text:8001C896 sub_8001C896    proc near               ; CODE XREF: sub_8003124E+7Cp
    .text:8001C896                                         ; sub_800333F0+15p
    .text:8001C896
    .text:8001C896 ; FUNCTION CHUNK AT .text:80018D28 SIZE 0000001A BYTES
    .text:8001C896
    .text:8001C896                 cmp     BugCheckParameter2, 3
    .text:8001C89D                 jnz     short locret_8001C8CD
    .text:8001C89F                 cmp     byte_8002CAF5, 0
    .text:8001C8A6                 jz      short loc_8001C8C8
    .text:8001C8A8                 call    sub_8001C474
    .text:8001C8AD                 test    eax, eax
    .text:8001C8AF                 jge     short loc_8001C8C8
    .text:8001C8B1                 push    2               ; BugCheckParameter4
    .text:8001C8B3                 push    0               ; BugCheckParameter3
    .text:8001C8B5                 push    BugCheckParameter2 ; BugCheckParameter2
    .text:8001C8BB                 push    10Bh            ; BugCheckParameter1
    .text:8001C8C0                 push    5Ch             ; BugCheckCode
    .text:8001C8C2                 call    ds:KeBugCheckEx
    .text:8001C8C8
    .text:8001C8C8 loc_8001C8C8:                           ; CODE XREF: sub_8001C896+10j
    .text:8001C8C8                                         ; sub_8001C896+19j
    .text:8001C8C8                 jmp     loc_80018D28
    .text:8001C8CD ; ---------------------------------------------------------------------------
    .text:8001C8CD
    .text:8001C8CD locret_8001C8CD:                        ; CODE XREF: sub_8001C896+7j
    .text:8001C8CD                 retn
    .text:8001C8CD sub_8001C896    endp
    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.
      My Computer


  4. Posts : 5,705
    Win7 x64 + x86
       #4

    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.
      My Computer


  5. Posts : 1,314
    Windows 7 64-bit
       #5

    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.
      My Computer


  6. Posts : 3
    Windows 7 Ultimate 32-bit
    Thread Starter
       #6

    Vir Gnarus said:
    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 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 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).
    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.


    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.
    Yes, I know. I was just clarifying because usasma suggested the HAL will cause a bugcheck exception upon the CPU being swapped out.
      My Computer


  7. Posts : 51,383
    Windows 11 Workstation x64
       #7

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

    Thread closed.
      My Computers


 

  Related Discussions
Our Sites
Site Links
About Us
Windows 7 Forums is an independent web site and has not been authorized, sponsored, or otherwise approved by Microsoft Corporation. "Windows 7" and related materials are trademarks of Microsoft Corp.

© Designer Media Ltd
All times are GMT -5. The time now is 12:22.
Find Us