| Date: | September 16, 2009 / year-entry #296 |
| Tags: | tipssupport |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20090916-00/?p=16693 |
| Comments: | 16 |
| Summary: | Occasionally, a customer will run into a problem that manifests itself only when Autologon is enabled. Here are some examples: If we log on manually, everything works just fine. But if we log on using Autologon with the same userid and password, we get a networking error from our wireless network card. Is there a... |
Occasionally, a customer will run into a problem that manifests itself only when Autologon is enabled. Here are some examples:
The issue really isn't Autologon. The issue really is the manual logon. For you see, manually logging on takes time. If you really concentrate you can get it down to one or two seconds, but under more realistic circumstances, a manual logon will be significantly slower than an automatic one because it simply takes time to click and type and click. And those seconds are crucial. That extra time, the delay introduced by the fact that human beings type a lot more slowly than a computer can, is enough to get those services you are relying fully initialized by the time you need them. Locating and connecting to a nearby wireless access point typically takes several seconds. If you use Autologon, the system will plow ahead with trying to contact the domain controller to validate your password, but the wireless networking card hasn't found the base station, and you get an error. ( In the second case, the problem is that the remote desktop service is not yet fully started by the time the program in the Startup group tries to use it. Under such conditions, you may want to query the status of the remote desktop service; if it reports a status of Anyway, the point for today is that Autologon itself doesn't have problems. Rather, Autologon takes away the "seconds of rest" the computer normally experiences while it's waiting for a human being to log in, and sometimes it's those extra few seconds that you were inadvertently relying upon. |
Comments (16)
Comments are closed. |
And thus the circle is complete:
http://blogs.msdn.com/oldnewthing/archive/2007/10/16/5465592.aspx
Sadly, I never found the answer to why the limit was set at 128 days.
John, Raymond blogged about that almost a year ago! Is there anything this man doesn’t have an answer to?
http://blogs.msdn.com/oldnewthing/archive/2008/11/13/9064839.aspx
Of course, since the article Nick links to is about delaying boot, it doesn’t solve the problem.
Perheps Microsoft could add another autologon registry settings that allows autologon to delay by certain seconds?
Or perhaps, by default, Windows shouldn’t allow someone to logon until it’s ready.
@Craig Matthews
So Windows has to guess who is going to log on and what programs will be started (ie: remote desktop) and then wait for the services those programs need before any user at all can log on?
@Drak: So after we introduced "Automatic (Delayed)" in Vista, we’d have yet another startup state setting "Automatic (Before logon)"?
Our software is used with auto-login machines, and we used to have terrible startup problems. We used to advise our customers to start the various components (they were console applications) using a startup batch file sprinkled liberally with delay statements.
Now we do it the proper way. We’ve converted everything into Windows services and made full use of Windows’ service dependency mechanism. All the problems have miraculously gone away.
A bit off topic. I noticed a few weeks ago that if you’re using the blue login screen in XP your wlan connection won’t connect to the access point.
After I set the classic login screen up, I was able to connect via vnc and login.
…is enough to get those services you are relying *on* fully initialized…
(I’m not a native English speaker so I could be wrong)
Yeah, it’s always the user’s fault, because they’re always asking for new features that work properly and don’t break others.
Speaking of autologon, why is it not possible, beginning with Vista, to override Autologon by pressing the SHIFT key before logon. Why is the IgnoreShiftOverride registry value is ignored in Windows Vista and Windows 7? Was this feature hampering any other feature? Or things get removed just like that or forgotten to be put back if removed inadvertently? I’ve been reporting this to Connect, blogs and Microsoft forums but this still isn’t getting fixed. Maybe Windows 7 SP1?
Btw I found Logon Expert (www.logonexpert.com/-if it would help anyone) which slightly performs a delayed logon compared to Windows’ built-in autologon.
@DRAK
Your question makes no sense.
The article states that these problems occur when autologin is used because it logs the user on too quickly before Windows is finished initializing things.
The article states that these problems do not occur when a manual login is used because Windows has time to finish initializing things *before the user is finished typing their credentials* specifically because a user types slower than autologin.
FTA: "Autologon takes away the "seconds of rest" the computer normally experiences while it’s waiting for a human being to log in" <— This explicitly refers to activities that Windows is doing in the background while the user is typing their credentials, which are completed prior to the user finishing typing (which, by contrast would not be completed because autologin is faster than a user typing), therefore what does predicting what the user is going to run have to do with anything when everything is initialized just fine before the user logs in as long as he types credentials instead of autologging in?
This reminds me of an excellent idea from back when I was an embedded programmer. We were discussing how to get ready to release and the system was still spewing out a fair few debug printfs on the serial port. Some customer had complained. Someone who knew about such things said "if you take those out it’ll stop working. Leave in all the ones that passed the last full test, just reprogram the GPIO pin routing register so the serial port pins were all used as GPIO inputs".
Brilliant idea, I thought. Later on we set things up so that if you held down some magic key sequence on boot it would set the port up as normal so you could still get a log from the release build.
And I’ve seen the other case – rebuild with the printf’s #ifdef’d out at the last minute and it invariably ends in introducing bugs.