Automatically restart shell

[Jure]

Hi,

I already searched this NG for such a problem. I also found some posts,
but I couldn't find a clear answer. If I overlooked it, please point me
to it.

My situation in brief:
I made a two shell image like described in the article:
http://msdn.microsoft.com/library/d.../html/tchDifferentShellsForDifferentUsers.asp
I assume you know what it is about, so I won't describe it in details
(if I should, I'll be glad to do that). As described in the mentioned
article, I set Key3 ("HKCU\Software\Microsoft\Windows
NT\CurrentVersion\Winlogon\Shell") to point to my custom application,
e.g. "c:\Program Files\MyApp\myapp.exe", which should act as the shell.
The problem is that if I close that application, it doesn't restart
automatically.

So, is there an easy solution (apart from writing annother "watchdog"
application which would respawn the custom application if it crashes)
to restart the shell?


Thank you in advance for any answer,
Jure

 

[KM]

Jure,

Please set the following registry value:
[HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon], "AutoRestartShell"=dword:1

 

[Jure]

KM,

I already tried that. Actualy I tried also part of the solution you
proposed in this topic:
http://groups.google.com/group/micr...p.embedded/browse_frm/thread/219d6606b940aee6

I tried only the following steps:
"Anyway, there is possible another trick (on NTFS only, though):
- have explorer.exe as default shell for any user.
AutoRestartShell=1
- after build, rename the explorer.exe to something like
MSexplorer.exe
- rename your custom shell app to explorer.exe "

I didn't go further since currently the system runs on FAT32. If I was
certain it solved the problem, I'd do that but since the person who
started that topic gave some code as the final comment/solution, I
thought it didn't work, so I preferred to ask first for possible
solutions.

Regards,
Jure

 

[Romain FETTES]

Hi,
Try 'shelaunch.exe' as shell, just search for it on google, easily
customisable by an ini file, does the job for us.
Have fun
romain

KM,

I already tried that. Actualy I tried also part of the solution you
proposed in this topic:
http://groups.google.com/group/micr...p.embedded/browse_frm/thread/219d6606b940aee6

I tried only the following steps:
"Anyway, there is possible another trick (on NTFS only, though):
- have explorer.exe as default shell for any user.
AutoRestartShell=1
- after build, rename the explorer.exe to something like
MSexplorer.exe
- rename your custom shell app to explorer.exe "

I didn't go further since currently the system runs on FAT32. If I was
certain it solved the problem, I'd do that but since the person who
started that topic gave some code as the final comment/solution, I
thought it didn't work, so I preferred to ask first for possible
solutions.

Regards,
Jure

Jure,

Please set the following registry value:
[HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon],
"AutoRestartShell"=dword:1

 

[KM]

Jure,

http://groups.google.com/group/micr...p.embedded/browse_frm/thread/219d6606b940aee6

Now I remember where I saw similar question. Thanks for pointing out that
thread.
Unfortunately, I never had enough time to explore the AutoRestartShell key
more carefully.

The key does work though for most of my images here even with a custom shell
implemented.

I tried only the following steps:
"Anyway, there is possible another trick (on NTFS only, though):
- have explorer.exe as default shell for any user.
AutoRestartShell=1
- after build, rename the explorer.exe to something like
MSexplorer.exe
- rename your custom shell app to explorer.exe "

Well, IIRC, the trick there was to lock down the access to the msexplorer to
admin only. Obviously, requires NTFS. I am away from my desk now for a week
so won't be able to test this approach.

We yet don't know asll the specs for your system so it is hard to assume if
the above can work for you either. For the Autorestart shell, I think,
Winlogon works better. Although the key worked just fine for me with
Minlogon as well with CMD shell, for instance. By "better" I mean it was
more intensively tested.

I didn't go further since currently the system runs on FAT32. If I was
certain it solved the problem, I'd do that but since the person who
started that topic gave some code as the final comment/solution, I
thought it didn't work, so I preferred to ask first for possible
solutions.

Well, you don't really have to use that un-tested workaround.
You can go easier way. E.g., along with your custom shell app create a
simple no-GUI app that will do a CreateProcess/OpenProcess call for your
main custom shell app.
Launch the non-GUI app as shell. Since end user is not able to close the
non-GUI app it will always be there running and the app code can monitor
your custom shell app running status. Very easy to accomplish if you stick
to OpenProcess API.
The non-GUI app can be a script (if appropriate script engine is added to
theimage config). E.g., Yaron's VB code:
http://groups.google.com:80/group/m...p.embedded/browse_frm/thread/219d6606b940aee6
However, my personal opinion, C/C++ will do that better - a few lines of
Win32 code and no dependencies beyong Win32 API.

Regards,
KM

Regards,
Jure

Jure,

Please set the following registry value:
[HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon],
"AutoRestartShell"=dword:1

 

[Jure]

Jure,


Now I remember where I saw similar question. Thanks for pointing out that
thread.
Unfortunately, I never had enough time to explore the AutoRestartShell key
more carefully.

The key does work though for most of my images here even with a custom shell
implemented.


Well, IIRC, the trick there was to lock down the access to the msexplorer to
admin only. Obviously, requires NTFS. I am away from my desk now for a week
so won't be able to test this approach.

I'm just curoius So, locking down the acces to msexplorer was just
for security reasons (so that the user can't run it). I thought it was
for some other, functional reason (so that the system worked
properly.....).
I also didn't understand what you meant by:
" have a peice of code in your custom shell app to launch explorer.exe
(e.g., CreateProcess). If MSexplorer.exe launched properly, do nothing
then. "
But that's not that important right now. I mean, I don't want to ask
something which was already discussed, and I ask that just for
curiosity.

We yet don't know asll the specs for your system so it is hard to assume if
the above can work for you either. For the Autorestart shell, I think,
Winlogon works better. Although the key worked just fine for me with
Minlogon as well with CMD shell, for instance. By "better" I mean it was
more intensively tested.

Maybe just a thought. Is it possible that the problem is caused by the
fact that actually only Key3 (in article
http://msdn2.microsoft.com/en-us/library/ms838576.aspx) is set to some
Shell value and actually this isn't a "true shell"? I mean, the custom
app isn't explicitly a shell component (created in TD), like e.g. in
http://msdn2.microsoft.com/en-us/library/ms838335.aspx where a custom
shell component (with "Shell Prototype Component" selected!!) was made.
I tested the approach described in this article, and the shell
automatically restarts when closed....

Well, you don't really have to use that un-tested workaround.
You can go easier way. E.g., along with your custom shell app create a
simple no-GUI app that will do a CreateProcess/OpenProcess call for your
main custom shell app.
Launch the non-GUI app as shell. Since end user is not able to close the
non-GUI app it will always be there running and the app code can monitor
your custom shell app running status. Very easy to accomplish if you stick
to OpenProcess API.
The non-GUI app can be a script (if appropriate script engine is added to
theimage config). E.g., Yaron's VB code:
http://groups.google.com:80/group/m...p.embedded/browse_frm/thread/219d6606b940aee6
However, my personal opinion, C/C++ will do that better - a few lines of
Win32 code and no dependencies beyong Win32 API.

Probably an application like that will be the final solution I just
started this post to see if it's possible to use the already
implemented (and probably more safe and robust) solution than writing a
custom monitoring app.

Thanks very much for your time and help KM,
Jure

 

[KM]

Jure,

I'm just curoius So, locking down the acces to msexplorer was just
for security reasons (so that the user can't run it). I thought it was
for some other, functional reason (so that the system worked
properly.....).

Yup, Yaron's problem was to have different shells launched for different
users.

Not really a security reason but just a way to block the access to explorer
for non-admin users.

I also didn't understand what you meant by:
" have a peice of code in your custom shell app to launch explorer.exe
(e.g., CreateProcess). If MSexplorer.exe launched properly, do nothing
then. "

Sorry, I think I meant MSexplorer.exe there in both places. Basically, the
custom shell app (which becomes explorer.exe after renaming) is responsible
for launching MSexplorer.exe. The way how the custom shell differenciated
the currently logged on user from administrator was the fact if the
MSexplorer.exe was launched properly. And if the MSexplorer.exe was launched
properly, it should become the shell.

Btw, now when I think more about it I don't believe that approach would
work. To have explorer working as the shell you must have it mentioned in
Winlogon\Shell registry key. Otherwise, the explorer is just launched in a
windowed mode (with no taskbar). It just requires a little bit more
preparation (fix in registry) to make that approach work, though.

Anyway, I think that discussion is not really relevant to your problem. Your
issue is a bit simpler - you just want to auto restart the shell when it
gets closed, right?

But that's not that important right now. I mean, I don't want to ask
something which was already discussed, and I ask that just for
curiosity.


Maybe just a thought. Is it possible that the problem is caused by the
fact that actually only Key3 (in article
http://msdn2.microsoft.com/en-us/library/ms838576.aspx) is set to some
Shell value and actually this isn't a "true shell"? I mean, the custom
app isn't explicitly a shell component (created in TD), like e.g. in
http://msdn2.microsoft.com/en-us/library/ms838335.aspx where a custom
shell component (with "Shell Prototype Component" selected!!) was made.
I tested the approach described in this article, and the shell
automatically restarts when closed....

Well, one other thing for you to try is to set the Winlogon\Shell key under
HKLM branch (not under HKCU)!

Regards,
KM

 

[Jure]

KM,

Well, one other thing for you to try is to set the Winlogon\Shell key under
HKLM branch (not under HKCU)!

I'll try that ASAP, but now I'm away from the computer for a couple of
days, so maybe I'll post a response with some delay.

Regards,
Jure

 

[Jure]

Hi,

sorry for the really big delay in posting the response.

I tried and it doesn't work. However, I'll do as you suggested, i.e.
write a custom app to monitor the shell's application status.

Thank you for all your help!

Regards,
Jure