Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

More on the help

vefatica

vefatica

May
13,121
180
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?
 
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.
 
rconn said:
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.
Click to expand...
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?
 
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.
upload_2017-1-4_1-22-59.png
 
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.

upload_2017-1-4_11-53-11.png
 
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.
upload_2017-1-4_12-15-12.png
 
Aha! That's an IE thing, and it's on by default. I bet unchecking Automatically detect settings here will fix it:

upload_2017-1-4_10-24-28.png
 
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.
 
The problem still exists. BTW, the Wpad subkey does not exist in HKLM. It's in HKCU.
 
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...
 
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!

upload_2017-1-4_14-50-50.png
 
You must log in or register to reply here.
Back
Top
[FOX] Ultimate Translator
Translate