I reckon my applications close down whenever my Azure VPS is disconnected (click the "X" at the top of the screen - NOT logging off). I have my MetaTrader programme running and not every trade is being executed whenever my pre-determined conditions are met.
I've looked at my logs for MetaTrader and there are no trade errors, no explanation as to why my trades are not executing. I've also looked at journals and there are no errors there either.
I've looked up my Windows Event Logs & I can't find anything for the MT4 application either.
The absence of error messages in my logs would say that my MT4 application is shutting down whenever I disconnect (resulting in no trades being executed - which is what you'd expect from an MT4 application that isn't running in the first place).
On the logs, it states that all symbols & EA's are being initialised - surely this shouldn't be saying this if they're running already.
Its bizarre and cannot get to the bottom of this. Can anyone shed some light on this and am I "barking up the wrong tree" as they say? Thanks in advance.
In a nutshell: Not all of my trades are being executed, & the presence of "initilsation logs" would indicate that MT4 is shutting down upon disconnection when its supposed to be running continuously.
You could try running the application as a service, this would allow the application to run in its own session and would not quit event after logging out:
Microsoft Windows services, formerly known as NT services, enable you to create > long-running executable applications that run in their own Windows sessions. > These services can be automatically started when the computer boots, can be paused > and restarted, and do not show any user interface.
Source: https://learn.microsoft.com/en-us/dotnet/framework/windows-services/introduction-to-windows-service-applications
Full steps on how to create a service:
https://learn.microsoft.com/en-us/dotnet/framework/windows-services/how-to-create-windows-services
Related
I have implemented a Windows Service in .NET 4 and C# using Visual Studio 2015. In the OnStart method, my service creates a "Worker Thread" which loops, blocking on an AutoResetEvent (connected to a Timer). The "Worker Thread" also has a CancellationTokenSource that it manually polls to check whether it should stop working. The OnStop method first Cancels with the CancellationTokenSource and then signals with the AutoResetEvent, waking up the Worker thread which notices that "cancel" has happened, and which then exits.
This Windows Service works fine on Win7. I've installed it on Win10 a few times and it worked fine - until yesterday where I saw a logfile which said the Worker Thread had, as expected, blocked on the AutoResetEvent, but: that worker Thread never got to the next statement in my program. It never woke up, didn't execute another statement. 94 seconds after it blocked, the service ended.
Note that in this scenario my OnStop method was not called.
The process as a whole had not been killed - there's a thread which comes in (threadID 1) presumably from the SCM or the OS, and which blocks until my service dies - that thread logged a few messages on the way out.
Here's my question: are there conditions where the Windows Service Control Manager (SCM) feels it necessary to actually kill off application threads? Can anyone explain why my thread died?
Short Answer to the Original Question
I discovered that restarting the machine caused my thread to die (interesting that the Windows-allocated thread didn't die, it just exited - I guess that's how the SCM cleans up services when it is told to shut down).
Longer Answer - Now I have a New Question
I didn't realize that I was barking up the wrong tree. My client app was saying the service was unavailable and I assumed it was because of what I described above - because it was getting killed off.
Not the problem - the problem was that once the service was stopped (because of shutdown), it was not getting restarted again!
So why didn't my .NET 4 Automatic service get automatically started, in Win10? That's a different question.
The New Answer
I have since posting my original question, found several postings that answer the new question:
Automatic Windows 10 service doesn't start up
Automatic Services don't start automatically after windows restart
Automatic Services not starting on Win10 upgrade machine
So the diagnosis was that Win10 was doing some kind of combination of slowing down the startup of my .NET 4 service, and then punishing the service for its slow startup by killing it before it can start executing my code.
I did find System Event log entries that support this.
The solution for me turned out to be changing my "start type" from "Automatic" to "Automatic (Delayed)".
Some relevant links for me:
Automatic vs Automatic Delayed Start
Set service StartType in WiX
I hope all this helps someone else out there.
I have a Azure Web Site running for 6 months and on Friday 1st April 2016 at 09:50pm the CPU was very high and this had a impact on the performance of the web site. Stopping and restarting the web service solved the problem but it came back at 13:00pm. Since then the CPU has stayed high and making the web site un-useable
I've tried all monitoring tools, Daas, Event Logs, checked for Open Connections and ensure my software is closing or disposing objects correctly.
But the CPU is still high. Only way to resolve is to restart the web service but I dont want to keep doing this.
Has anyone else experience a similar problem and what was the solutions.
The only thing from the event logs that look an issues is the odd "A network-related or instance-specific error occurred while establishing a connection to SQL Server", which could be because the SQL Aure is not available.
Please help
Hmmm, high cpu means that your web site is executing code, perhaps a wrong loop on some not frequent code path.
The brute force way to identify what code is being executed, would be to add tracing to your solution by System.Diagnostics.Trace.WriteLine("I am here") and then check the Azure Application Log.
Another way would be to attach the Visual Studio Debugger during high cpu and check what is being executed
The other way would be to take a dump or minidump from kudu site and analyze it with WinDbg:
1)What thread is conuming cpu:
!runaway
2) What is this thread doing:
!clrstack
hth,
Aldo
I have a worker role deployed that works fine for a period of time (days...) but at some point it stops or crashes, then it can't restart at all and stays "Cycling...". The only solution is to Reimage the Role.
How can I set an automatic alert so I get an email when the Role becomes unresponsive (and Cycling...) ?
Thanks
Alerts or notifications like this are not available today, but they are being worked on. If this is causing service interruptions you could always sign up for an external monitoring service which will send you alerts whenever your site is down.
However, I would recommend solving the root cause of the problem rather than just Reimaging it to fix the symptom. Here is how I would start:
You are most likely hitting the issue described in http://blogs.msdn.com/b/kwill/archive/2012/09/19/role-instance-restarts-due-to-os-upgrades.aspx. In particular, see #1 under Common Issues where it talks about common causes for a role to not restart properly after being rebooted due to OS updates. Notice that #1 also talks about how to simulate these types of Azure environment issues (ie. manually do a Reboot from the portal) so you can reproduce the failure and debug it.
To troubleshoot the issue I would recommend reading through the troubleshooting series at http://blogs.msdn.com/b/kwill/archive/2013/08/09/windows-azure-paas-compute-diagnostics-data.aspx. Of particular interest to you is probably the "Troubleshooting Scenario 2 – Role Recycling After Running Fine For 2 Weeks"
Azure cannot notify you of such conditions. Consider placing a try/catch around your loop in the WorkerRole with a catch that can email you in case of an issue.
Alternatively, if you're open to using third party services, consider AzureWatch (I'm affiliated with the product). It can alert you in case your instance becomes Unresponsive, Busy, or goes thru other non-Ready status
Using a large instance of a virtual machine on Windows Azure. The instance runs Microsoft SQL 2012 with light usage, on Windows Server 2012 + all up to date. No user is logged in at time of failures.
However, several (between none and three) times a day (appears random), the VM halts and shuts down. It does not come back online until someone logs back into the Management Portal and starts the VM again. There is no memory dump created. So I am guessing the host halts the running VM, rather than some configuration instance within the guest OS causes the halt. The subscription has billable funds. Other VMs in the subscription are also affected.
Only event logs generated:
Kernel-Power logged:
The system has rebooted without cleanly shutting down first. This
error could be caused if the system stopped responding, crashed, or
lost power unexpectedly.
Kernel-Boot logged:
The last shutdown's success status was false. The last boot's success
status was true.
How can this be resolved? There is no way to initiate a support request within Azure.
The first point I would do is install some monitoring software like newrelic or foglight and see if you can see if you are running out memory or a process is pushing the CPU into a spin.
This will give you some visibility of the activity on the box over time and give you some evidence should you need it to open a support request.
Azure now has paid support only
http://www.windowsazure.com/en-us/support/plans/
We use developer for exactly this type of situation where you are bit lost to figuring out a situation the cost of $30 dollars compared to running a SQL Server 2012 VM per month makes it worth having. The support under Microsoft are generally very good and they will have more diagnostic information and will be able to give you the heads up if this is because of Azure failure or something else.
Getting diagnostic going though would be first port of call then you can see what is going on and get some evidence together and help you track down the problem.
We have WFF 2.5 installed, and have used it to successfully configure a farm and provision a secondary server in our test environment.
Our environment (controller, primary, secondary servers) is Windows 2008 Server Web Edition R2, running IIS 7.5, with WFF 2.5 installed.
We have ongoing issues with a .tmp file in an app pools related directory being locked. Process Monitor indicates that it is the worker process (w3wp.exe) locking the file.
The exact error message is Failed to run operation "ProvisionApplications". Failed to run method "Microsoft.Web.Farm.SyncApplicationsRemoteMethod" on server "abc". Exception in response stream. An error was encountered when processing operation "Delete File" on "ABC85DA.tmp". The error code was 0x80070020. The process cannot access "C:\inetpub\temp\appPools\ABC85DA.tmp" because it is being used by another process
If I shut down the Windows Process Activation Service which AFAIK hosts the worker process, the error is disappears.
Obviously, however , to bring the server online, we need to start the service, and as soon as we do, the automated provisioning step fails, and WFF marks the server as unhealthy, and takes it out of the farm.
I have tried to turn Application Provisioning off by unchecking "Enable Application Provisioning" under the Application Provisioning Module, but the operation still seems to fire every 30 seconds.
So - two problems really:
How to solve the file locking issue on the App pool temp file.
How to turn off automated application provisioning operation on
secondary servers? (this is really a second prize workaround in case
there is no solution to problem 1)
TIA
Rebooting the ARR server caused the server to stop attempting to repeatedly provision the secondary servers (in other words applied the "Enable Application Provisioning" option, which I had turned off)
Otherwise, I think the locking issue would still occur. This may not be an issue, since you can turn off the Windows Process Activations Service while initially provisioning the service, and during any subsequent application provisioning intended to synch the servers.
Automated provisioning on a schedule will still be an issue, I suspect.