Problem with WoW and add-in SATA Hello all, Great job on WoW, it's worked great for me more than once, and it's easy to install. I recently had a problem with it though and was wondering if anyone else has had the same issue. The problem is the PC refuses to load with an add in SATA/IDE controller card. Without WoW installed the PC will boot with the card (it's a Promise SATA 300 TX2 Plus), after i install WoW, however, it hangs with a black screen (with a flashing cursor in the top left) right after the BIOS detects the hard drives. The only way to get the PC to load is to remove WoW or the controller card. I can leave the controller card in the PC and it will work, but only if there are no drives plugged into it. This leads me to believe that it must be something to do with the controller cards BIOS. It loads its own BIOS (much like a RAID BIOS) if there are drives plugged into it. My best guess is it must be interfering with the patching WoW is trying to do. Maybe the controller card is loading its BIOS into a memory address WoW is attempting to patch. I don't know enough about what it's doing to make a more accurate guess. Has anyone else had this problem? I haven't seen any other posts with this issue. The same problem exists with VistaLoader as well. If you have any ideas to solve this issue it would be much appreciated, if not, it's still a great tool and keep up the good work on it. Thanks, Jacksonkid
bibo It could happen when you are updating Vista that an update wants to update bootmg. But bootmgr = grldr. This means grldr will be removed at update---> wow doesn't work anymore. But that's no problem at all. It's no disabling of the patch, it's just because of the missing grldr. It that case just reinstall wow again (execute wow6.exe, replace *img, rename the files.) I suggest to you first to install all updates (Sp1 as well), after that WoW6. It will work. Flagmax I'll do more analysis and will compare tables. I still can't get why DSDT is overwritten after relocation. -There must be a difference for the OS between the original location and the relocated. I'll dump and have a closer look again. The FACS table is located in front of RSDT and is the first one. What is the difference of a relocated DSDT and the original one? Phoenix bios doesn't make a difference... If we can find an answer for that, it would be great. Fact is there seems to be a place which isn't applicaple (not valid) I think there is a special condition, like DSDT must not be the first table, or must be after /FADT/RSDT At real bios there is never the DSDT located before RSDT. Will compare a few *.ats reports and will find out what are the same conditions at address ranges and relative positions (order) of the tables. Maybe we can define or notice some similarities. Then after to 'integrate' the conditions into wow. Idea: I don't know what's about the dynamically allocation of the Acpi table addresses. The first table is FACS, DSDT was relocated in front of it. So we have exeeded the address range of the original acpitables. What about to make wow search between the latst physical memory address and the first table only? To calc. the last possible address you have to read the last byte of the entry of e.g. RSDT (3Fh) at RSDP multiply by 100000 plus FFFFFFh Will this be possible for a test? I've got the feeling that anything before 3FFF0000h gets lost.
Motherboard: GA-MA770-DS3 (rev. 1.0) For the sake of interest I have decided to try WoW6. I have installed WoW6 on clean copy of Windows Vista, installed certificates and so on. All seemed to be OK, but when I tried to "put" my PC into slip mode (S3(STR)) the activity of hard drive stopped, but PC did not turn power off. After uninstalling WoW6 and flashing mobo with modded BIOS all started to work again correctly. I am not sure that the problem is connected with WoW6. Maybe it is somehow connected with new Gigabyte BIOS F7h. I don't know... I have not found modded F7h BIOS... I hope it will somehow help you to keep WoW6 working.
Good news for Samsung NC10 users - works perfectly with 04CA BIOS installed. Many thanks to Flagmax & Yen.
Hi all, I had version 5.2 working great, until today after I've done a mass Windows Update, replaced some accessories (mouse keyboard flash drive etc) and also removed a secondary hard drive. Now it just says 15 days left to activate. I've tried reinstalling 5.2, that didn't work. So I then tried 6.0, but it is still the same. I have also tried 6.0 Special version, but that didn't help either. The boot sector definitely is rewritten correctly because I can see the blinking cursor in the centre for a split second. This is Sp1 Ultimate on an Aopen motherboard with unmodified and latest BIOS. I have attached my ACPIScope report done on 6.0. Any ideas? The version 5.2 DID work before. Thanks. Great work by the way guys.
Doesn't work with HP Compaq nc6220 I'm using the v6.0 nombr version. All seems to install okay, but V still says 30 days left to activate. Clean V Ultimate OEM install, no serial entered during setup, then ran steps as per first post (disabled UAC first). That was it.
Im not using RAID. A funny problem has occured after it has worked a couple of times... now when i try to startup my PC the bootup hangs with a cursor flashing in the middle. I used Startup repair after booting from Vista DVD to fix the problem. Now Vista boots but Welcome Centre says 15 days to activate :-( Any ideas?
By using startup repair you have likely removed the custom (patched) bootloader. Re-install wow6 from inside c:\wow6 folder and reboot (ensure the key was slmgr'd in and the cert also). Note that with RAID or not the same bootmgr routine (or grldr) as specified will be used - so it is not a factor unless the RAID controller driver loads to an area of memory occupied by the wow6 HP SLIC after it is loaded. Your RAID controller may have option to load to another area of memory in its driver options at .ini level.
Vistaloader is pretty evil toward your MBR. Don't touch it. Wow6 makes a neat approach to the slic 2.0 byte placement whilst not affecting the MBR. If you can use acronis to military level clear any disks affected by vistaloader. The actions of wow6 are easily reversed by uninstall.cmd unlike vistaloader.
Yen, Read this thread...nice work....Just though I'd pass on some info...there are bios routines that do appear to utilise memory before and after the tables so it make it extremely difficult to find a reliable location to place code into. For instance on GA boards you will find free space at the end of the lowest table address in RSDT. Placing code into this position will run reliably until the bios sleeps....upon waking wake the bios uses these locations and overwrites code thats placed there. I'm not 100% sure your going to be able to be 100% sure that the location of free space will never be used by later routines initiated by the bios. In the case your investigatng one would expect it to be the same for each boot. Since its not however one would expect that this may be because the bios is detecting an external device and executing some other code?? or not detecting as it may be. just a guess.... Nice work by the way...
hi, im trying to do this in my presario laptop cq20-205tu.. just a question.. how do i know that it booted up on WoW using the cd/mem stick? is there a hint that it booted up there and installed the WoW? thanks for ur replies
The visible versions and the boot CD /Floppy should show some fast moving messages before Vista boots and 'windows98....'
It seems there is something wrong with the last entry of RSDT. It points far below to an address where is no SLIC. Would you please post a report without WoW to compare? Thanks. We have to wait till flagmax is back again......
That looks like a bug in my coding when it relocates APIC table then creates slic. The 4 bytes you see at end of RSDT is CIPA which is how "APIC" is stored in a variable. Somehow I got varibles messed up or I derefrenced an address one to many times. I will try to hunt down to bug on Sunday. Happy New Year everyone! edit: Actually, it looks like it relocates APIC ok but fails to create SLIC. The bytes are actual from original APIC table. I will check my code. edit2: Bug has been located. Will release the fix Sunday. Thank you guys.