I have a set of NetTCP services configured that run under a Windows service for production but I use a console app to spin them up for debugging purposes. With Windows Vista I disabled UAC outright because it was annoying, however I'm trying to leave it enabled with 7 because it does everything I want while being very quiet and not naggy.
The issue I ran into is when running VS in "standard" mode (i.e. not using run as administrator) the services won't spin up because it says this:
"The service endpoint failed to listen on the URI 'net.tcp://localhost:60000/[ServiceName]' because access was denied. Verify that the current user is granted access in the appropriate allowedAccounts section of SMSvcHost.exe.config."
After a bit of research I was able to find this file and modify it with the SID for my user account. The config looks like this:
<?xml version="1.0" encoding="utf-8"?><configuration>
<runtime>
<gcConcurrent enabled="false" />
<generatePublisherEvidence enabled="false" />
</runtime>
<system.serviceModel.activation>
<net.tcp listenBacklog="10" maxPendingConnections="100" maxPendingAccepts="2" receiveTimeout="00:00:10" teredoEnabled="false">
<allowAccounts>
<add securityIdentifier="S-1-5-21-XXXXXXX"/>
</allowAccounts>
</net.tcp>
<net.pipe maxPendingConnections="100" maxPendingAccepts="2" receiveTimeout="00:00:10">
<allowAccounts>
<add securityIdentifier="S-1-5-21-XXXXXXX"/>
</allowAccounts>
</net.pipe>
<diagnostics performanceCountersEnabled="true" />
</system.serviceModel.activation></configuration>
The SID came from the tool packaged in the Sysinternals suite and was validated against ADSI Edit so I know it's correct. After a reboot the services still won't spin up though and I'm trying to avoid forcing it to run in administrative mode because then you can't double-click on solution or project files anymore which is rather irritating.
Anyone have any ideas? The SMSvcHost.exe.config file came from "C:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation" and even though I'm running x64 the app is compiled in x86 mode. I'm not sure if that is where my trouble lies?
To find "right" configuration file location do the following:
Locate NetTcpPortSharing in serivce tab in Task Manager.
Click Go to process in context menu.
Click Open file location.
ps.
on my Windows 2008 R2 x64 with .NET 4 location is C:\Windows\Microsoft.NET\Framework64\v4.0.30319
Related
Applications must be run with administrator privileges. How to ask the user is? How to verify that he agreed to? How do I know whether already running application as an administrator?
Made as described here by the user ChrisW67. The result is not received. If possible, give an example of "Hello world" project.
P.S Windows 7. Am writing in Qt Creator. Qt5.2
Disclaimer: Why does your application require admin rights? A modern application should in most cases be able to avoid this. One could use a service for the elevated actions.
I realize that you are using Qt. I don't have access to this tool at the moment, but here are a few general options. Essentially you need to modify the manifest that gets embedded into the binary on compilation:
.NET:
How do I force my .NET application to run as administrator? (as stated above; you modify the manifest that gets embedded in your application executable). More here.
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
Remember to verify admin rights in case the UAC is disabled - in that case the user is not prompted for admin rights on application launch.
C++: In C++ you can set a flag in the project properties: How to run application with Admin privileges using Manifest file in Visual Studio 2005?
Shortcut: You can set up the launching shortcut to require admin rights. The user will then be prompted on launch. "Run this program as an Administrator".
I've inherited maintenance of an application that, when it runs, occasionally causes the UAC admin elevation (Do-you-wish-to-allow-this?) dialog to appear. To me, the obvious first thing to try is "switch on UAC logging", re-run the application to make the dialog appear, then find the entry in the log that says, for example, "2013-11-23-19:10:03 [MyApplication] attempted to write registry entry [MyRegistryKey]. Requires admin authorization", then take steps to resolve things so the dialog doesn't surface when the application is being used.
However, some people posted questions about UAC logging in 2008/09, in relation to Vista, and the answer was something like "UAC doesn't log, but that would be a great feature for a future release". Was UAC logging ever implemented, either in Windows 7 or as a patch release? If not, is there an alternative technique that is commonly used?
I resolved the problem eventually. Here is what happened.
1) I tried Ben's suggestion of using the sysinternals tools. The tools that seemed useful were
DependencyWalker
ProcessExplorer
ProcessMonitor
They each provide a lot of information about what is going on, and I can see that these will need to be the first port of call for many, if not most, Windows problems. However, in my case I double clicked the app and got the UAC userid/password dialog but then found that not much information had been written by the tools up to the point the dialog was surfaced.
It also looked like it would be useful to digest the contents of the Microsoft Press Windows Internals books when attempting to troubleshoot problems with UAC.
2) I tried using the Application Compatibility Toolkit, but it showed no issues with the program either on XP (where it worked) or Windows 7 (both with standard user, which surfaced the UAC dialog and admin user, which worked)
3) I then tried painstakingly recreating the app from scratch, starting with an empty project and then copying in files and settings bit by bit. At each stage, I checked whether the app would launch without surfacing the UAC dialog.
Eventually I applied a change and this caused the UAC dialog to surface. This was a VB6 app and I changed the "application title" and the "product name" in the dialog Project, Properties, Make. The previous (failing) value of each field was "ApplicationName Update". To make the app work without UAC elevation, what I had to do was remove the word "Update".
As Ian suggested above, it looks like the UAC heuristics were being applied, and to values within the exe. I see that the Windows Internals book does talk about scanning for byte sequences in the exe when deciding whether to elevate.
4) So in summary, the approach that worked for me was to reassemble the app bit by bit and see at what stage the UAC dialog is triggered. Once this happens, knowledge of the four reasons given by Ian in the previous answer become important.
5) I should point out that I have fixed the problem by removing the thing that was being flagged in the heuristics, but didn't consider the alternative suggested by Ian: "asInvoker". It could be that this is the best thing to try rather than spending time inside the (legacy) app fixing problems.
find the entry in the log that says, for example, "2013-11-23-19:10:03 [MyApplication] attempted to write registry entry [MyRegistryKey]. Requires admin authorization"
UAC does not work like that. Windows does not watch an application, and based on the activity decide that it should run elevated next time.
Windows 7 mostly behaves the same as Windows XP in this regard. If your app is running as a standard user, tries to write to:
HKLM\Software\Cotoso\Litware
your application will get an Access Denied error message.
Unless File and Registry Virtualization is enabled for buggy apps
Unfortunately, most applications are poorly written. Most applications, when run as a standard user on Windows 2000 or Windows XP, crash horribly. Since 1999, as part of the Windows Logo Requirements, Microsoft has required developers to test their applications while running as a standard user. Almost nobody ever does.
That is why, starting with Windows Vista, Microsoft added a feature that lets your buggy application think it successfully wrote to HKLM, or Program Files. If a write fails, which would have succeeded if the user was an administrator, Windows will reissue the write operation, except this time redirect it someplace that will succeed. For example:
writes to
HKLM\Software
are redirected to
HKCU\<User SID>_Classes\VirtualStore\Machine\Software
writes to
C:\Program Files
are redirected to
C:\Users\Westwell\AppData\Local\VirtualStore\Program Files
Neither of these redirection mechanisms will cause your application to be elevated on next launch. Both of these features are temporary compatibility hacks. You can inform Windows that you wrote your application correctly, opt-out of file and registry virtualzation, by adding a requestedExecutionLevel of asInvoker to your application's assembly manifest:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="client" type="win32"/>
<description>Westwell Contoso</description>
<!-- Disable file and registry virtualization -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
Now only eliminates the side-discussion of why sometimes writes can succeed, even when the user is a standard user.
When does UAC Elevation happen
There are five reasons why an application might prompt to elevate on launch:
You manifested that your application needs to be run as an administrator.
If you app needs to be run as an administrator, and cannot perform any useful functionality without being an administrator, then you can manifest your application as requireAdministrator (rather than asInvoker):
<description>Westwell Contoso</description>
<!-- Disable file and registry virtualization -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
If this were the case, then the application would always run as an administrator. So that's not it.
You manifested that your application be run as administrator only if the user actually is an administrator.
Applications like RegEdit can run fine as a standard user, they do not require elevation. But if the user is actually an Administrator RegEdit can prompt to elevate to the user's full admin privelages. This done by marking your application as highestAvailable (rather than asInvoker or requireAdministrator):
<description>Westwell Contoso</description>
<!-- Disable file and registry virtualization -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
If this were the case, your app would prompt for elevation for admins, but not prompt for standard users. This cannot be the cause because your application has no manifest.
Compatibilty option marked the application as Run as administrator.
The user can choose to mark an application so that it should prompt for elevation:
The state of this checkbox (and the other checkboxes) is stored in the registry:
HKCU\Software\Microsoft\WindowsNT\CurrentVersion\AppCompatFlags\Layers
and for "all users" under:
HKLM\Software\Microsoft\WindowsNT\CurrentVersion\AppCompatFlags\Layers
This option can be per-user, or per-machine. So it's possible some users will see an elevation prompt, and others will not. This could be a source of your problem.
Installer detection heuristics.
By default, Windows will attempt to recognize that an application is probably an installer (e.g. setup.exe, install.exe, update.exe) and prompt the user to elevate. This feature can be disabled through group policy, the policy name is User Account Control: Detect application installations and prompt for elevation.
The Easy Fix
The easy fix is to simply mark your application asInvoker. That will disable heuristics.
After that, it must be a compability setting on the machine (AppCompatFlags in HKCU or HKLM).
Bonus Reading
Registry Virtualization
User Account Control Data Redirection
I suddenly cannot start IIS anymore on my Windows 2008 R2 server. The depending "Windows Actication Service" does not start.
In the Event Viewer I can see the following message:
"The Windows Process Activation Service failed to generate an application pool config file"
I've checked all IIS config files for typo's, none can be found.
I've tried to remove the IIS role from the server, which results in an error.
I'm totally desperate here. I've looked on Google for several hours, but none of the suggestions I've found helped.
Something has messed up permissions and the user account under which WAS runs does not have permission to create its working files. Probably you installed a service pack or similar.
Rebuild the box and apply all service packs to Windows before you install WAS, and then let it update itself and then install your own stuff.
Rebuilding boxes is no fun and takes far too long. Learn to use virtualisation and undo disks.
If you have another working server, you can import IIS configuration from there via Shared Configuration. I was able to resolve this error by doing so.
i was making an installer for my app its working fine on xp but on vista the UAC is giving problem unless i do a run as administrator the Unexpected error appears when i run my app afters installation, any idea?
i am installing the application in C:\xfolder\x
There is nothing you can do. You MUST run the installer as administrator.
As for the application, you will also need to run it as administrator with elevated priviledges but thre are options to make it ask automatically for elevation via application manifest. You can do a search on stackoverflow.com because there are more post related to this issue.
Here is a link to a post that might help.
Here are a couple more usefull link on app manifest and UAC:
App Manifest (1)
App Manifest (2)
UAC technology.
They are in C# but then again translating to VB.net is like a walk in the park.
You can make a windows service. And put all operations that require elevated rights into that service. You install the service as SYSTEM account and you communicate with the client via .net remoting or any other way for vb6.
if your app exe is an active x exe then you will need to register all the ocx file using regsvr command and then register your exe with regsvr32 command, for an active class to be used in win vista it first must be registered. make a batch to do these registration.
I put together a small WCF service in VS2008 and when I try to run the host using an HTTP protocol, it bombs because it doesn't have the proper rights to do so. On my "Host.Open()" line I get this exception: "HTTP could not register URL http://+:9001/. Your process does not have access rights to this namespace." I did not seem to have this problem using TCP. My o/s is Vista Home Premium.
This was happening when I would try to Debug it inside VS2008. After a lot of research, I determined I could get the host to run by building, going to the "bin" folder, and right-clicking on my executable, selecting "Run as Administrator". The same thing happened when I tried to use the WcfSvcHost.exe. I had to open the VS2008 Command Prompt window from my menu using "Run as Admin" before I could successfully get WcfSvcHost to run my service.
Is there a way to do this right instead of using this workaround? Am I going to have similar problems when I try to deploy this next week on a Windows 2003 Server?
This link might help you: http://msdn.microsoft.com/en-us/library/ms733768.aspx
Short version: pre-register the url/namespace from a privileged console
netsh http add urlacl url=http://+:9001/ user=DOMAIN\user
Make sure you are starting VS as administrator..
Locally, you can change your base address to something like this:
<host>
<baseAddresses>
<add baseAddress="http://localhost:8731/Design_Time_Addresses/MyService/" />
</baseAddresses>
</host>
The main part being the addition of "Design _ Time _ Addresses". If you create a WCF Service Library project, it sets up the App.config for the project like this by default. Everything works fine this way, but if you remove "Design _ Time _ Addresses" and try to run it with "http://localhost:8731/MyService/", you will get the error that you are running into.
I was having a similar problem here:
WCF ServiceHost basicHttpBinding 503 error
The netsh command works for Vista, but for Windows 2003 server, there is an HttpCfg.exe utility that allows you to register a URL/namespace for an account. Not sure if the netsh is available in 2003.
I never actually got it to work on Vista, I'm still getting 503 errors when I try to access the services. If you run into the same problem/figure it out, I'd appreciate it if you post again! Thanks