Odd delay before control panel, programs start in Windows 7

[wombatpete]

Hello,
Specifically:
There's a significant delay before the control panel displays as a menu when activated from the control panel.
It's as if the computer is waiting for a response from something, times out, and shows the menu.

Note: when I activate the control panel from a desktop shortcut, it opens IMMEDIATELY.
Programs seem to start with a similar delay; otherwise, the computer seems very fast.

Looking at the task manager as I try to open the control panel as a menu, I see only that explorer.exe shoots up to about 13% of memory usage, nothing else unusual.

I've set the menu open delay in the registry to 1. That hasn't helped, either.

I have a new IBM/Lenovo Thinkpad with i7-2720 & 8GB RAM & Windows 7 (fully updated).

A clean start does NOT solve this problem.

Could the issue be related to services started/disabled? I've played around with them, but it hasn't solved the issue.

I've run all the hardware diagnostics I can find - the memory, and everything else, passes with flying colors.

 

[cluberti]

If you're willing to install a tool and take a trace, we can probably figure out what's happening.

1. Install the Windows Performance Toolkit following the instructions here - note you don't need to take any traces, just follow the section called "Installing the tools"
2. Open up an elevated command prompt.
3. Type this command into that command prompt, and press ENTER to start the trace:
   

   xperf -on DIAG+DISK_IO_INIT+DRIVERS+FILE_IO+FILE_IO_INIT+FILENAME+NETWORKTRACE+PRIORITY+PROFILE+REGISTRY+SPLIT_IO

   Note you will not get any indication a trace is running, the command prompt will just return to a prompt when the trace has started
   
4. Reproduce the delay in opening the control panel
5. Type this command into the command prompt and press ENTER to stop the trace:
   

   xperf -d C:\slow.etl

Once you've done the above, compress (using 7zip, winrar, etc.) the slow.etl file and upload it somewhere so we can download it and analyze it for you.

 

[wombatpete]

Thanks, I'll install it now and report.

 

[cluberti]

Fantastic .

 

[wombatpete]

If you give me an e-mail (or temporary e-mail alias), I can send it via yousendit.com.
Would that work?

 

[cluberti]

Send me a PM and I will reply with specifics.

 

[Dwarf]

You should be able to attach the file to a reply.

 

[cluberti]

I would doubt it - even compressed it is going to be larger than the forum allows.

 

[Dwarf]

I would doubt it - even compressed it is going to be larger than the forum allows.

What sort of size are we looking at?

 

[wombatpete]

Apparently I have insufficient privileges to send a PM (?!)
When I go to quicklinks & select "Send a PM", I'm told that I can't access the page.

 

[cluberti]

More than 20 or so MB - if it's a long trace, probably closer to 100+MB (zipped!).

 

[cluberti]

@wombatpete - try uploading to mediafire, and posting the resulting download link here instead.

 

[wombatpete]

OK, I've done that.
I've created two files.
The link to the first one is: slow.etl
The second one records a similar pause before opening a program (specifically, OpenOffice).
That .etl is still uploading; I'll post it as soon as it's up.
Thanks all!

 

[wombatpete]

And here's the second .etl file: slow2.etl
Thanks again.

 

[wombatpete]

Actually, I'm not sure those are "open" links.
Let me try again.
First file: slow.etl
Second file: http://www.mediafire.com/file/dcsppsdd552scmx/slow2.etl

 

[cluberti]

You might want to try zipping these up with 7zip before posting them. It'll go quicker.

Downloading now.

 

[wombatpete]

Sorry... here's the 1st, 7z-ed: slow.7z

One of those days.

 

[wombatpete]

And here's the other one: slow2.7z

 

[cluberti]

These are interesting, although not entirely unexpected:

In slow.etl #1 (opening control panel), the trace is 44 seconds (approximately). In that time, it appears these are all a part of the slowdown:

• Opera, during the time of the delay, is causing a lot of file I/O, and it's because of the Adobe flash plugin. This appears to be the better part of 17 seconds of delay.
• cmdagent.exe is causing an inordinate amount of file I/O (specifically QueryInfo calls) and WMI calls during the time that the shell (explorer.exe) is querying the registry for CLSIDs to display information (and what MUI / language to use, etc) to display control panel items. This is approximately 5-6 seconds of delay - this is also exacerbated near the end with opera.exe's file I/O (at close to 100% of the total disk I/O time during this timeframe).
• Lenovo's MessageCenter Plus takes 7.9 seconds to initialize once the control panel itself starts to load, which delays the load of the control panel. The control panel finishes loading once MCP loads in 0.3 seconds.

It appears that this issue is caused by 3 things:

1. Opera.exe is out of control when running, so assume any time it is running, it's going to consume large amounts of CPU and disk time due to the flash plugin until you fix it (and I have no idea what "it" is that is causing it).
2. Comodo's Agent is slowing down disk and registry file access whenever anything that can access the network is running - Comodo is fine if you like it, but I've seen enough performance issues with it in the past to recommend you consider something else instead.
3. The MFT and disk are somewhat fragmented, and there are A LOT of head seeks in this trace. If you're using a specific tool to manage disk fragmentation other than defrag.exe, it might be time to reconsider it's effectiveness.

Slow #2 is approximately 45 seconds, and looks like this:

• DCOM thumbnail cache lookups take 5 seconds to load.
• Resource Monitor is accessing/creating it's backup (via WMI) during the launch. This takes approximately 7 seconds.
• It appears that any time one of the three binaries necessary for Writer (swriter.exe, soffice.exe, soffice.bin) attempt to touch *any* files, Comodo also opens the files and parses them. It also parses other files and registry accesses, basically more than doubling the time it would otherwise take to open the OpenOffice binary (at least according to this trace).
• Disk shows far less head reads, although the cache is flushing far more often.

The answers to this are basically the same as the first:

1. Comodo is your biggest problem
2. Your disk is your second, although for different reasons this time - it looks like this is a Seagate 320GB notebook drive with 16MB of cache, and having more cache would make it faster. Not sure how much, but some.

I wish the answers were a silver bullet, but these traces are fairly simple and straightforward.

 

[wombatpete]

Fascinating. I would have thought there was something being queried that eventually just timed out, allowing things to continue. But I suppose not.
Thank you, sir.
I'll test the browser issue; that's easy enough.
The HDD was destined for upgrade, anyway.
What about the firewall/antivirus? Do you here have a recommendation on this? Is there a consensus?
Thanks again, it's the first actually answer I've gotten in a lot of searching over this week.