Problem Installing SP1 - Windows 7 Home Premium 64 bit

Jon, at this point it sounds like the only thing to try

I don't ever recall seeing anything above around the POQ 300 mark - here's the end of your CBS/SFC log....

Code:

POQ 488 ends.
2013-09-26 18:45:50, Info                  CSI    00000d12 [SR] Verify complete
2013-09-26 18:45:50, Info                  CSI    00000d13 [SR] Repairing 1 components
2013-09-26 18:45:50, Info                  CSI    00000d14 [SR] Beginning Verify and Repair transaction
2013-09-26 18:45:51, Info                  CSI    00000d15 Repair results created:
POQ 489 starts:
 
POQ 489 ends.
2013-09-26 18:45:51, Info                  CSI    00000d16 [SR] Repair complete
2013-09-26 18:45:51, Info                  CSI    00000d17 [SR] Committing transaction
2013-09-26 18:45:51, Info                  CSI    00000d18 Creating NT transaction (seq 2), objectname [6]"(null)"
2013-09-26 18:45:51, Info                  CSI    00000d19 Created NT transaction (seq 2) result 0x00000000, handle @0x159c
2013-09-26 18:45:51, Info                  CSI    00000d1a@2013/9/26:17:45:51.076 CSI perf trace:
CSIPERF:TXCOMMIT;7
2013-09-26 18:45:51, Info                  CSI    00000d1b [SR] Verify and Repair Transaction completed. All files and registry keys listed in this transaction  have been successfully repaired

Please run another SFC SCANNOW, and post the new log - It should be fascinating!

That finished on a much more reasonable note :)

Code:

POQ 144 ends.
2013-09-26 20:43:30, Info                  CSI    000003a1 [SR] Verify complete
2013-09-26 20:43:30, Info                  CSI    000003a2 [SR] Verifying 94 (0x000000000000005e) components
2013-09-26 20:43:30, Info                  CSI    000003a3 [SR] Beginning Verify and Repair transaction
2013-09-26 20:43:32, Info                  CSI    000003a4 Repair results created:
POQ 145 starts:
 
POQ 145 ends.
2013-09-26 20:43:32, Info                  CSI    000003a5 [SR] Verify complete
2013-09-26 20:43:32, Info                  CSI    000003a6 [SR] Repairing 0 components
2013-09-26 20:43:32, Info                  CSI    000003a7 [SR] Beginning Verify and Repair transaction
2013-09-26 20:43:32, Info                  CSI    000003a8 Repair results created:
POQ 146 starts:
 
POQ 146 ends.
2013-09-26 20:43:32, Info                  CSI    000003a9 [SR] Repair complete

I think the POQ can roughly be translated as 'Packet of Queries' - SFC checks files in batches of 100 and works on them before proceeding to the next batch. Each batch is given a consecutive POQ number, but I have no idea how it works out the ordering.

It seems that the first run had immense amount of pending transactions to complete, and that the second had very little to do - hence the drop in final POQ from 489 to 146.


Although there's nothing in the standard SFC extract, there is one error in the detailed log that may need attention...

Code:

POQ 27 ends.
2013-09-26 20:34:05, Info                  CSI    000000d5 [SR] Verify complete
2013-09-26 20:34:05, Info                  CSI    000000d6 [SR] Verifying 100 (0x0000000000000064) components
2013-09-26 20:34:05, Info                  CSI    000000d7 [SR] Beginning Verify and Repair transaction
2013-09-26 20:34:11, Error                 CSI    000000d8@2013/9/26:19:34:11.433 (F) d:\w7rtm\base\xml\udom_microdom.cpp(3734): Error c000003e [Error,Facility=(system),Code=62 (0x003e)] originated in function MicrodomImplementation::CDomLayoutCache::AdvanceCachedPointer expression: (ulElementType == (0x2)) || (ulElementType == (0x3)) || (ulElementType == (0x5)) || (ulElementType == (0x1)) || (ulElementType == (0x6)) || (ulElementType == (0x7)) || (ulElementType == (0x4))
[gle=0x80004005]
2013-09-26 20:37:16, Info                  CSI    000000d9 [SR] Verifying 100 (0x0000000000000064) components
2013-09-26 20:37:16, Info                  CSI    000000da [SR] Beginning Verify and Repair transaction
2013-09-26 20:37:17, Info                  CSI    000000db Repair results created:
POQ 28 starts:
 
POQ 28 ends.

Unfortunately, I can't claim any knowledge as to WTH it means!
Guessing here, that the fact that the verification stage appears to have restarted, and completed successfully, means that there was a mis-read recognised by the system, which then re-read the affected data and was happy with it.


The rest of the log looks pretty clear.

Anything's possible :)
It certainly wouldn't hurt anything to do so.

OUCH!
There's a fair number of manifest problems - Please run a CheckSUR scan and we'll see what that has to say. You'll need to download the latest version (they updated it a week or so ago)