AnthonyM1229

Well, thanks for your help before, MagicAndre. I don't think I would've found ProcMon when I did, without reading through your tutorial and the associated comments. So, my computer actually boots in less than 20 seconds...that's awesome, haha. Ever since I first discovered the Diagnostics/Performance Event log (back in my Vista days), I've normally used the boot time figures there, never knowing about the 10 second idle time or whatever, that's tacked on. Oh well--now I know As for the very small delay by startup tools--I've always made a huge effort to keep auto loading junk away from my boot process. I only have one enabled entry in my MSconfig startup tab I may even experiment with disabling that and instead setting a scheduled task to start it shortly after I log on, because I don't absolutely need it to run at startup.

Hey MagicAndre, I fixed my boot time! It wasn't any device at all that was causing my slowness...it was... ...a stupid font file! I generated a boot log with Process Monitor, and in that log, I isolated all events with a duration of at least one second. Out of tens of thousands of total events (if I recall, correctly--maybe even hundreds of thousands, fewer than 10 lasted more than a second, and so, the offender became instantly visible. It was a leftover ttf file from a font family I installed and tested on April 13 (yeah, some unlucky Friday that turned out to be for me, ha), but then promptly uninstalled. I'm not sure why that one file got left behind...perhaps because it's encrypted (as evidenced by the green color in Explorer). Why anyone would distribute an encrypted font file, who knows...even more odd, why only encrypt one file of a set? Whatever. In any case, I guess because of the encryption, and because it's a file I downloaded in my previous install of Windows, my current install could not access the file...hmm...Process Monitor reported an "access denied" warning on the file, and a hold-up of 20 seconds, the average length of the boot delay I've been experiencing. Previous ReadyBoot issue aside, that font was literally a single-handed destroyer of my fast boot time, and it even began slowing me down the very same day, as my Event Viewer logs indicate. But now, it's gone!!! Haha. I gleefully wiped out the offending file, and obliterated any traces of it in my registry. Afterward, I rebooted, seeing about a 10 second improvement to 40 seconds. A few more reboots, and I was not only back to normal, but even faster than I've been! I'm now averaging 27-30 seconds, whereas my previous normal was closer to 35, with occasional <30-second boots. I've uploaded a new trace. May you take a look at it, and tell me if there's anything more I can do to wring out even another second from my boot time? Haha. I've probably gotten as low as I can already.

This reminded me that my USB 3.0 port was one of the drivers I updated recently. I reverted to the previous driver, but saw no improvement in boot time after running the sysprep boot traces. I then disabled the port altogether--still no help. I've even implemented a scheduled task to do "defrag c: -b" two minutes after I log on, to see if boot files fragmentation is an issue...it's not really helpful, either. Do you have any other ideas? I think I've exhausted my efforts, after thoroughly examining my logs.

My PC Specs: Dell XPS 15 L502X with Core i7-2630QM, 8GB RAM, 640GB 7200RPM HDD, running Windows 7 Pro X64 Hello, Magic Andre. Do you have any idea what could make Readyboot stop functioning in Windows 7? Late last week, I discovered that my Readyboot tracefx files had not been updated in about 6 months (!). I have no idea what happened. Somehow, my typical boot times of 30-40 seconds, survived most of that time until the few weeks leading up to this past weekend. In the middle of April, I began noticing a delay in the boot process (sitting at a black screen after the Windows flag logo for over 10 seconds). I didn't think much of it right away, because 1) it was after the latest round of Windows updates, and 2) I knew I hadn't been treating my computer optimally anyway (such as by going days or over a week in between reboots, when I usually shutdown and reboot every day...intense web design work made me slightly lazy about maintenance of my own computer.) However, last Friday night and into Saturday morning, I decided to do a routine upgrade of my BIOS and Intel and NVIDIA graphics card drivers, as I saw updates available from Dell. After that process, boot time slowed to a crawl, over 60 seconds! And it would never get better from there, no matter how many times I restarted. In fact, it often worsened to about 120 seconds. So, I did some checking in my Prefetch folder--Prefetch appeared to still be working okay, as I saw recent .pf files. But then I checked my Readyboot folder, and that's when I noticed the 6-month old trace fx files. Apparently, my computer had been running on a stuck boot plan since the end of October 2011, and it was fine, because I had used my computer similarly until recently. But now things weren't fine. Not only had boot times ballooned, I was also starting to experience sluggishness in opening/using programs, and I was not going to stand for that, so, I began feverishly researching for how to fix this. I came across your thread, and followed instructions. However, boot traces would fail due to not being able to find the prefetcher, or whatever..."gave up waiting for prefetcher after 300 seconds"--that was some of the words of the error, and I know that error has been discussed elsewhere in this thread. Anyway, to speed my story along, I got so frustrated with not being able to cure my PC's slowness, no matter what I tried...even restoring a backup from just before I installed the new driver updates, did not fix the issue. So, I decided to resort to doing a repair install of Windows (aka an inplace upgrade). That definitely should've been a routine process. In fact, I last did that in early October 2011 in response to another unrelated issue (though I verified I did the reinstall weeks before ReadyBoot apparently quit working). However, as I may document elsewhere, the repair install turned out to be a nightmare (mainly because Windows in its infinite wisdom, would attempt to install itself in one of my data partitions instead of my existing system partition, and then fail at the step where it installs drivers...I finally figured out that by shrinking the size of my data partitions so their free space amounts to less than that of my system drive's, Windows would install properly in the system drive. But, I never had to do such trickery in the past...again, I may further discuss this upgrade misadventure later, perhaps on Microsoft Answers. Edit: I've posted my experience at Microsoft Answers Sorry if I'm being long-winded... I've since finally gotten Windows properly reinstalled as of yesterday, and Readyboot is working properly. After installing all the needed Windows updates and doing other steps for setting up my computer for regular use, I attempted to do the prepsystem boot trace again. This time it worked! I even noticed boot times get down to about 25 seconds a couple times, which would happen occasionally anyway, long before my reinstall and when things were working smoothly. However, such low boot times are elusive now. Instead, I typically average 45 seconds, which is not terrible, sure, but it grates on my nerves, because at startup, I sit at a black screen for 15-20 seconds or more after the flag logo displays. This appears to be the same behavior I noticed in the weeks leading up to now, mentioned above. Currently, I suspect fragmentation of the Prefetch and Readyboot folder contents, may have something to do with it, but if so, that's a losing battle, right, because even when I defragment them, they'll just get fragmented again in the next bootup or two. Speaking of Readyboot fragmentation, what is with the *.DQPA, *.DQPAF, and related files, if you know? These are most subject to fragmentation, and, they are new to me as of this install of Windows. Previously, I only ever saw a ReadyBoot.etl file and up to five trace.fx files in the Readyboot folder. I can't seem to find any documentation on those new files, and for some reason, they seem to be essential... as a test, I marked them as read-only, and within one or two next bootups, my boot time nearly doubled, and ReadyBoot.etl would indicate no cache hits. I seem to be running out of ways to try to stabilize my boot time at under 40 seconds and eliminate the startup delay after the Windows flag display...do you think you can help me out? I've made a folder available on my Skydrive with two traces. My "Trace Of Best Boot" is a <30-second boot traced during a sysprep, while the "Trace Of Typical Boot" is a 45-second boot--what I get at least 90% of the time. Actually, only three total times so far, have I gotten a boot of under 30 seconds with my latest Windows install, and two of those times were during a sysprep. May you analyze my traces, and tell me if there's anything I can do to restore my once-regular boot times of ~30 seconds? I'd greatly apppreciate it--thank you! And if you need any more info from me, please let me know.