I am trying to start up a web role on Windows Azure, but it initializes, goes to busy/stop and continues the endless loop of busy then stop. I have followed the recommendations of this question : Windows Azure Deployment but still no joy. Of course the application runs nicely in the development fabric when I debug
I have done these things so far:
Turned off the diagnostics to ensure azure storage is not used
Made sure that copylocal=true is set for each no microsoft assembly.
Added the Microsoft.WindowsAzure.* references that the sample web role adds
Did a test run of the basic MVC role and that works.
Did a dependency analysis to make sure I am explicity referencing all assemblies using this tool Dependency Visualizer and that they are in the package for deployment. no joy.
Is there a startup log that azure keeps that I can access or similar facility so that I can learn what is failing?
Do you have access to Intellitrace? If you turn that on (VS Ultimate SKU), you can easily download the logs and see why the role is failing to start. Windows Azure Diagnostics is almost certainly not the issue anymore. Back before SDK 1.3, it used to run in the same process as your RoleEntryPoint, which meant you a.) could crash your role if it crashed and b.) if your role crashed, it killed the monitor which made it useless for collecting information. However, the Diagnostics Monitor is now deployed as background task that runs outside of your RoleEntryPoint and it can no longer crash your role. If you turn on Crash Dump collections and Tracing and you should be able to pick those up. In theory your Crash Dump should have the stack trace.
Related
First off, I'm very new to Azure.
I've successfully deployed an ASP.NET MVC 3 web application to Azure, using a web role. The app uses Entity Framework and SQL Azure.
Recently I've done some changes (some including adding appsettings), and tried to upgrade the application. When upgrading, it took quite a long time, before Aborting. I've always deployed through the management portal Silverlight application at http://windows.azure.com.
When trying again to no avail, I setup remote desktop and deployed again. The remote desktop session was extremely slow, and it turned out to be because WaIISHost was putting the CPU to 100%.
The IIS Manager shows that the application is deployed and 'started', however I cannot navigate to the site in the VM, and the deployment constantly seems to be trying to update without success and eventually aborting and retrying, (as I write this, it's currently Busy and Waiting for role to start...).
Does anyone have any ideas as to what the problem could be?
I believe all the right dependencies are set to copy local, which is a possible problem. It is extremely hard to debug this issue, as the remote desktop session hangs so often due to the 100% CPU utilization, and the recycling/restarting/reupdating of the web role from time to time.
Thanks,
James
P.S. Hope some of that made at least some sense...
I doubt that there's something doing in your WebRole.OnStart and/or Run, which caused the WaIISHost uses 100% CPU. Can you remove all codes from the WebRole.OnStart and/or Run and try again.
And it might be helpful to turn on the IntelliTrace when deploying, so that you can download the trace and find out any exceptions occurred when your application started, even before the website started.
I have an Azure solution that I want to debug in Visual Studio 2010. I have two MVC sites set up as Virtual Applications in a single Web Role - this structure makes sense from a cost and url standpoint. The virtual applications worker processes don't spin up automatically and therefor VS doesn't attach to it. After hitting the virtual applicaiton url (i.e. localhost/app1) in the browser, a new w3p process starts and I can manually attach to it. Just wondering if someone out there has done this before and has a tip on how to automatically attach to the process.
Related post that makes it sound like you have to do it manually: http://social.msdn.microsoft.com/Forums/uk/windowsazuredevelopment/thread/f1c5d72b-9196-480e-ace6-3c9063be79a7
This isn't Azure specific, but you could trigger a breakpoint when your application starts:
protected void Application_Start()
{
#if DEBUG
System.Diagnostics.Debugger.Break();
#endif
...
}
And you could try to combine this with a startup task only running when you are in the emulator and that hits the url of both web applications (using wget.exe for example). This will create the w3wp process, triggering the Debugger.Break.
Resource: http://blog.smarx.com/posts/skipping-windows-azure-startup-tasks-when-running-in-the-emulator
For working on multi-site roles, at development time, I have a separate Cloud project for each site, and use a combined one for deployment purposes only. It's not ideal, but it is easier than the whole manual-attach thing.
(For history fans, this practice originally started before the SDK added support for Local and Cloud configuration files. We used to have a Local project and a Cloud project, because otherwise we kept forgetting to switch the connection strings before deploying.)
I have two cloud solutions (.ccproj files). Each has a single distinct web role. One project runs under Compute Emulator without any problems but when I try to run another one (the first one not running) Visual Studio will package it and then display
Windows Azure Tools: There was no endpoint listening at net.pipe://localhost/dfagent/2/host that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
Windows Azure Tools: The Windows Azure compute emulator is not running or responding. Stopping the debugging session.
I'm using SDK version 1.4
I Googled for a while but couldn't find anything that could help me. Force starting the Compute Emulator (csrun /devfabric:start) doesn't seem to help.
How do I resolve this problem?
Although an old question, I got this issue recently and the reason for it was that - while the service or website in azure would have been removed or stopped and you try to publish to it. If this happens, check the publish profile to see that you are pointing to the correct service/site including the storage acc etc and correct them. Hope it helps someone.
I deployed my service package into Windows Azure. Management Portal has been showing "waiting for the role instance to start" for 30 minutes already so I assume something is wrong.
I know that there's Azure Diagnostics, but is there some easier way to find what's going on in my instance - like some console displaying some detailed output or something?
In these cases, it is probably the most expedient to simply RDP into the box and see what is going on. Event logs, hitting the site, etc., from inside the machine usually gives you a pretty good idea. If you have Intellitrace (Visual Studio Ultimate), you can also enable that and suck down the logs to see what is happening. That works very well also.
#dunnry The problem is that you can't open a RDP session to the server if your Azure Role is not running, so you don't know anything what is going on.
Most of the times there is something wrong in your Azure Configuration files. Try removing parts and redeploy afterwards. Pay triple attention to your ConnectionStrings. Make sure that the ServiceDefinition ConfigurationSettings are all defined in the ServiceConfiguration ConfigurationSettings File.
What we basically do is to deploy on a nightly build basis. We can check our ChangeSets of the day before after an instance is not reaching the running state.
If the Azure Diagnostics doesn't tell you anything then I don't think so - no. Somewhat annoyingly, one thing that frequently causes problems is Azure Diagnostics initialization - e.g. if the diagnostics connection string is wrong.
If the role instances start but the app has problems then the remote desktop might help.
If all else fails, try Azure support - it's still free right now.
I'm really loosing it here. Not being able to attach a debugger to a process is kind of a big deal for me. As such, I'm having a very hard time doing something to pinpoint the source of problems with an Azure-hosted application.
What's worse is that the app works fine in the Development Fabric, even when using online Storage Tables, but can go quite haywire when uploaded and running online.
I know IntelliTrace is one way to do it, but unfortunately, I've got a x86 machine, and the application uses RIA Services. As such, publishing it from my machine results in an error caused by RIA services. I can't build the application by specifying x64 the very same bug strikes again. (So far the only way that I know of to deploy a RIA Services Azure application is to set it to Any CPU and build / publish it from an x64 machine).
So IntelliTrace is not available. Online Azure doesn't have something to resemble the nice console log window of the Development Fabric, and as such, I'm at a loss. Thus far I've been just trying to get things to work and not crash by commenting out sections of code, but given the time it takes to upload and start an instance, this is hardly optimal.
Any suggestions would be appreciated at this point.
The Azure SDK has a logging / diagnostics mechanism built in:
http://msdn.microsoft.com/en-us/library/gg433120.aspx.
One route would be to deploy a version with some Azure specific instrumentation built in.
You could try to RDP into an instance of the role and see if there's anything in any of the logs (event or files) that helps you identify where the failure is.
Baring that, I think Amasuriel has it right in that you REALLY need to architect instrumentation into your solutions. Its something that's on my "must" list when building a Windows Azure application.
If you have access to another workstation with an x64 version of Visual Studio, you can configure Azure diagnostics to collect and copy the crash dumps to Blob Storage:
// Must be called after diagnostic monitor starts.
CrashDumps.EnableCollection(false);
You can then download them (using a tool like Azure Storage Explorer) and debug them locally.
If you absolutely need to see what's going on on the console Rob Blackwell has embedded a neat little trick in his Azure Run Me solution.
It pushes the console output of azure instance(s) out over the service bus. You can therefore consume that data locally and in effect monitor the console of the instances running on Azure right on your desktop.
AzureRunMe is available here and it's open source so you can take a look at how they've fed the console output to the SB.
https://github.com/RobBlackwell/AzureRunMe