MVP'S? Corrected Repost re 2+min Post-boot Sys Delay

[lbrty4us]

Fllwg prob & search for it's cause/solution persisting for 4 months:
I have taken the trouble to be thorough in its descr - TIA 4 ur
patience & lack of conclusion-jumping before considering all.

Box: Compac notebook Presario 2195US/Ath2500/512/40g no ntwk connect
& usually no peripherals attached. XP Home, has SP1 & most all recent
updates.

There is no worm or virus or spyware detectable on this box
(double-checked with update NAV & Spyhunter, filesearches etc.).
Earlier post mis-named a process (wrongly from my memory) associated
with a worm. There are no other observed operating problems beyond
the fact that it's, well, Windows<g>.

Here is the actual name (abbreviation) list of drivers that load 2+
minutes after boot is completed, obtained from bootvis by extending
its dump duration to 3 minutes, in their order of very late loading.
The rest of the table columns (delay times etc.) are omitted here but
available if needed. They have to be read & hand-typed because the
table utility doesn't copy/paste. All major functions are device
controllers except the first 2 which are CREATE:

Process Driver
------------ ---------

explorer.exe(1364) wdmaud
explorer.exe(1364) ks
ONETOUCH.EXE(1480) wdmaud
explorer.exe(1364) wdmaud
explorer.exe(1364) ks
explorer.exe(1364) ks
explorer.exe(1364) wdmaud
ONETOUCH.EXE(1480) wdmaud
ONETOUCH.EXE(1480) DkbFltr
ONETOUCH.EXE(1480) DkbFltr
winlogon.exe(616) wdmaud
ONETOUCH.EXE(1480) DkbFltr
ONETOUCH.EXE(1480) DkbFltr
ONETOUCH.EXE(1480) DkbFltr
imapi.exe(1304) imapi
imapi.exe(1304) MxlW2k
imapi.exe(1304) Cdr4_xp
imapi.exe(1304) pfc
imapi.exe(1304) redbook
imapi.exe(1304) pwd_2k
imapi.exe(1304) Cdralw2k

Some relate to necessary navigation & connectivity processes
(explorer.exe etc.), some are audio functionality, some are just HP
One-Touch frills etc. You can start any app, but can't do
anything in it until these load. Of course the logon .wav & audio &
ntwk tray icons only appear & sound after the delay. Power & touchpad
icons are unaffected & appear immediately after boot.

Actual boot to GUI cmplts in 30 sec or so.

- did all the usuals: unnecessary startups/any ntwkgn
startups all cleared in CP & msconfig etc.;
- some these drvr or refs to them do appear in the prefetch file, but
appear not to prefetch quickly enough(?) - tried deleting/recreating
the P/F file too;
- bootvis has no effect on optimizing these post-boot drvrs, & is not
a cause since it predates my obtaining it in misguided attempt to fix
this, & resulted in no change; FWIW it *did* shorten actual boot time
a bit;
- unclear whether these are all supposed to be "post-boot" loads & not
loaded during boot?;
- the Defrag GUI does indicate a 2nd large immoveable sector halfway
up the HD, which may or may not hold these drvrs & may or may not be
relevant; boot defrag flag to "Y" doesn't move it;
- the 40g HD is 3/4 empty;
- in *one* instance, before normal defrag, these drvrs were suddenly
loading within 2-3 sec after boot; after defrag, back to the 2 min
delay, may or may not be a fluke;
- no HD activity/seeking is indicated during the 2-min post-boot
delay, until they begin loading;
- *if one waits at the login screen* for the same 2+ minutes before
loggin on, these drvrs will load immediately (within 2-3 sec) after
boot, possibly indicating there is some sort of prefetch call for
them just being greatly delayed?

Others are beginning to rpt same prob on other NG's & www forums w/o
response. Appears no info anywhere on the 'net or in MSKB etc. -
help?

Email CC much appreciated,
Frank

 

[Alex Nichol]

There is no worm or virus or spyware detectable on this box
(double-checked with update NAV & Spyhunter, filesearches etc.).
Earlier post mis-named a process (wrongly from my memory) associated
with a worm. There are no other observed operating problems beyond
the fact that it's, well, Windows<g>.

Here is the actual name (abbreviation) list of drivers that load 2+
minutes after boot is completed, obtained from bootvis by extending
its dump duration to 3 minutes, in their order of very late loading.
The rest of the table columns (delay times etc.) are omitted here but
available if needed. They have to be read & hand-typed because the
table utility doesn't copy/paste. All major functions are device
controllers except the first 2 which are CREATE:

There is nothing in your list that looks out of the ordinary or likely
to cause delays. And BootVis will stop logging when the processing of
items in registry - not parts of the system - begins. The two things
that come to mind:

Do you have a LAN connection trying to be made and access the LAN DHCP,
and the LAN is not around? That can give a minute or more delay before
timing out

Start - Run MSconfig.exe and look at the things starting on the Startup
page, and on Services with 'Hide all Microsoft' checked. Such delays
may be from such background processes starting up - AV may be set to do
a scan at this time; Zone Alarm Pro I have found holds things up as it
initialises

 

[lbrty4us]

There is nothing in your list that looks out of the ordinary or likely
to cause delays.

Yes, only posted to show the specific delayed items.

And BootVis will stop logging when the processing of
items in registry - not parts of the system - begins.

(you are the expert)When I extend its duration, it does log & graph
add'l events such as app starts etc.

Do you have a LAN connection trying to be made and access the LAN DHCP,
and the LAN is not around? That can give a minute or more delay before
timing out

Disabled this early on, thx. Similar previous disabling/re-enabling
in CP console etc. without effect.

Start - Run MSconfig.exe and look at the things starting on the Startup
page, and on Services with 'Hide all Microsoft' checked. Such delays
may be from such background processes starting up - AV may be set to do
a scan at this time; Zone Alarm Pro I have found holds things up as it
initialises

AV & other unnecessary autostarts were disabled early on & show
"stopped." Did just try disabling an (unknown) WAN start, no
difference. Also, total clean boot (only Load System Settings &
Boot.ini), has no effect, yields identical 2+ min delay.

Not wishing to prejudice an expert's thinking, I'd suggest considering
that (per the last point of my OP) it's odd & significant that the
long delay "doesn't care" which side of the logon screen it is
subjected to. Since waiting an equally-timed period B4 logging on
produces immediate full loading & sys availablity without further
delay, I am inclined to believe the problem may have nothing to do
with other processes which are supposed to start after the boot, and
any other delays such additional processes may or may not introduce.
IOW, the affected drivers take the same extended amt of time to load
independently of the logon point's position on the timeline.

This behavior tempts me to consider that thinking in terms of any
post-boot process problems or conflicts may be a waste of time.(?)
Perhaps we need to think outside the box.

My idiot-marine-engineer *suspicion*<BG>, is that the affected drivers
have somehow become separated & repositioned in another immovable
sector much further away on the near-vacant HD which is not being
searched for a considerable period of time.