More on the help

[vefatica]

If I haven't used the local help for a while (sometimes even five minutes, certainly half an hour) it takes about 15 seconds before a newly opened help window is populated with text and graphics. At it's best, it's about 2.5 seconds. The remote (web) help is faster that that.

Is it possible (in a future version perhaps) that TCC/TCMD could be configured to use a non-default browser for the web-based help?

 

[rconn]

Not reproducible here. But I don't have a system as woefully underpowered & under-RAM'd as you (even my Win 7 x86 VM takes less than 2 seconds in all cases to load a help page). I wouldn't be surprised if Windows is swapping madly on your system. Not much I can do about that.

 

[vefatica]

Not reproducible here. But I don't have a system as woefully underpowered & under-RAM'd as you (even my Win 7 x86 VM takes less than 2 seconds in all cases to load a help page). I wouldn't be surprised if Windows is swapping madly on your system. Not much I can do about that.

I don't know about that. During that 15 seconds, there's no disk activity and no (after the first second) CPU activity. Are there any tests I can perform to figure out what's going on during that time?

 

[vefatica]

10 seconds of that delay seems to be devoted to waiting for a do-nothing thread. Here's what ProcessMonitor shows me. I'm filtering on mostly everything. At 1:14:51 a thread is started and nothing happens until 1:15:01 when the thread ends.

 

[vefatica]

Here's another ProcessMonitor capture. It shows thread IDs. See the 10 second delay before thread 3756 exits (followed by a 2 second delay). I went back to that thread's creation and found that it did nothing (at least nothing in the "file system", "network", or "process" categories). All of this is happening early on, when DLLs are being loaded/mapped.

 

[vefatica]

So I enabled registry events (and ran it again. The thread in question does exactly one thing, queries a WebProxyAutoDiscovery key. That fails. After that, a 10 second delay before the thread exits.

 

[TEA-Time]

Aha! That's an IE thing, and it's on by default. I bet unchecking Automatically detect settings here will fix it:

 

[vefatica]

Did that ... let you know if it fixed the problem. The service has been disabled for as long as I can remember. Also (from the KB) disabled, via GPEDIT, cacheing of such info.

 

[vefatica]

The problem still exists. BTW, the Wpad subkey does not exist in HKLM. It's in HKCU.

 

[TEA-Time]

Oh.. that's right, the setting I referenced is a user preference. Still, if yours was on, I'd expected it to help by disabling it. IE hangs for a bit on startup if that option is on with no service for it to hit up.

Hmm.. might the Group Policy setting "Make proxy settings per-machine (rather than per-user)" in Windows Components\Internet Explorer be enabled? I'm not sure if that would make a difference or not...

 

[vefatica]

This is a very elusive problem. It happens only sometimes ... more likely (but not for sure) if TCHELP.EXE hasn't been run in a while. And I'm beginning to wonder whether I can trust ProcMon. In my most recent capture, a 12-second delay happened here (see below), at a place apparently not connected to Wpad, but still at a context switch from one thread to another. When I look inside TCHELP.EXE I find many references to Borland and Delphi, and many dates ranging drom 1995 to 2008. It suggests that it's not exactly an up-to-date app!

 

[TEA-Time]

It happens only sometimes ... more likely (but not for sure) if TCHELP.EXE hasn't been run in a while.

Interesting... That's how IE behaves with the auto-configuration option on.

It suggests that it's not exactly an up-to-date app!

Yeah... :-/

 

[rconn]

When I look inside TCHELP.EXE I find many references to Borland and Delphi, and many dates ranging drom 1995 to 2008. It suggests that it's not exactly an up-to-date app!

No, it only suggests it's a (new) Delphi app.