I have created one service with following build env:
OS : Windows Server 2012
IDE: Visual Studio 2012
Arch: x64
Same service is working fine with Windows Server 2012 but The same service is not starting in Windows Server 2008.
OS : Windows Server 2008 R2
Arch : x64
I am getting following error in Event Viewer
A timeout was reached (30000 milliseconds) while waiting for the service to connect.
Note : I have installed all the necessary VC++ redistributable package needed.
Your Service needs to long to start on the Windows Server 2008 machine. If the timeout is exceeded the service will be stopped. This could be due to different reasons like the following:
slower hardware
slower network connection
different workload
...
I would recommend to create a worker Thread in the starting method of the service. This avoids the Timeout.
protected override void OnStart(string[] args)
{
// Create working thread
Thread serviceThread = new Thread(() =>
{
// do stuff
});
// start thread
serviceThread.Start();
}
Related
First, Docker novice.
Attempting to run a .Net5 Worker Service on a mcr.microsoft.com/windows/servercore:1909 docker image with the .Net5 and 3.1 sdks installed onto the system.
The Service is being installed by a C# program (its part of a larger package) that is using a wrapper for the advapi32.dll to create and otherwise work with the Windows Services and SCM. On other computers, including the host system, the service is installed correctly and will continue running. After installation on the docker image, the service (startup as AutomaticDelayed) is created but will return "The service did not respond to the start or control request in a timely fashion" as the only error.
Both from viewing the logs and running the service manually (from powershell) on the docker container, the service will continue running until the SCM kills it from timeout. I have extended ServicesPipeTimeout registry item to 10 minutes and the SCM will still timeout the application after it fails to respond.
Any thoughts?
EDIT: Had question about using .UseWindowsService() but we were already using that. This is the program main that all our services are using.
public class Program
{
public static void Main(string[] args)
{
if (!IsDebug())
System.IO.Directory.SetCurrentDirectory(System.AppDomain.CurrentDomain.BaseDirectory);
CreateHostBuilder(args).Build().Run();
}
public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.ConfigureServices((hostContext, services) =>
{
services.AddSingleton<SingletonHandler>();
services.AddHostedService<Worker>();
services.AddHostedService<Listener>();
})
.ConfigureLogging((hostingContext, logging) => {
logging.AddConfiguration(hostingContext.Configuration.GetSection("Logging"));
logging.AddFile(hostingContext.Configuration.GetSection("Logging"));
})
.UseWindowsService();
}
EDIT EDIT: I am attempting to run this on a Windows Server Core image if possible. I don't know if that messes with the capabilities of Worker Services.
you should call .UseWindowsService() when configuring your host builder. The method is contained in the package Microsoft.Extensions.Hosting.WindowsServices
I'm doing some performance testing on ASP.NET Core 3.1. I've created a dummy web app that just returns a statically allocated struct as shown below:
[Route("api/[controller]")]
[ApiController]
public class DummyController : ControllerBase
{
private static State _state = new State();
public State Get()
{
return _state;
}
}
When run under IIS this app supports requests/sec that is half of what it can achieve under Kestrel. Under IIS it unable to exhaust the CPU capacity whereas within Kestrel it maxes out all cores. Does anyone know of common reasons why this could be? I've googled it and found people reporting the opposite problem (i.e slower under Kestrel), but not this.
I'm running the app InProcess under IIS. IIS version is 10 and the OS is Windows 10 1903. The machine's got 16 cores and 32 logical processes. I'm testing using bombardier via loopback (i.e. bombardier is running on the same machine as the app).
The problem was due to me running the app on Windows 10. It went away and IIS's performance started to match that of Kestrel's as soon as I moved the app to Windows Server 2016.
I am attempting to set up a controller and agents for a Visual Studio 2013 web performance test, and when configuring the agent receive the error message "Failed to register this test agent with the test controller. Connection to the test controller MyController:6901 failed because either the test controller is accessible or the service is not running."
The detailed error message from the log is: "System.Net.Sockets.SocketException (0x80004005): No such host is known"
I downloaded "Agents for Microsoft Visual Studio 2013," from http://www.microsoft.com/en-us/download/details.aspx?id=40750
The controller MyController is a 64-bit physical machine running Windows 7 Professional SP1. MyDomain\MyUser is an administrator on this machine. Windows Firewall is not enabled.
I logged into the controller machine as MyDomain\MyUser and ran the controller install. I specified the logon account as MyDomain\MyUserName and checked "Configure test controller for load testing."
After the install I found:
The service "Visual Studio Test Controller" running under the identity of the domain user account MyDomain\MyUser.
The documentation says the service listens on port 6901 by default. The service resides at C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\QTController.exe. When I look in QTController.exe.config I notice the appsettings key ControllerServicePort is set to "6901", which is the default value.
When I run netstat -a -n I see TCP 0.0.0.0:6901 0.0.0.0.:0 LISTENING, so it looks like the machine is listening on port 6901 and taking all callers.
MyDomain\MyUser is in the Administrators group on the controller machine.
MyDomain\MyUser is in the TeamTestControllerUsers group on the controller machine. This group was created by the Visual Studio controller installer and MyDomain\MyUser was added by the installer.
I can successfully ping MyAgent.
I rebooted the machine.
The problem comes when attempting to configure the agent.
The agent machine is a 64-bit virtual machine running Windows 7 Professional SP1. MyDomain\MyUser is an administrator on this machine. Windows Firewall is not enabled.
I logged into the agent machine as MyDomain\MyUser and ran the agent install. At the end of the install the "Configure Test Agent" dialog appears. It asks 2 questions:
Run test agent as a service. I entered MyDomain\MyUser.
I checked "Register with Test Controller" and entered "MyController:6901" and click Apply Settings.
The error message is "Failed to register this test agent with the test controller. Connection to the test controller MyController:6901 failed because either the test controller is accessible or the service is not running."
The test agent has a detailed error log. Here is the relevant section:
I, 2015/03/26, 09:35:57.872, AgentConfiguration: Found agent is not configured on any controller.
I, 2015/03/26, 09:35:57.872, Getting information about controller: MyController:6901.
I, 2015/03/26, 09:35:57.872, Creating Channel
I, 2015/03/26, 09:35:57.997, CreateControllerObject : ControllerVersion : 12.0
I, 2015/03/26, 09:36:02.943, CreateControllerObject: attempt 0, System.Net.Sockets.SocketException (0x80004005): No such host is known
Server stack trace:
at System.Net.Dns.GetAddrInfo(String name)
at System.Net.Dns.InternalGetHostByName(String hostName, Boolean includeIPv6)
at System.Net.Dns.GetHostAddresses(String hostNameOrAddress)
at System.Runtime.Remoting.Channels.RemoteConnection.CreateNewSocket()
at System.Runtime.Remoting.Channels.RemoteConnection.GetSocket()
at System.Runtime.Remoting.Channels.SocketCache.GetSocket(String machinePortAndSid, Boolean openNew)
at System.Runtime.Remoting.Channels.Tcp.TcpClientTransportSink.SendRequestWithRetry(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream)
at System.Runtime.Remoting.Channels.Tcp.TcpClientTransportSink.ProcessMessage(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream, ITransportHeaders& responseHeaders, Stream& responseStream)
at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage(IMessage msg)
I rebooted MyAgent and get the same error.
From MyAgent I can successfully ping MyController.
From MyAgent I can telnet MyController 6901 and get the blank screen (which means the port is open).
I attempted the fix noted here (http://support.microsoft.com/en-us/kb/2823477), to append the DSN suffix of the domain of the controller machine to the TCP\IP settings for the NIC on both the controller machine and the agent machines. Since MyAgent and MyController are able to ping each other using only the machine name I did not expect this solution to work, and it did not work.
I repeated this agent install on a Windows 7 64-bit physical machine (instead of a virtual machine) and recieved the exact same error.
There are hotfixes for previous versions of Visual Studio (eg http://support.microsoft.com/en-us/kb/2643086), but nothing for VS 2013.
Our agent machines were on a different subnet from the controller machine.
When we moved the controller to a machine in the same subnet as the agent machines, it began working.
This might be caused by using a physical machine for the controller and virtual machines for the agents, but that is speculation.
I am trying to use MSMQ queue inside Mule flow;Going by the docs here, I find we need to run Anypoint Gateway as a service. The service wont run and gives error:
"Error 1053: The service did not respond to the start or control request in a timely fashion"
System:windows 7 professional desktop 64 bit;
How to resolve the issue?
Info from System logs:
A timeout was reached (30000 milliseconds) while waiting for the Anypoint Gateway service to connect.
Info from Application logs:
The program AnyPoint-Gateway-Service.exe version 1.0.0.0 stopped interacting with Windows and was closed. To see if more information about the problem is available, check the problem history in the Action Center control panel.
Error from MSI installer:
Product: Anypoint Gateway for Windows -- Error 1920. Service 'Anypoint Gateway' (MuleMSMQService) failed to start. Verify that you have sufficient privileges to start system services.
I have admin privileges to install any service and running on .NET 4.03 platform.
The Mule Doc says for a .NET 4.0 prerequisite.
But I resolved the above error by:
1.Updating to .NET 4.5 platform
2.Running the Anypoint-Gateway.exe as compatible for windows 7(tweaking the properties of exe).
3.Also check if you have admin rights.
I just installed Visual Studio 2012 RC and tried to run a service with netHttpBinding enabling WebSocket and get the following error:
This platform does not support server side WebSockets.
The sample I am running is from http://blogs.microsoft.co.il/blogs/idof/archive/2012/03/01/what-s-new-in-wcf-4-5-websocket-support-part-1-of-2.aspx
Can WebSockets work on Windows 7 with Visual Studio 2012 RC?
No, websockets is only natively supported by Windows in Windows 8, regardless of which visual studio version you are using.
http://www.paulbatum.com/2011/09/getting-started-with-websockets-in.html
This is due to some low level issues in Windows 7 with http.sys.
There's an offchance it may be backported, but seems unlikely: http://weblogs.asp.net/owscott/archive/2012/03/01/what-s-new-in-iis-8.aspx
To use websockets on Windows 7, you'll have to write your own service.
Try using this for clientside: http://websocket4net.codeplex.com/
and this for server side: http://superwebsocket.codeplex.com/
I ran into the same problem and solved it by using Fleck. Trivially simple to implement:
One. NuGet add Fleck reference
Two. Create your webserver socket
// Create Websocket server
websocketServer = new Fleck.WebSocketServer("ws://localhost:82");
websocketServer.Start(socket =>
{
socket.OnOpen = () => Console.WriteLine("Open!");
socket.OnClose = () => Console.WriteLine("Close!");
socket.OnMessage = message => socket.Send(message);
});
I now have a a ASP.NET Self Host web API on one port and the websockets connection running along side it.