Program in HKLM\Software\Microsoft\Windows\CurrentVersion\Run sometimes does not start
Antti Nivala
program does not start when the user logs on to Windows. Are there any known
reliability problems in getting programs started this way?
Our software includes a program that needs to run whenever a user logs on to
Windows. Our program puts up an icon in the notification area of the status
bar and takes care of certain important tasks. This program must always be
running, otherwise our software is not fully functional. In a multi-user
situation (e.g. Terminal Services or XP Fast User Switching), each
interactively logged-on user that has explorer.exe running should also have
our program running. To achieve this, we have placed the full path to our
program in HKLM\Software\Microsoft\Windows\CurrentVersion\Run.
For some strange reason, our program does not _always_ start when a user
logs on. This happens fairly infrequently, but nevertheless happens. I think
it has happened on XP laptops only but I don't know if that is really
meaningful or not. Apparently, Windows either does not launch our program,
or our program crashes very early during its startup. If our program
crashed, it should save a minidump and pop up a dialog box but this has not
happened. Neither do we see any indication in Event Log that our program
would have crashed. Because of this, I think it is more likely that Windows
just has not executed our program at all.
Are there any known causes for this kind of behavior? Can someone recommend
some other, more reliable way of starting our program after explorer.exe
starts?
Thanks in advance!
Antti
Gary Chanson
"Antti Nivala" <niv...@newsgroup.nospam> wrote in message
news:%23pYNzdl...@TK2MSFTNGP12.phx.gbl...
I use the Registry Run key for several of my programs and I've never seen
them fail to start (except in cases where they failed for their own reasons).
In the cases you've seen, have other autorun programs also failed to
start?
One possibility I can think of is that if for some reason Explorer were to
crash during startup before running your program, the OS would restart
Explorer and your program would not get run.
--
-GJC [MS Windows SDK MVP]
-Software Consultant (Embedded systems and Real Time Controls)
- http://www.mvps.org/ArcaneIncantations/consulting.htm
-gcha...@mvps.org
Rhett Gong [MSFT]
Glad to see you.
For the causes for this behavior, I think the same way as Gary.
> Can someone recommend
> some other, more reliable way of starting our program after explorer.exe
> starts?
I am not sure what role this "logon start" program plays in your case, but
from your description, seems it is you who create/install the program in
the end users' system and uses some functions inside it.
In my opinion, the easy way to achieve the goal is to use the program as a
service ---- we register this program as an automatically started service.
When your software is started, we could call StartService on it and check
if it is already running or not. If it is not running StartService will
start it, otherwise ERROR_SERVICE_ALREADY_RUNNING or other status codes
will be returned.
Please let me know if my answer helps you resolve the problem. If there is
anything more I can assist you, please feel free to let me know.
Thanks,
Rhett Gong [MSFT]
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties and confers no rights.
Paul Delivett.com
I have had problems in the past when using the long file name full path. But
it was a long time ago on 2000. Might be worth a try.
Regards
Paul Delivett
"Antti Nivala" <niv...@newsgroup.nospam> wrote in message
news:%23pYNzdl...@TK2MSFTNGP12.phx.gbl...
Gary Chanson
"Paul Delivett.com" <Paul.D...@NewMediaSecurity.com> wrote in message
news:eR5UjFu...@TK2MSFTNGP10.phx.gbl...
> Hi
>
> I have had problems in the past when using the long file name full path. But
> it was a long time ago on 2000. Might be worth a try.
The long file name works properly even in Win2K as long as you put quotes
around it. Otherwise, it will get confused by spaces within the name (even on
newer versions).
Antti Nivala
debugging the problem :-) But it's been solved now. Thanks for your input,
you helped a lot by convincing me that the Run key itself does not have any
problems.
I installed 10 copies of our app side-by-side, which helped me make the
problem more reproducible. Almost every time I forcefully shut down the XP
laptop and then restarted it, some of the icons of our app did not show up
in the system tray. Somehow the fact that XP started a lot slower after a
forceful shutdown made the problem occur more frequently.
In the end, I found out that in some circumstances displaying the tray icon
using Shell_NotifyIcon just failed. We had not noticed this problem because
an extra AfxPostQuitMessage call in our window's OnDestroy actually
prevented our error message dialog from appearing. So, an error occured, but
another coding error silently dismissed the error message and caused the
process to exit cleanly and silently very soon after it had been launched.
The only mystery left now is why Shell_NotifyIcon sometimes fails, at least
in our application, when called during logon to Windows XP. It seems to
occur easily if the computer is a slow one and if starting up services and
other apps takes lots of CPU time. When Shell_NotifyIcon fails during logon,
GetLastError() typically returns ERROR_TIMEOUT. Is there some sort of
timeout period built into Shell_NotifyIcon??? And sometimes GetLastError()
just returns zero after Shell_NotifyIcon has failed, so even this timeout
thing does not explain everything.
I found some postings on the web about Shell_NotifyIcon and ERROR_TIMEOUT.
It seems that I'm not the only one who's had this problem. But nobody ever
received a definitive answer.
Right now, we have worked around the problem by retrying Shell_NotifyIcon a
few times if it fails during application startup. I'd be delighted to hear
the real cause for the problem and the real solution :-)
Antti
Rhett Gong [MSFT]
icons in te taskbar on the startup time. I am not very sure what
circumstances you mean "in some circumstances displaying the tray icon
the taskbar) is not/ not-fully started. And it is possible that this issue
may be caused by other problems we did not find out, for real cause, I
believe we need kernel-debugging the windows from startup time to find the
root.
If there is anything more I can assist you, please feel free to let me
know.
Have a nice day,
Antti Nivala
> icons in te taskbar on the startup time.
Correct (our program is started by the
HKLM\Software\Microsoft\Windows\CurrentVersion\Run key).
> I am not very sure what circumstances you mean "in some circumstances
> displaying the tray icon using Shell_NotifyIcon just failed".
I only know that sometimes this happens.
> As I can imagine, Shell_NotifyIcon generally fails when shell (especially
> the taskbar) is not/ not-fully started.
Our program is launched by the
HKLM\Software\Microsoft\Windows\CurrentVersion\Run key. Is this too soon? I
would assume that at this point explorer.exe is already fully operational.
But is the taskbar still in the process of starting in some background
thread of explorer.exe? If yes, how can we wait until the taskbar is fully
operational?
Antti
Gary Chanson
"Antti Nivala" <niv...@newsgroup.nospam> wrote in message
Explorer is the program which processes the run key and it is fully
functional before your program is started. Assuming that Explorer itself does
not get killed off before starting your program, it will be started. If it
then fails to start or to create its notify icon, you should look for a
problem in the program's startup code.
Paul Baker
error.
Perhaps Explorer.exe is just taking too long to start. Does it seem that way
on the occasions that it is failing?
Paul
"Antti Nivala" <niv...@newsgroup.nospam> wrote in message
news:eQtgdqEM...@TK2MSFTNGP15.phx.gbl...
Paul Baker
Shell32.dll is timing out waiting for it to automatically recover.
Paul
"Gary Chanson" <gcha...@No.Spam.TheWorld.net> wrote in message
news:OTUCj8KM...@TK2MSFTNGP10.phx.gbl...
Rhett Gong [MSFT]
after the shell is "fully functional".
But for the taskbar, TaskbarCreated message signifies that the taskbar
initialization is complete. I think we could try trap this message and we
could let our apps send messages to taskbar to add icons to taskbar's
notification area when we receive TaskbarCreated create message.
Please let me know if my answer helps you resolve the problem. If there is
anything more I can assist you, please feel free to let me know.
Thanks and regards,
Antti Nivala
> error.
>
> Perhaps Explorer.exe is just taking too long to start. Does it seem that
way
> on the occasions that it is failing?
Your suggestion that Explorer.exe is just taking too long to start sounds
correct. I am certain that Explorer.exe has not crashed during those
occasions.
The problem seems to occur much more easily if I have previously forcefully
shut down the laptop. This seems to trigger some additional operations
during startup that make the logon process much slower.
The laptop itself is pretty old and slow. It takes between 10 seconds and 60
seconds for Explorer to get fully started. It seems that there is something
like a 20-seconds timeout in Shell_NotifyIcon. If it fails, it always seems
to happen pretty much 20 seconds after the Shell_NotifyIcon call was made.
What I'm saying here is that our app calls Shell_NotifyIcon, and the call
does not return. After 20 seconds, it returns zero (fails), and GetLastError
in most of these cases returns ERROR_TIMEOUT.
I can't understand what could be wrong in our startup code. It is always
executing exactly the same simple startup steps, but sometimes the
Shell_NotifyIcon call just takes a long time and fails. I have worked around
the problem by retrying the Shell_NotifyIcon call in those cases, and this
seems to always help. That is, calling Shell_NotifyIcon again with exactly
the same arguments succeeds. Perhaps not the second call yet, but the third
or fourth or fifth call by the latest (the program sleeps 1 - 2 seconds
between the retries). It really seems that we have to give Explorer.exe more
time...
If there really is a need for this kind of retrying, I think this should be
documented. From the current Shell_NotifyIcon documentation, it would seem
that the
Here are links to two other discussion where the writer has encountered the
same problem. These
have not received a valid response:
Subject: Shell_NotifyIcon fails with errcode = ERROR_TIMEOUT
http://groups.google.fi/groups?hl=fi&lr=&threadm=45300248.0301311649.1de7db5%40posting.google.com&rnum=1&prev=/groups%3Fq%3DShell_NotifyIcon%2520ERROR_TIMEOUT%26hl%3Dfi%26lr%3D%26sa%3DN%26tab%3Dwg
Subject: Shell_NotifyIcon failing intermittently under XP Home
http://groups.google.fi/groups?hl=fi&lr=&threadm=OduMTPNDDHA.2328%40TK2MSFTNGP10.phx.gbl&rnum=3&prev=/groups%3Fq%3DShell_NotifyIcon%2520ERROR_TIMEOUT%26hl%3Dfi%26lr%3D%26sa%3DN%26tab%3Dwg
Antti
Jim Barry
> Right now, we have worked around the problem by retrying
> Shell_NotifyIcon a few times if it fails during application startup.
> I'd be delighted to hear the real cause for the problem and the real
> solution :-)
Shell_NotifyIcon is delivered to the tray window via SendMessageTimeout with a timeout of only 4 seconds. Depending on what programs are installed under the "Run" key, Windows really chugs on startup so this timeout period could easily be exceeded. In that case, the retry strategy looks good to me. You mentioned that sometimes GetLastError returns zero - I'm not sure what circumstances would cause that.
--
Jim Barry, MVP for Windows SDK
Paul Baker
Paul
"Jim Barry" <j...@mvps.org> wrote in message
news:uvnq86LN...@TK2MSFTNGP10.phx.gbl...
Paul Baker
message to the tray window, I guess that means it must exist and it is at a
late point. Therefore, is there any reason it can't process the message
immediately upon receipt? Therefore is the problem that it doesn't even
*get* the message for more than 4 seconds?
If so, Windows must be really chugging! What crap the poster have running at
startup that would cause that?
Paul
"Jim Barry" <j...@mvps.org> wrote in message
news:uvnq86LN...@TK2MSFTNGP10.phx.gbl...
Antti Nivala
In my case, I've encountered this on Windows XP. In most cases, GetLastError
returns ERROR_TIMEOUT after a failed Shell_NotifyIcon call, but sometimes
(say every tenth time it fails) it returns 0.
Note that the documentation of Shell_NotifyIcon does not say anything about
calling GetLastError to get more information about failure. So I assume
Shell_NotifyIcon itself does not guarantee a proper value for GetLastError
in case of failure, but one may find something useful there if a function
that Shell_NotifyIcon calls internally sets the LastError value.
Antti
Antti Nivala
> upon receipt? Therefore is the problem that it doesn't even *get* the
> message for more than 4 seconds?
>
> If so, Windows must be really chugging! What crap the poster have running
> at startup that would cause that?
The test laptop really starts up slowly after a forced shutdown. Windows
seems to perform some additional things that make the startup slower than
usual. But as far as I can tell, our app is not doing anything special in
those cases. I've commented out everything except the code that is directly
related to showing the tray icon.
To me it still seems that when the startup of XP is slow enough because of
lots of (valid) programs in the Run key, Shell_NotifyIcon is vulnerable to
failing even though the application itself is properly coded. It seems that
some circumstances that are not in the application's control are causing
Shell_NotifyIcon to fail.
As I said, I'm not the only one who has had this problem, so perhaps there
is something wrong with Shell_NotifyIcon on XP...
Antti
Paul Baker
I suppose you can't rely on it. That's poopy.
Paul
"Antti Nivala" <niv...@newsgroup.nospam> wrote in message
news:OL0Fnwh...@TK2MSFTNGP12.phx.gbl...
Jim Barry
> Note that the documentation of Shell_NotifyIcon does not say anything
> about calling GetLastError to get more information about failure. So
> I assume Shell_NotifyIcon itself does not guarantee a proper value
> for GetLastError in case of failure, but one may find something
> useful there if a function that Shell_NotifyIcon calls internally
> sets the LastError value.
Yes, exactly. Shell_NotifyIcon actually calls SetLastError(0) initially. After that, basically it uses FindWindow to find the tray notification window and sends a WM_COPYDATA message to it. If that message returns zero, then Shell_NotifyIcon will fail with GetLastError returning zero. The only obvious way I see for that to happen is if the tray icon already exists, though no doubt there is some other reason that I haven't managed to spot.
Paul Baker
within 4 seconds, I'm thinking Windows is really really bogged down at that
point.
Paul
"Jim Barry" <j...@mvps.org> wrote in message
news:e4fVcOkN...@TK2MSFTNGP10.phx.gbl...
Rhett Gong [MSFT]
Have you tried calling Shell_NotifyIcon after TaskbarCreated is receieved?
Does it make some difference in this case?
I do test in some slow machines i can find (PIII 700 box), but have no luck
to get the problem reproduced. If this issue impacts your product, I
suggest you contact our PSS directly ---- our engineer would remote to your
desktop and debug to find out the root cause of this problem.
Antti Nivala
assumed that since Explorer.exe is starting our app, the taskbar is already
functional. Later, we do use the TaskbarCreated message to detect
Explorer.exe restarts so that we can re-add our icon.
I will probably do more tests later, but as of know, I am happy with the
workaround of retrying Shell_NotifyIcon calls if they fail during
application startup. This has helped us avoid the problem completely. I do
not fully understand the reasons why the Shell_NotifyIcon call sometimes
fails, but since retrying always solves the problem we & you do not need to
spend more time with this issue. If I find out something new, I'll let you
know or contact PSS directly.
Thanks for your help!
Antti
Rhett Gong [MSFT]
you need assist, please don't hesitate to let me know.
Best regards,