:`( These screenshot are identical, but adresses is different: and BSOD and BSOD (sorry, i forget to swith off flashlight) and OK
Sorry to bother you. Would you please redo a screenshot without flashlight (BSOD). At the third shot it seems the relocation of DSDT is not executed and hence no BSOD. Thanks again.
Ok we need to do process of elimination so I will make a set of different versions that do one thing only like PatchOEM then exit. another version Relocate DSDT then exit. another simply Compute checksum then exit. Hopefully we can see if BSOD caused by different OEMs or relocation is to blame. In third screenshot it could not find the free space anymore. Its like the Ram is not cleared at restart. edit: Oh and it searches total of 1,048,576 (1mb) bytes from startaddress where RSDT is at. It looks in reverse for the free space. It remembers where free space was found the first time so next time it uses that address, this is to avoid placing SLIC inside DSDT table.
hi I install Wow 6.0 and do two command in cmd like it says it text in first page. But my HPCompaq 6820s still isn't activated. Here are two files: *.ats Yen, What to do? what is wrong ?? Thanx !!
It seems WoW wasn't executed, but IMO it should work. Have you rebooted after the installation of it? Are you using multiboot OS? To where have you installed WoW? C:\ ? Where is the hidden systemfile bootmgr located? C:\?
Sorry, I have no free time. Later I do some tests. For numbers 9-4 there is no BSOD. (But if it random...) 9: 6: 4: 1. 9 -> OK -> Shutdown 2. Bootmgr -> Shutdown 3. 8 -> OK -> Shutdown 4. Bootmgr -> Shutdown 5. 7 -> OK -> Shutdown 6. Bootmgr -> Shutdown 7. 6 -> OK -> Shutdown 8. Bootmgr -> Shutdown 9. 5 -> OK -> Shutdown 10. Bootmgr -> Shutdown 11. 4 -> OK -> Shutdown I will try WoW5 instead bootmg (for more stable BSOD )
Thanks again, Eugene Nuke Hmm, seems there is sometimes not enough free space in front of RSDT---> no BSOD. And if found---> relocate DSDT--->BSOD. I'm afraid of relocating DSDT may cause BSOD every time, since it's 'used' already or used just right now........ Flagmax, what do you think? If this should be true, a delay could help, but not if it's too late already.....let's be optimistic.
Eugene Nuke: Thank you, I really apreciate your work. Just to confirm, turn PC off completely, boot from CD, type 9, enter. Look for FreeSpaceCheck result, If it says *** Success ***, it will then Copy DSDT to free space and will say *** Success ***. After this you seem to get BSOD. If you want to test more, just do command 9, or 8. They both Copy DSDT. If the problem is random, I don't know how to solve it. Commands 7 to 1 should NEVER give BSOD. Yen: Yes, that time it failed to find free space. So it did not relocate. But why? In other tests, sometimes it finds the space, sometimes not. What could it be that is writing to that area on fresh boot? I don't know anything about DSDT table other than its very large This is a laptop so perhaps as long as the battery is charged, RAM stays powered up even if the PC is turned off? Or could the BIOS be using some of that space for power management and it corrupts the DSDT table? I could make a program that when run, just compares original to relocated table, but first we need to know why that area is not free every boot. Another question I have is, does OS protect ACPI tables only after RSDT or anywhere in RAM as long as its linked. This is a very weird problem Attached is a shot from 9 from my VMWARE. edit: Oh just noticed that if it fails to find freespace, it will exit and does not recalculate Checksum of FADT. This should not cause BSOD but will cause FADT not showing in ACPISCOPE because of bad checksum.
Yes, I rebooted it. I dont use multiboot OS. I have only Windows Vista Ultimate with SP1. I Installed on C:/ and system file bootmgr is in C:/ , too. Hm...
OK, have now tools here. The FADT is too short here, it contains no 64 bit address entry to DSDT, so it cannot be a problem. Well I think the code in front of RSDT is there before WoW tries to find free space in front of RSDT---> no relocation of DSDT. Or: Probably the same code overwrites a few moments after the relocated DSDT--->BSOD.... Solution: Try to find free space somewhere else.......think it's bios specific and a 'bad' bios ?
What bothers me is sometimes it finds the free space and relocates. But one thing I noticed when it relocated, the 8 bytes in front of RSDT are still zeros and not what it seen in his ACPI reports. We should try to get a memory dump using WOW but he would need to use a floppy or USB for that. Once Vista starts the area is not the same.
The 8 zero bytes in front of the RSDT belong to the FADT which is right in front of the RSDT (together 19 zerobytes) RSDT: 3FFF0C84h FADT: 3FFF0C00h Search before 3FFF0C00h..... Another thing. Tables like FACS are sometimes 'empty' (consists of zero bytes) How does your search for free space routine work exactly?
to YEN YEN: Thanx MAN, the Wow 6.0 works for me. Vista SP1 is finally activated. One more question now: Is Vista now activated permanently? Do i need boot vista from Wow CD everytime? Can I download Windows updates? Thanx again.