sh.exe appcompatflags elevated privileges

Max Polk
Fri Dec 27 15:45:00 GMT 2013

On a fresh 32-bit cygwin install onto a 64-bit windows 7 machine, 
somehow sh.exe became a child node inside these two areas (or subtree 
areas) in the registry:


Causing it to require elevated permission to run.  Each time I ran 
sh.exe manually, or via a script with /bin/sh shebang, even after 
several fresh installs, it popped up the user account control question 
asking for elevated privileges to run sh.exe.  If you say yes, it opens 
in its own new console window.  If you say no, you get permission denied.

The data for the key in each case seemed to hint that it was marked as 
having to run it with elevated privileges, or in windows xp 
compatibility mode.  By deleting both keys, normal functionality was 
restored.  I'm sure I didn't ask for that.

How it got this way is unknown, I had tried the 64-bit cygwin but 
couldn't do without clisp.  Deleted, reinstalled 32-bit cygwin and it 
wouldn't work for the reasons above.  Tried 2 more times, same thing.  
Since it lived beyond fresh installs, I finally tried searching the 
registry for "sh.exe".  I removed the keys referencing sh.exe inside the 
areas listed above.  Then things wouldn't run from emacs-w32 due to 
vfork problems and popen failure, so I had to ash rebaseall then all was 

Shot in the dark, but it might have to do with me trying BitDefender 
free antivirus which actually blocked an exe I freshly compiled, so 
since it was really blocking too many Cygwin things I went to AVG free.  
So I'm sending this mostly as a reference of how I fixed it in case 
someone else runs into it.  Could be a narrow failure case under just 
the right set of conditions with Cygwin as the victim and some 
third-party software as the culprit.

Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list