Keyboard+mouse freeze on logon screen

Hello.
This seems to be a pretty common problem. I've tried whatever few suggestions I found (unsuccessfully)and I'd appreciate some pointers.
The system is Windows 7 SP1 Ultimate x64. It runs on an oldish laptop that only has USB connectors (no PS/2). At the moment I don't have access to another computer (except an XP x86 installation in another partition) and I even have a broken CD player (just reads :) ). It makes it a bit hard to debug the problem.
Up to now everything was running fine until last night when there was a power failure.
After his point, Windows starts up normally up to the logon screen at which point the disk keeps going for a bit but the keyboard/pad/wireless mouse are dead. Nothing lights up no matter what I press.
Under BIOS, or under XP, or when booting with an old recovery CD I still had around, keyboard and mouse work just fine. So it's not a hardware problem but rather some corrupted driver (?).
Resetting BIOS to defaults, legacy USB etc, battery out, or whatever else I read, makes no difference.

Under XP, I tried removing the UpperFilters/LowerFilters of the keyboard and mouse GUID, but that also made no difference.
Bootlog shows nothing interesting, previous configuration makes no difference (but see below), no restore points available.

The only thing during those registry adjustments that struck me as very strange, was the ComputerName under \ControlSet00x\Control branch.
In the dead system's SYSTEM file, all the ControlSet00x branches were referring to an old name I used to use, say NAME1, under XP. I use a new name (NAME2) for a year now.
The SYSTEM.bak file though of a month ago, was referring in all its ControlSet00x branches to the new name (NAME2), I use under Win7. I don't remember if I had ever used NAME1 in Win7 but I might have.

1) How could Windows mix up those branches? I just can't think of a scenario that allows this.
2) I will rename the SYSTEM.bak to SYSTEM next and try but I don't know if something else has to be switched to. Has anybody ever tried this and lived to tell the tale? :)
3) I'm open to other ideas too.

Thanks.

Some more information that points to a possible Windows bug.

Besides SYSTEM and SYSTEM.BAK, I checked the corresponding SOFTWARE, SAM, SECURITY and DEFAULT files.
The *.BAK ones were much larger so I loaded them up as hives to check them out.

The information in the *.BAK ones, matches the software etc, I have on the crashed Win7 system.
The non-*.BAK ones, match the information on the XP system (that's on its own partition)!!

What I believe happened, is something really buggy with Windows when it tried to handle the crash.
The XP partition was installed first, many years ago, and was put on drive C:
The Win7 one was done a few years after that and was put on drive F: (on a second physical disk).
Win7 crashes on F: and Windows for some reason defaulted to pick up SYSTEM and the other files from drive C:

If it actually happened so, it sounds ugly.
As for my problem, it looks like I'll have to backup the pairs of those files and then remove the *.BAK suffix and see what happens. After I get some coffee in me...

I'm back to (almost) normal as of a couple hours ago.

The use of the *.BAK files instead of the corrupted active files, restored the system and most everything works fine.
By using that month old backup (SOFTWARE.BAK), I've lost the registration of 3-4 programs I had installed so I'll have to reinstall or repair them. Also the SYSTEM environment variables (but not the USER ones) were set to a month ago, but that's easy to fix.

So far so good.

Keep an eye on those files, especially if you have multiple Windows installations. If you see too much of a difference in size between the active file and its *.BAK, try and check it out in case you end up with the same problem.

Cheers.

Do you know and understand how REGISTRY works.
Out of the 5 HKEY but actually only 3 HKEY are saved.
The other 2 are auto-created from the 3 HKEY when you run registry.

Next time when you do something to Registry, Export it to flash drive, first
and do take note on your changes.
Beware as registry is active, and one wrong move, the whole system could failed.

Have you try to remove and then re-insert in.
Windows will auto create a generic driver.

How USB work.
Let say, your computer have 3 USB ports.
1. Let say, you want to connect the external hard disk, to an USB port-2. Windows create a driver.
2. Next time when you connect the same external hard disk, do connect to USB port-2.
3. But if you connect the same external hard disk to USB port-3, Windows will create driver.
4. This is how Windows USB work and if you use the same port, then windows will not create the driver, as the port had already was connect with driver had been created.

So when connect, try another USB port, in order to create the driver for the device.

I wonder what caused the impression that I don't know about the registry and how USB systems work :)

Your advice is good for the simple cases but here Windows got all mixed up. Still, the way I did it, should be a last resort and only for people who know their way around this mess.

I took backups of all the registry files of course (none of them was active since I worked on it from another running Windows), removing/reinserting/changing ports were all tried and proven useless in this case (even the builtin keyboard and pad didn't work).
Somebody could wear the USB ports down retrying them and good luck to them when they have a Windows 7 x64 system trying to boot up using XP x86 hives.