I'm trying to connect to a C# service. I can view the service in Windows Task Manager, but it does not appear in the "Available processes" List. I've tried running VS2012 as my normal user, as administrator, with "Show processes from all users" and Managed (v4.5, v4.0) code instead of the default. The service is built in Debug mode and then installed using an installer(Wix). On every demonstration of this, I've seen "Show Processes In All Sessions" but this is not shown in my Attach to process dialogue.
I managed to connect from a command line using "vsjitdebugger.exe -p 7012" but this wants to debug in a new instance, and should I use that new instance, I can't see any of the code.
Any advice would be really appreciated.
Related
My console application is responsible for starting a WCF service in interactive mode (ie. the service does not get installed as a Windows service in that case).
In order for my application to start the latter, the application invokes the compiled executable using the following method:
static bool AutoStartService()
{
var MyProcessFile = System.IO.Path.GetFullPath($"pathToExecutable/MyServiceExe.exe");
Process myProcess = new Process();
myProcess.StartInfo.FileName = MyProcessFile;
myProcess.StartInfo.Arguments = "";
myProcess.StartInfo.WindowStyle = ProcessWindowStyle.Normal;
myProcess.Start();
Thread.Sleep(WaitForTheServiceToStart);
}
return true;
}
Note that this approach works just fine when debugging from Visual Studio.
However, when the console application is invoked from Jenkins (note that I gave Jenkins admin access and it logs in as a normal user), then the service process does not seem to stick or be visible from the Console application. I can tell it at least starts and stops as I can see the logs being written to file.
The Console application is started using a batch command from Jenkins (I also tried using Powershell, but without luck).
Any suggestion on how to do that?
I have tried with both debug and release builds of my Console app C# project, but it makes no difference.
EDIT
I have edited the following properties, but without success:
myProcess.StartInfo.UseShellExecute = false;
myProcess.StartInfo.Environment.Add("BUILD_ID", "dontKillMe");
I am now seeing the following warning, but I don't believe installing the service is the only way to go as this is what I am doing when running this code without Jenkins and it works. Maybe Jenkins does not allow it though?:
Cannot start service from the command line or a debugger. A Windows Service must first be installed (using installutil.exe) and then started with the ServerExplorer, Windows Services Administrative tool or the NET START command.
EDIT2
I went a step further. The reason why I was getting the former message is that the service checks "Environment.UserInteractive" to either run as interactive or to start/run the installed service. For some reasons this flag is always set to false, while it should be true in my case.
Is there a way to fool the service to think that flag is true?
I am trying to follow this tutorial to run azure function app using C# using vscode.
But when I click the run button, it shows "You must have the Azure Functions Core Tools installed to debug your local functions." But I have actually installed it in my mac. When I click the install button, it shows errors like follows:
/bin/bash: func: command not foundThe terminal process "/bin/bash '-c', 'func host start'" failed to launch (exit code: 127).
And on the right bottom there is a small window showing:
Error exists after running preLaunchTask "host start". View task output for more information.
But when I use the command func host start in my local terminal, it can run smoothly.
We have tried the same but on Windows(OS) , Below are the workaround to resolve the above issue.
Created a new Azure function with HTTP Trigger using .net 6
Before debugging we have started the Azure storage Emulator/Azurite on local.
Or Alternatively, We can add "AzureWebJobsStorage": "UseDevelopmentStorage=true", in our localsettings.json and tried to debug by using .net Function.
OUTPUT DETAILS FOR REFERENCE:-
NOTE:- To run function locally based on the given MICROSOFT DOCUMENTATION:-
Click on Ctrl - (macOS) the HttpExample function and choose Execute
Function Now
Or, we can add a breakpoint over our function.cs file and type start debug as shown below :-
For more information regarding VS CODE on macos configuration Please refer this SO THREAD discussions .
I have a service that runs and accepts remote commands. I am trying to send a remote command to uninstall. This works and executes the msiexec. The msiexec gets to the point where it tries to stop the service and then hangs and eventually fails saying no privileges to stop the service.
If I run the same command from a command window it works fine.
I have tried this running the service as local system (with admin privs) as well as administrator (I enabled the administrator account)
I just can't seem to figure out why I am getting permission errors stopping the service running the msiexec
added information
We have a single service - it does required work and sleeps periodically
the service typically runs as local system
we have the installer set using custom actions - and all cases work fine - installing and uninstalling from command line - but running msiexec uninstaller initiated within the C# code has this issue
When a remote request is made to uninstall the desire is to remove the service, registry entries, and files on disk
The request is handled by the running service - it goes to the registry, finds the product entry and retrieves the uninstall command
when the uninstall is performed I use C# process and include in the StartInfo parameters the program name, arguments, and verb (defined as run as) - among other parameters
the uninstaller starts properly, does some actions, and then gets to the point of stopping the service
stopping the service sits until it times out after which it writes in the uninstall log that there may not be sufficient privileges to stop the service
The note from Quercus triggered the solution to my problem. It turns out changing to not run the uninstall as a child of the service allowed the uninstaller to perform the msiexec without issue. To accomplish this I had to change UseShellExecute from false to true.
I run into the problem where VSCode prompts
Debug adapter process has terminated unexpectedly
For a C# project created using console template; when I debug it by pressing "F5" key.
I do not have any problems in compiling the project.
I have performed dotnet run on the project folder. I see the "Hello World" printed on the command prompt without any problem.
My version strings
VSCode : 1.14.2
dotnet : 2.0.0-preview2-25407-01
C# extn : 1.11.0
OS : Microsoft Windows NT 6.1.7601 Service Pack 1 (Windows 7 - 64 bit)
I do not have any info in event log.
How do I tackle this error?
[Update]
OmniSharp debug server is exiting/closing when they are launched suspiciously!
Where do I collect the log for the OmniSharp debug server?
I do not have anything printed on my Output window in VS Code. I do not even see OmniSharp log source in the Output filter dropdown.
[Additional information]
Noted same error when I run the application in non-debug mode as well using "Ctrl+F5" key.
Browsed VS Code's source code in github; the error message appears when debug server is not in disconnected state while exiting the server. Pursuing further on building a call graph, onServerExit are called
1. close event of the socket create in [connectServer] (https://github.com/Microsoft/vscode/blob/fbece01268f4e5d290a470b328eea6312069eda0/src/vs/workbench/parts/debug/electron-browser/rawDebugSession.ts#L433)
2. exit event of the debug server process launched in [startServer] (https://github.com/Microsoft/vscode/blob/fbece01268f4e5d290a470b328eea6312069eda0/src/vs/workbench/parts/debug/electron-browser/rawDebugSession.ts#L437)
Now my question gets refined to why is the debug server exiting / closing when they get created?
Could this be due to permissions or port numbers or something else? Where should I look for such problems in my machine?
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!