I have a tablet PC running XP Tablet 2005 with a built-in Wifi card and LAN
port.  The access point I use at home has issues with WZC and constantly
drops the connection, so I've setup the config tool that came with the
laptop.  That tool disables WZC in preference of its own setup.  I was seeing
this delay with WZC as well, so I don't think thats an issue.  In both cases,
I'm using DHCP to get the IP address from the associated access point.

The delay lasts about 2 minutes, and is occurring shortly after the "Loading
your personal settings" screen shows up.  I've run BootVis, and it seems that
the delay starts just after SPBBCSVC.EXE launches.  About one minute later
WUAUCLT.EXE starts, and a minute after that ALG.EXE starts along with several
other processes and booting resumes normaly.  During the 2 minutes, BootVis
shows the the CPU, drive, IRP stacks, and the rest are all quite inactive.

It would appear that these items (Norton Internet Security, and Windows
Auto-updater?) both are looking for a network when one isn't setup yet and
delaying boot in hopes that it just a temporary thing.

Is there a way to indicate to these services that they need to wait?  Or if
not, is there a way to delay or disable the WUAUCLT.EXE process?  I'm not
sure whats starting it, since its not showing up anywhere in the registry, or
in the service lists.

Woody <Wo***@discussions.microsoft.com> wrote:

I don't think there is any one answer to "why does this happen".  In
the cases I've seen, both based on BootVis I/O delay logging and based
on physically debugging the machine, the 120-second delay is due to a
120-second timeout in mrxsmb!MRxSmbRegisterForPnpNotifications.

BootVis showed that SVCHOST.EXE had a IRP_MJ_DEVICE_CONTROL call in
progress down to the Microsoft SMB redirector (MRXSMB.SYS) for up to
120 seconds.  Under the debugger this was confirmed to be originating
from the Microsoft "Workstation Service" (WKSSVC.DLL, running on a
SVCHOST.EXE instance) and that the IOCTL was specifically blocked in
mrxsmb!MRxSmbRegisterForPnpNotifications in a nt!KeWaitForSingleObject
with a hard-coded 120-second max timeout.

I've seen this happen in seemingly "predictable" cases.  Such as cases
where the workstation doesn't have any other network interface besides
the wireless interface, but the wireless interface cannot obtain an
address via DHCP until after a post-login wireless configuration tool
gets launched.  As such mrxsmb!MRxSmbRegisterForPnpNotifications is
waiting for one or more network interfaces to be known.  But since the
network interface won't come up until post-login, you're stuck waiting
for the APIPA (169.xx.xx.xx) to fianlly be auto-assigned to the
interface or for the 120-second timeout to expire.

This situation could also occur in some cases by having the Wireless
Zero Configuration service stopped, presumably for similar reasons.
But not everyone having the issue had WZC stopped, and not all those
who did have it stopped saw success once it was started (although some
did succeed then).

But this same issue seems to happen in "unpredictable" cases too; e.g.
with the presence, removal or re-installation of seemingly unrelated
software.  So it seems like there is just a more specific underlying
condition or issue that has not been fully appreciated yet.

My own guess (and its just a guess) based on what I've seen is that
you're always going to encounter "something" that will hang and have
to be allowed to timeout because of this, if the issue is occurring.
Even if the application isn't network-specific or specifically waiting
for a network interface (which would also be an issue), applications
that call any API that is directly or indirectly dependent on the
Workstation Service for its answer can get hung up anyway because the
initialization of the Workstation Service itself is being delayed.

So either "delay anything that needs the network or the Workstation
service" would end up being "everything", or new things end up getting
delayed because of the services you've now deferred because they
depend on the network or Workstation service.

The best approach would probably trying to get a wireless network
interface that becomes active even pre-login.  You might check into
whether the non-WZC-based configuration tool for the wireless card is
intending or can be configured to run pre-login (e.g. as a service,
like WZC).  Doing so, if possible, would allow the network interface
to become active instead of timing out to the end of the 120 timeout.

Alan Adams

Thanks for the reply Alan, it at least has one bit of info I didn't know
before, which was the bit about SMB redirector.  Maybe if I disable SMB
services (which I don't use on the laptop) it will speed up the boot process.
(Assuming thats still possible?)

Do you think that changing that, or the Workstation service to Manual start,
and then adding a startup cmd in the boot reg/startup list would work?  May
try that tonight.

It just baffles me that MS doesn't have a hot-patch for this to prevent the
2 min timeout delay.  Do they think nobody uses wifi as a primary network? 
Or that nobody uses a 3rd party wifi manager in place of their WZC service? 
Seems pretty outrageous to me. :(

Woody <Wo***@discussions.microsoft.com> wrote:

Its not something I would recommend, but I guess its possible it could
end up being effective.  What doesn't compute for me is "what happens
to all the stuff that wanted to use information from the workstation
service" if you did that.  As described earlier, I would be expecting
to have new problems by trying to force individual services to delay
loading; even though you might "avoid the 120-second timeout", now
you've affected something else.

Alan Adams

Basic question, hope you can help
Wireless connection questions
"Limited or No Connectivity"
Wired and wireless
wireless card features table
No internet access on wireless - DNS error
NetGear WG111v2 Adapter - fluctuating signal
Allowing access to my own computers within my own network
XP and only one wireless access point
Netgear wireless adsl router only 11mbs