c# error on windows service - c#

I have the following error:
OpenSCManager Failed 5: Access is denied.
Can someone help me? Is there another way besides using installutil to install the windows service ?
P.S : I am using Visual studio 2008. I did look for installutil in C:\VisualStudio... but i can't find it either.
I found the InstallUtil.exe executable. I run the application and now i have the error: c:...\InstallUtil,installLog is denied. WHY?

There are two questions here:
For the access denied problem. Chances are you are don't have permissions. Run the command with administrative privilegies. This means that you have to be a member of administrators group and your process has to be elevated, i.e. you have to right-click -> Run As Administrator to lauch the process.
There are many ways to install service. Since you already know InstallUtil, I don't have to mention it.
There is Win32 API called CreateService.
There is command line utility sc.exe -- it comes with OS by default
If you are so inclined, you can hack registry -- it is not that difficult to reverse engineer records under HKLM\System\CurrentControlSet\Service\
I personally prefer sc.exe. It installs managed services just fine.

Related

How remote debug C#/.Net app on Linux when the app is run under a different user?

I'm running a .Net Core microservice on Linux (Ubuntu) and am trying to remote debug with Visual Studio over SSH. But the service is run under the user svcuser and my user is mainuser. Main user is in the same group as the service user.
In visual studio, I can see the process that the service is running under, but when I try to attach I get:
One or more errors occurred. Failed to attach to process. The .Net Debugger has insufficient privileges to debug the process. To debug this process, vsdbg must be running with root permissions.
I checked in MS documentation but for Linux all they have is this: https://learn.microsoft.com/en-us/visualstudio/debugger/remote-debugging-dotnet-core-linux-with-ssh?view=vs-2019 which has no info on running the service with a different user
And the only info they have on fixing such a problem is for windows only: https://learn.microsoft.com/en-us/visualstudio/debugger/error-the-microsoft-visual-studio-remote-debugging-monitor-on-the-remote-computer-is-running-as-a-different-user?view=vs-2019
If you have sudo privileges then this is relatively easy, and can be kept secured to those users with sudo privs. Avoids needing to reconfigure users/environments, and allows you to debug any process on the machine regardless of which user account it is running as.
If you use Visual Studio to make an initial attempt to debug you will find that a ~/.vs-debugger folder has been created in the home directory of the user account you were attempting to use. This command will help you locate the vsdbg binary which was installed. You can install VsDbg manually but I find leveraging the automated process is easier. If you are using VSCode this becomes a manual process, and an exercize left for the reader, but I would still use VS2019 IDE to prep the target just to keep things consistent between tools.
find ~ | grep vsdbg
For my installation the binary is located at ~/.vs-debugger/vs2019/vsdbg and this path will most likely change over time.
First, rename the binary to something convenient:
mv ~/.vs-debugger/vs2019/vsdbg ~/.vs-debugger/vs2019/vsdbg-bin
Second, create a script to replace the binary:
touch ~/.vs-debugger/vs2019/vsdbg
chmod 770 ~/.vs-debugger/vs2019/vsdbg
nano ~/.vs-debugger/vs2019/vsdbg
The script content might look something like this, note the full path to vsdbg-bin, the use of $# ensures all command-line args passed to your script are forwarded to VsDbg.
#!/bin/bash
sudo ~/.vs-debugger/vs2019/vsdbg-bin $#
Now retry your debug session from Visual Studio, if you did things correctly you should be able to attach to any remote process on the target machine using SSH->VsDbg. "Works on my machine." ;) This was confirmed with VS2019 16.8.4, .NET 5.0, and VsDbg 16.9.20122.2 debugging an ASP.NET Core application running on Debian 5.4.8 (x64) launched by systemd under a service user account in Azure. "Sweet."
HTH!

Access Denied. installutil.exe installation after rebuilding in VS Express 2013

This is my first time in C#, and I was following this tutorial in order to test out a Directory Monitoring Service. The relevant installation steps is in Step 6:
http://www.rhyous.com/2012/11/27/c-creating-a-service-to-monitor-a-directory/
Step 6 – Install the Service
Open the Developer Command Prompt by right-clicking and choosing Run as
Administrator.
In the command prompt, change to the bin\debug folder in your project
directory.
Run this command to install the service:
installutil.exe DirectoryMonitoring.exe
Start the service with this command.
net start DirectoryMonitoringService
After following the tutorial, my service was able to install and run after building using the Visual Studio Development Console. I then updated my code a little and built it again.
I tried using the same steps to install or run the service via the VSD console again, but I get an Accessed Denied error when I try to do either commands.
I get the following error for the installation:
System.InvalidOperationException: Cannot open Service Control Manager on
computer '.'. This operation might require other priviledges.
The inner exception System.ComponentModel.Win32Exception was thrown with the
following error message: Access is denied.
I also get the following error for net start:
The service name is invalid.
What is going on? I was able to do everything perfectly the first time. Why is it not working now?
If you have the services window open, close it and then try doing the reinstall again.
Also, don't forget to uninstall the service before reinstalling it. However, in my experience, I'm pretty sure that once the service is installed just replacing the EXE with the updated service and restarting it is sufficient and I have gotten away without having to reinstall the service. YMMV.

Silent install msi from a windows service local service account

I am building an auto-updating mechanism. A windows service that runs on a local service account responsible with the auto-updating of a msi.
The service downloads the msi file then it tries to install it using this code:
Process process = new Process();
process.StartInfo.FileName = "msiexec.exe";
process.StartInfo.Arguments = string.Format(" /i \"{0}\" /qn /norestart ALLUSERS=1", sMSIPath);
process.Start();
process.WaitForExit();
Where sMSIPath is a string representing the path to the file, for example "C:\test.msi".
This code, from a regular console application seems to be running fine. I managed to silently install adobe reader, for example.
But from my windows service, it does nothing. According to the logs, i get a warning with this message:
Failed to connect to server. Error: 0x80070005
Where the user is "LOCAL SERVICE" (as i mentioned, my windows service runs as a local service).
Also, the projects have target x86, but i am running a 64-bit OS. (i need them at x86, i want this software to be able to run on multiple operating systems).
Any help is very well received.
Thanks alot!
I don't think you have much chance of making this work. If the MSI tries to access folders like Desktop, User's Program Menu, the CommonFilesFolder (not a complete list) or looks at the LogonUser property and any number of other things it will fail because in a normal install from the interactive user these are all valid properties associated with that installing user. When the installing user is localservice you're likely to be in a mess.
If you need to do this, configure the service to run as a valid administrator account - that might give you a chance of it working better. It's possible that the failure to connect to server error is because MSI files are expected to be run from some kind of user account.
Open service management console Start->Run->Services.msc
Right click on your service and go to properties
On property page select second tab i.e. "Log On"
Check checkbox called "Allow Service to interact with desktop".
Harry Johnston is right, local service doesn't have the privileges to do that. Local system works great though, so i'll use a local system account.
Thank you for your answers, they were all helpful!

Can't debug windows Service VS2010 Win7

I am not able to debug any of my services after migrating from XP and VS2005, to Win7 and VS2010.
I can compile, I can install, I can run the services correctly.
But, I need to debug them. And when I try to attach to the process, I select the running process as I always did on VS2005, and I receive an error telling that I need admin permission.
I am already an administrator. Also, after searching a lot on the internet, I found that running VS2010 as an admin (via right click) should fix it, but I still can't.
I also tried to mark the checkbox on vslauncher.exe properties to run it always as administrator. The VS2010 window shows on top that it actually is running as admin, but again, when I try to attach to the process it says that I need admin rights.
Has anybody any idea about how to proceed?
It was a permissions problem.
Win7 comes with a new security system, and I had to add to my profile (even being an admin) this permission:
Control panel -> Administrative tools -> Local Security policy -> Local Policies -> User rights Assignment -> Debug programs -> Add user or group .
And there, I added my own user. Reboot machine(Important!! Without rebooting, it won't work).
After that, I was able to attach processes to debug them. It's been a really long time to solve this, I hope to help other people that find this same problem.
Thanks everybody for your help.
Edit your service and put the following line into the OnStart() method:
Debugger.Launch(); It's important that you do this in OnStart() rather than a thread launched by OnStart() so that if there is any bug, you can catch it prior to your service crashing.
When your service starts the debugger will open. Windows will then offer to automatically launch an elevated visual studio so you can attach to your service. I find it very useful to put this line in with an app.config setting so you can enable it as required (i.e launch and attach debugger to service).
FYI when you use Vista / Windows 7 you can run apps as administrator. However these apps explicitly reject administrative privileges unless you launch them with "Elevated" permissions. This is a security feature called UAC.

Windows Installer (C#) error code 2869

I have a project, in VS 2005, which has a console application and a setup project associated to install the application. I also have an installer class in the console application that the setup project will use to do some validation before installation. Those tasks are checking the database connection string and checking some directory locations to make sure they exist prior to installation.
I am getting an error code of 2869 when I try to install the application. All the code is written in C#. I have googled for this error code on Windows XP, but only found articles that deal with Vista and Windows 7. Any ideas what might be happening? Is there a workaround?
This won't help with fixing the installer code, but just in case this happens to anyone when doing in install on a Windows 2008 Server you probably need to run the installer from an elevated command prompt:
Open a command prompt with Run As Administrator and then run the
installer
msiexec /i installer.msi
Installer errors are difficult to debug, you can try to :
Look in Event Viewer / Application for logged exceptions
Surround your code with a big try/catch and a MessageBox.Show(ex.ToString()) in the catch clause
Generate a log when installing: msiexec /i "installer.msi" /lvx "log.txt" and look in it for clues
Error 2869 is documented as a dialog issue with the Windows Installer dialogs. The only reason you see it is that the setup is showing the error dialogs and there is a minor issue with it. The true error will be earlier in the log. In other words it's a meaningless downstream error from an install that has already failed. Look earlier in the log for the actual error, which nine times out of ten will be a failed custom action.
To get an idea of what happened, you can use Sysinternals' Process Monitor.
It automatically instruments your operating system and is portable so you just need to do the following:
Download Process Monitor from https://technet.microsoft.com/sysinternals/processmonitor.aspx
Start Process Monitor
Set Filter "Process Name is msiexec.com" to monitor your installer
Start your installer (e.g. setup.exe) (no need to modify or run it with special command line switch)
Check the monitoring log for errors (file access, registry, etc.)
In my case Process Monitor showed me the cause "DISK FULL" at file extraction leading to error code 2869.
I had this error as well and pursued the wrong course going after what was thought to be a "Run as Administrator" issue as explained above and in other forums.
I tried many solutions all dealing with Run as Administrator....Nothing worked.
I built a Windows 10 VM and tested the install in the purest environment I could and got the same error during the installation execution.
At the end of it all....
it turned out I got the error code 2869 because the Serial Number I entered was not valid.
(The serial number I was given by my predecessor had more entries than needed).
Once I entered the correct serial number it turned out "right as rain".

Categories

Resources