Page 2 of 2

Re: bug: button doesn't open control panel

Posted: 11 Jan 2011, 18:53
by therube
Can someone please point me at the real problem?
Perhaps there is no "problem"?
I created a Limited account (XP SP3 also).
Started an elevated (right-click a desktop shortcut, Run as ...) CMD (cmd.exe) prompt.
Typed CONTROL at the prompt & nothing happened.
(Actually it seemed as if a window attempted to open, then was immediately closed. Might have been my imagination. Would have to use Process Monitor or similar to know for sure.)

So perhaps some commands are blocked even though you are "Run as" under an Admin account?

Opening a CMD prompt as a Limited user & typing in CONTROL, does open Control Panel as expected.

Odd that it does not work when using Run as?

Re: bug: button doesn't open control panel

Posted: 12 Jan 2011, 09:24
by salaman
therube wrote:
Can someone please point me at the real problem?
Perhaps there is no "problem"?
I created a Limited account (XP SP3 also).
Started an elevated (right-click a desktop shortcut, Run as ...) CMD (cmd.exe) prompt.
Typed CONTROL at the prompt & nothing happened.
(Actually it seemed as if a window attempted to open, then was immediately closed. Might have been my imagination. Would have to use Process
Exactly

Re: bug: button doesn't open control panel

Posted: 12 Jan 2011, 13:46
by Ether
salaman wrote:I actually was hoping that there's another, more native way of creating shortcuts, but still, as you said - i don't mind to write a little of code.
How about Hot Paths?
therube wrote:Perhaps there is no "problem"?
I created a Limited account (XP SP3 also).
Started an elevated (right-click a desktop shortcut, Run as ...) CMD (cmd.exe) prompt.
Typed CONTROL at the prompt & nothing happened.
(Actually it seemed as if a window attempted to open, then was immediately closed. Might have been my imagination. Would have to use Process Monitor or similar to know for sure.)

So perhaps some commands are blocked even though you are "Run as" under an Admin account?

Opening a CMD prompt as a Limited user & typing in CONTROL, does open Control Panel as expected.

Odd that it does not work when using Run as?
Is that all under Windows XP? Run as Admin and Run as... are different functions and associated behaviour differs.

I did a experiment on my own and it seems that Run as Admin doesn't interfere with anything (i.e. works), and Run as... (limited account) makes an error dialog show up when I try to open the Control Panel (using both button and cmd.exe/control methods).

Re: bug: button doesn't open control panel

Posted: 12 Jan 2011, 19:49
by therube
Yes, XP.
(OP is running XP.)
Run as Admin and Run as... are different functions and associated behaviour differs.
Yet something else I need to look into :-).
Now you're saying a right-click on a shortcut & "Run as...", selecting an Administrators account vs. a command-line RUNAS, or am I missing it?

Re: bug: button doesn't open control panel

Posted: 12 Jan 2011, 22:05
by Ether
therube wrote:Now you're saying a right-click on a shortcut & "Run as...", selecting an Administrators account vs. a command-line RUNAS, or am I missing it?
Run as... and runas should use the same functions internally. The difference is with Run as Admin introduced with UAC.

Now that I tested with Windows XP, I can confirm the behavior (and I can also remember that I encountered it before in my XP days). The problem is that control is just a "shortcut" that starts an explorer window with the Control Panel open. If you run control, explorer (or anything else that depends on explorer), it will use the already running instance of explorer (which maintains your desktop and taskbar). But since explorer's running as a different user, something fails and the window is never shown. Sometimes the fail is silent (I guess more often on XP than on 7), sometimes it shows the error dialog.

To dig deeper into the problem: there are several possibilities why the operation fails, not neccessarily exclusive - maybe one possibility applies in one kind of situations and the other in... well, those others. I think we can say one thing for sure: explorer checks mutexes before it initializes itself. But what happens afterwards?
1] upon encountering one, it tries to communicate with an existing explorer, but it hasn't got the correct privileges or namespace.
2] upon encountering one that belongs to a different user, it just gives up.

... AND! During the writing of this post, I have tried several scenarios and settings and may have gotten a solution for you.
x] One good thing to know is, you can kill explorer and replace it with an instance running under a different user. (Start cmd and taskmgr, kill explorer and start runas /user:<whoever> explorer.) It will produce an environment very similar to the one you get by logging in as that user - an added bonus is that you can have more than one of such "desktops" running under the same user account.
x] There's an option for explorer that, if set, will instruct it to open a new process for every new window, effectively bypassing all that mutex machinery. It can be found in Folder Options > View > Advanced settings > Files and Folders > Launch folder windows in a separate process, or set by a simple program Xtra Windows Stability, which I prefer because it aggregates several options similar to this one.