This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?

> At my place I have installed both versions of Cygwin (i.e. 32-bits and 64-bits) -- of course,
> in different places.  As "some" of you will have the "same" setup, I would like you to confirm
> the following (UNexpected, to me) result:
>  - I canNOT invoke regedit from 64-bits bash (Yes, I can if bash has been invoked in ELEVATED mode)
>  - I can invoke regedit from 64-bits bash (not elevated) as follows: cygstart regedit
>  - however, I can invoke regedit from 32-bits bash (not elevated) ...
>  - likewise, I can invoke regedit from 64-bits cmd (not elevated) ...
> By UNexpected result I mean: I cannot explain why I canNOT invoke regedit from 64-bits bash ...
> My installation in general:
>  - stand-alone installation (i.e. not connected to a domain)
>  - standard passwd and group files
>  - nsswitch.conf: passwd: file, group: files, db_enum: files

Hi Chris,

Thanks for the input!

Of course, it is not really a problem, that regedit cannot be invoked from Cygwin, as it can
be invoked from the Windows interface ...

However, in some of the "harder" cases of using Gygwin, one needs to have a "mental" model of
how Cygwin "integrates" with Windows (is my belief) ... and as far I understand the matter, I
was surprised to find that I could not invoke regedit from bash.

Consequently, I decided to investigate why I got the denial (64-bits Cygwin) at my end.

First of all, some more info about my "environment":

 - I am using Cygwin from Windows 7 ...
 - I am using Cygwin from an administrative account ...
 - furthermore, using secpol.msc, I have set the ConsentPromptBehaviorAdmin field in

   HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System (key in registry)

   to zero, meaning 'elevate without prompting'
   (default: 5, meaning 'prompt for consent for non-Windows binaries)

Note: secpol.msc: security settings > local policies > security options > User Account Control: \
Behavior of the elevation prompt for administrators in Admin Approval Mode

As result of doing that, I am still able to "elevate" using a Standard User Account (as far as I
can remember), while am I able to "elevate" using the Administrative Account without being asked
for consent ...

Back to the issue I started with (back to my investigation).

Using the event viewer (Windows), I have been able to "connect" the denial, reported by 64-bits
bash, with error 'ERROR_ELEVATION_REQUIRED'.

Note: event viewer: applications and services logs > microsoft > windows > uac > operational

Each time I got the denial, an entry was being added to this particular log.

Searching the internet, it got the understanding, that this (new) error value is not handled as it
should be handled ... as far as I understand, the user should be (normally) be asked for consent.

Not handled correctly where? 64-bits bash? 64-bits Cygwin? I cannot tell.

Strangely enough, all of the following invocations of regedit were succesful at my place:

64-@@ cmd /c 'c:\Windows\regedit'
64-@@ cygstart /drv/c/Windows/regedit
64-@@ /drv/e/Cygwin/bin/bash -c /drv/c/Windows/regedit

 - in all of the above cases, 64-bits regedit is being invoked
 - specifying /drv/c/Windows/SysWOW64/regedit invokes 32-bits regedit (successful)
 - and, as I reported before, regedit can be invoked as "usual" from 64-bits bash if bash has been

Btw, using a Standard User Account, regedit can be invoked from 64-bits bash as "usual" ...

As you will notice, invocation of regedit using cygstart (from 64-bit bash) does NOT fail. As far
as I know, cygstart makes use of the "ShellExecute" API i.s.o. the "CreateProcess ?????" API ...
Searching the internet again, it was suggested to me, that the "ShellExecute" API, different from
the other API I mentioned above, takes "appropriate" action in case of ERROR_ELEVATION_REQUIRED.

Another issue you might run into ...

I was surprised to find, that 32-bits bash reported /drv/c/Windows/regedit.exe as a different file,
compared to what 64-bits bash reported.

Note: 32-bits cmd and 64-bits cmd report c:/Windows/regedit.exe as the SAME file. Which, of course,
made me wonder ...

Searching the internet again, I got the understanding, that there has been been a time in which a
request for c:/Windows/regedit.exe was redirected to c:/Windows/SysWOW64/regedit.exe (in case of a
32-bits application).

As far as I can tell, this redirection no longer applies (meaning, as far as can tell, MS changed
its mind here).

My findings and questions in a nutshell:

 - by "default" 64-bits regedit is succesfully invoked from 64-bits cmd, and 32-bits regedit from
   32-bits cmd.
 - both 32-bits cmd and 64-bits cmd list the 64-bits regedit in c:/Windows

 - ... basically, "by default" the same should happen if regedit is invoked from bash ...
    - why does "64-bits Cygwin" (bash?) fail on the invocation of regedit?
 - 32-bits Cygwin (using bash) shows a "32-bits" regedit in /drv/c/Windows
    - does "32-bits Cygwin" (bash?) use a "deprecated API" that still redirects c:/Windows/regedit
      to c:/Windows/SysWOW64/regedit?

It should be obvious, Chris, that I canNOT say why you cannot invoke regedit from 32-bits Cygwin at
your place, as I cannot tell you WHAT to look for.

My hope, when I sent my original message, was, that more than one person would reply. It would have
enabled me "to compare notes".

Thanks all for reading this far ;-),


@@ bash --version | grep bash
GNU bash, version 4.1.10(4)-release (i686-pc-cygwin)

64-@@ bash --version | grep bash
GNU bash, version 4.1.11(2)-release (x86_64-unknown-cygwin)


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]