Well, you have basically three phases here, all affected in different ways.
It takes almost 10 seconds to get from kernel bootstrap to starting the very first process (smss.exe), which must happen before any other processes can be initialized. This delay is pretty long, and can be attributed almost entirely to Symantec's scanning engine driver.
It only takes an additional 45 or so seconds to get to and through the "post-boot" phase, which is considered complete after all automatic services have started, the user has logged on, the shell is visible and loaded, and all start/run/runonce/etc. items have finished starting. This phase shows two issues - one, the Symantec product appears to be doing an on-access scan, which causes random writes during random reads (which as we all know is one of the slowest things a mechanical drive can do); and two, there's a decent amount of head movement which indicates a small amount of disk fragmentation (and it appears that neither Superfetch or Readyboot are optimized well, which could be due to defragmenting with a non-Microsoft defragmenter or other antivirus scan artifacts, for instance).
One interesting bit of the trace shows a large amount of USB polls by the nusb3mon process and driver, which I believe is installed when you attach certain Western Digital external USB hard disks (and potentially others, of course). This driver causes heavy I/O delays throughout the trace (and I've seen it many times before, so this is not anything new), especially bad when an external USB device is attached. Unless you need the Western Digital (or whichever vendor branded) USB software, you'd be wise to remove it.
The last bit seems to be a rather large search index cache, which doesn't really hit the machine until a time after PostBoot has completed. I cannot easily explain why this seems to take so long, other than you have two very inefficient (I/O-wise) applications with filter drivers installed (WD's nusb3mon and Symantec's I/O filter driver) which would be invoked on every read and write to the search index db cache. I can't say this is even an issue, per se, because I don't have +DRIVERS - however, from experience, I would say I can visualize what these *usually* look like, and if that is the case here, you might want to consider four things:
- Increase the frequency that your system runs defrag.exe, and clear the prefetch cache to force a rebuild
- Consider a lighter antivirus product, which will have the side-effect of increasing I/O performance
- Remove any USB software installed by external devices if not needed for day-to-day usage of the device(s)
- Consider the size and amount of folders in your search index, and consider paring down if possible to reduce the size of the search cache database files
As to #2, that's more a personal choice - I have heard that newer versions of the Norton Internet Security consumer products were more efficient, but as I don't use them myself I cannot corroborate any such statement (and with years of experience with their corporate products, I can't say I believe such proclamations much either). I can only tell you what it appears is happening from the data, no more, no less.
.
