Develop Reference

Windows Service - UnauthorizedAccessException Error when Installing Service (C#)

So I am trying to create a service using C# in Visual Studio 2017 and I keep getting an error when I try to install it.
Right now, I don't even have anything in my service, I just want to be able to install the service. I created a new Project in Visual Studio 2017 using the Windows Service (.NET Framework) template under Visual C# > Windows Desktop. I then added the installer via Right Click > Add Installer. For serviceProcessInstaller1, I set the account to LocalSystem. And...that's it!
Now, I try to install it. I open up command prompt (run as administrator) and I do
InstallUtil ServiceTest.exe
Things start off smoothly, but then I get a message:
"An exception occured during the Install phase.
System.UnauthorizedAccessException: Attempted to perform an
unauthorized operation."
What could be generating this message?
I've googled and tried the following things:
Ensure I run command prompt as administrator.
Assign Full Control to
the project folder to my admin account.
Configure permissions to Full
Control for admin account in the security log of regedit.
Log into my
computer as an administrator (rather than regular user) and run it
that way.
Despite these things, I keep getting the same error. What else could I be doing wrong? Would really appreciate some advice!
Note: I am trying to install this service locally on my computer.
Edit: Per request, here are the logs. I named my project "FailedService", by the way, since I can't get it to work!
InstallUtil.InstallLog
Running a transacted installation.
Beginning the Install phase of the installation.
See the contents of the log file for the C:\Users\first.m.last\source\repos\FailedService\FailedService\bin\Debug\FailedService.exe assembly's progress.
The file is located at C:\Users\first.m.last\source\repos\FailedService\FailedService\bin\Debug\FailedService.InstallLog.
An exception occurred during the Install phase.
System.UnauthorizedAccessException: Attempted to perform an unauthorized operation.
The Rollback phase of the installation is beginning.
See the contents of the log file for the C:\Users\first.m.last\source\repos\FailedService\FailedService\bin\Debug\FailedService.exe assembly's progress.
The file is located at C:\Users\first.m.last\source\repos\FailedService\FailedService\bin\Debug\FailedService.InstallLog.
The Rollback phase completed successfully.
The transacted install has completed.
FailedService.InstallLog
Installing assembly 'C:\Users\first.m.last\source\repos\FailedService\FailedService\bin\Debug\FailedService.exe'.
Affected parameters are:
logtoconsole =
logfile = C:\Users\first.m.last\source\repos\FailedService\FailedService\bin\Debug\FailedService.InstallLog
assemblypath = C:\Users\first.m.last\source\repos\FailedService\FailedService\bin\Debug\FailedService.exe
Installing service Service1...
Creating EventLog source Service1 in log Application...
Rolling back assembly 'C:\Users\first.m.last\source\repos\FailedService\FailedService\bin\Debug\FailedService.exe'.
Affected parameters are:
logtoconsole =
logfile = C:\Users\first.m.last\source\repos\FailedService\FailedService\bin\Debug\FailedService.InstallLog
assemblypath = C:\Users\first.m.last\source\repos\FailedService\FailedService\bin\Debug\FailedService.exe
Restoring event log to previous state for source Service1.

I was FINALLY able to resolve this issue. I was able to get to the bottom of it by using SysInternal's Process Monitor. I opened up the program and had it take logs for InstallUtil.exe. From there, I began to search for any logs that said "Access Denied". As I sorted through them, I noticed something interesting: it was trying to create a registry key, but it kept failing!
So I went into the registry and created a key named "ServiceTest". After that, I ran the InstallUtil command again, and it worked!
If anyone else is having trouble, the solution is to create a key named after your process name in the following location:
HKLM\System\CurrentControlSet\Services\EventLog\Application\

Enter the full path to installUtil & your service binary in an elevated prompt, that could do.

Getting permission for accessing an existing file in setup created using Inno Setup

I am a new C# programmer. I made a setup file of an application in Inno setup, but when I use this application after installation, the application crashes when it tries to access (read) an existing folder in the computer (which the user has permission to access otherwise). This folder does not contain any program file, or logs. It just contains some media files which are already in the computer.
I saw the Inno script format, but it shows only how to give permission to access program files/folders only, what about the files which are already there in the computer? Shouldn't the application should have access to files which the user (who installed it)has access to ?

To set permissions on existing files or folders, you can use the Windows cacls command in the [Run] section.
Filename: "{sys}\cacls.exe"; Parameters: """C:\My Folder\My File.ext"" /t /e /g ""Everyone"":f ""Power Users"":f ""Users"":f ""Authenticated Users"":f "; StatusMsg: "Configuring Windows settings..."; Flags: runhidden
Type cacls /? at a command prompt for all available switches and syntax.

It worked when I used
"Permissions: users-modify" in [Dirs] section.

Trying to start a new service - but having a permission problem

The error:
I get a popup window when trying to manually start the windows service. It says:
Windows could not start the XXX
service on Local Computer. Error:
1069: The service did not start due to
a logon failure.
Post-build events:
There are 2 Windows services in the solution and they have the same post-build events:
REM C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\InstallUtil.exe /u "$(TargetPath)"
REM C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\InstallUtil.exe /i /username=.\administrator /password=blabla "$(TargetPath)"
But for some reason it's only the first service that is installed during debug-build mode. The other is not (despite similar post-build events). So I manually used the InstallUtil with the administrator login and blabla password from the post-build events. That did install it, but one is installed with "Log On As = Local System" (works!) and the other has "Log On As = .\administrator" (does not work!).
I guess that's what triggers the error. Why the difference? Is there another install going on the solution build somewhere? It should be said that it is a solution consisting of 47 projects.

I'm 99% sure that you can solve this by granting the Log on as service privilege to the administrator user.

Mark MSI so it has to be run as elevated Administrator account

I have a CustomAction as part of an MSI.
It MUST run as a domain account that is also a member of the local Administrators account.
It can't use the NoImpersonate flag to run the custom action as NT Authority\System as it will not then get access to network resources.
On Vista/2008 with UAC enabled if NoImpersonate is off then it will run as the executing user but with the unprivileged token and not get access to local resources such as .installState. See UAC Architecture
Anyone know of a way to either
Force the MSI to run with the elevated token in the same way that running from an elevated command prompt does?
Force the CustomAction to run elevated (requireAdministrator in manifest doesn't appear to work)?
Work out if UAC is enabled and if it hasn't been ran elevated and if so warn or cancel the installation?

Answering my own question for any other poor s0d looking at this.
You can't add a manifest to an MSI. You could add a SETUP.EXE or bootstrapper to shell the MSI and manifest that with requireAdministrator but that defeats some of the point of using an MSI.
Adding a manifest to a CustomAction does not work as it is ran from msiexec.exe
The way I have tackled this is to set the MSIUSEREALADMINDETECTION property to 1 so the Privileged condition actually works and add a Launch Condition for Privileged that gives an error message about running via an elevated command prompt and then quits the installation.
This has the happy side effect - when an msi is ran from an elevated command prompt deferred CustomActions are ran as the current user with a full Administrator token (rather than standard user token) regardless of the NoImpersonate setting.
More details - http://www.microsoft.com/downloads/details.aspx?FamilyID=2cd92e43-6cda-478a-9e3b-4f831e899433
[Edit] - I've put script here that lets you add the MSIUSEREALADMINDETECTION property as VS doesn't have ability to do it and Orca's a pain.

requireAdministrator in the manifest should work.
You can also use a bootloader .exe file which can use ShellExecute with "RUNAS" as the verb (you can use 7-zip to create the bootloader, or there are many other ways).

You can creating a simple sfx archive file for msi file with Winrar and these options:
Setup tab > Run after execution input: your msi file name
Advanced tab > Mark Request Administrative access option checkbox

Uninstall Command Fails Only in Release Mode

I'm able to successfully uninstall a third-party application via the command line and via a custom Inno Setup installer.
Command line Execution:
MSIEXEC.exe /x {14D74337-01C2-4F8F-B44B-67FC613E5B1F} /qn
Inno Setup Command:
[Run]
Filename: msiexec.exe; Flags: runhidden waituntilterminated;
Parameters: "/x {{14D74337-01C2-4F8F-B44B-67FC613E5B1F} /qn";
StatusMsg: "Uninstalling Service...";
I am also able to uninstall the application programmatically when executing the following C# code in debug mode.
C# Code:
string fileName = "MSIEXEC.exe";
string arguments = "/x {14D74337-01C2-4F8F-B44B-67FC613E5B1F} /qn";
ProcessStartInfo psi = new ProcessStartInfo(fileName, arguments)
{
CreateNoWindow = true,
UseShellExecute = false,
RedirectStandardOutput = true
};
Process process = Process.Start(psi);
string errorMsg = process.StandardOutput.ReadToEnd();
process.WaitForExit();
The same C# code, however, produces the following failure output when run as a compiled, deployed Windows Service:
"This action is only valid for products that are currently installed."
Additional Comments:
The Windows Service which is issuing
the uninstall command is running on
the same machine as the code being
tested in Debug Mode. The Windows
Service is running/logged on as the
Local system account.
I have consulted my application logs
and I have validated that the
executed command arguments are thhe
same in both debug and release mode.
I have consulted the Event Viewer
but it doesn't offer any clues.
Thoughts? Any help would be greatly appreciated. Thanks.

Step 1: Check the MSI error log files
I'm suspicious that your problem is due to running as LocalSystem.
The Local System account is not the same as a normal user account which happens to have admin rights. It has no access to the network, and its interaction with the registry and file system is quite different.
From memory any requests to read/write to your 'home directory' or HKCU under the registry actually go into either the default user profile, or in the case of temp dirs, c:\windows\temp

I've come across similar problems in the past with installation, a customer was using the SYSTEM account to install and this was causing all sorts of permission problems for non-administrative users.
MSI log files aren't really going to help if the application doesn't appear "installed", I'd suggest starting with capturing the output of MSIINV.EXE under the system account, that will get you an "Inventory" of the currently installed programs (or what that user sees installed) http://blogs.msdn.com/brada/archive/2005/06/24/432209.aspx
I think you probably need to go back to the drawing board and see if you really need the windows service to do the uninstall. You'll probably come across all sorts of Vista UAC issues if you haven't already...

Thanks to those offering help. This appears to be a permissions issue. I have updated my service to run under an Administrator account and it was able to successfully uninstall the third-party application. To Orion's point, though the Local System account is a powerful account that has full access to the system -- http://technet.microsoft.com/en-us/library/cc782435.aspx -- it doesn't seem to have the necessary rights to perform the uninstall.
[See additional comments for full story regarding the LocalSystem being able to uninstall application for which it installed.]

This is bizarre. LocalSystem definitely has the privileges to install applications (that's how Windows Update and software deployment in Active Directory work), so it should be able to uninstall as well.
Perhaps the application is initially installed per-user instead of per-machine?

#Paul Lalonde
The app's installer is wrapped within a custom InnoSetup Installer. The InnoSetup installer, in turn, is manually executed by the logged in user. That said, the uninstall is trigged by a service running under the Local System account.
Apparently, you were on to something. I put together a quick test which had the service running under the LocalSystem account install as well as uninstall the application and everything worked flawlessly. You were correct. The LocalSystem account has required uninstall permissions for applications in which it installs. You saved the day. Thanks for the feedback!