I'm trying to run a WebRole on my local machine via Compute Emulator. My Compute Emulator and Storage Emulator is running fine. When I hit F5 in VS2010, I can see the action in Compute Emulator. But after a while, I get an exception in VS2010;
Microsoft.WindowsAzure.Hosts.Worker.RuntimeEnvironmentException was unhandled
Message=Unable to load the runtime environment: could not get hosting environment settings
Source=WaWorkerHost
StackTrace:
at Microsoft.WindowsAzure.Hosts.Worker.Parameters..ctor()
at Microsoft.WindowsAzure.Hosts.Worker.Loader.Main(String[] args)
InnerException:
Then Roles in Compute Emulator begins to shutdown. VS2010 launches the browser with IP and port but no luck, it's not running of course.
I don't think this is a coding error because I live the same problem even in an empty out-of-the-box Azure project and a single Web Role on it.
I've searched the net but no info about this error. Actually if you search exactly for "RuntimeEnvironmentException" Google returns zero result. Using the description words also does not make any sense.
Anyone have an idea?
Thanks,
Ali
Sorry for not responding earlier but I was still working on the issue. Then a Microsoft guy from Turkey office figured it out. There is a problem with localization on developer machines. In development environment computers, in "Region and Languages", set "Format" to "English (United States)" and "Current Location" to "United States". After setting these, Azure emulator is working flawlessly. They said this is a known issue and they're preparing a report about this. I hope this will be resolved in next releases.
Hope this helps to anyone who live same problem. And thanks everyone who tried to help...
Ali
I've had a similar issue where the compute emulator just fails to load my web role and nothing ever responds. It seems to happen to me when I hibernate my laptop a few times while the compute emulator is running. Even shutting the emulator down and restarting it doesn't seem to help.
Best solution I've found is to reboot. Definitely not elegant (and a bit of a pain in the butt), but it's worked for me every time.
Not sure if this helps or not. Good luck.
Related
An automated Windows update this morning left my Windows Server 2012 R2 Classic Virtual Machine on Azure in a semi-crashed state. The VM is a web server, and all the files and applications in it are still accessible via the browser. In other words, IIS and a number of other services are still running. Unfortunately, however, the VM is not accessible via Remote Desktop and is unresponsive to commands from the Azure management interface on the portal.azure.com website.
This type of error is quite common and can be found reported on many other websites. The error has been happening to Windows users (not just Windows Server) for many years already, and none of the solutions online will work for Azure users, because they involve restarting from a CD, pressing shift-f8 during boot, issuing DOS commands, restoring from backup, or unchecking certain properties in VMWare or other software.
Does anybody have a real solution for this problem on Microsoft Azure?
After struggling with this for weeks, I think I was able to fix this with the help of Microsoft support! I decide to post the solution here in case it can help someone in the future. Here are the three things that you need to do to fix this:
1-Restore the VM from a backup prior to the crash. The VM with the "Undoing Changes" crash is pretty much toast at this point. Now, proceed to steps 2 and 3 to ensure that the next batch of Windows Updates won't crash it again!
2-On your new VM, ensure that the Environment Variables for TEMP and TMP both point to C:\Windows\TEMP. In my case, they were both pointing to a temporary folder in the logged in user's profile.
3-Ensure that C:\Windows\TEMP is always empty. I achieved this by setting up a scheduled task that runs a simple BAT file that deletes all files and folders inside of the C:\Windows\TEMP once a day. I spoke with a Microsoft representative who said that even though you may have plenty of hard drive space in your C:\ drive, the Windows TEMP folder is really not supposed to get much bigger than 500MB. When it gets very large you may have some issues with Windows Updates (mine was just under 500MB when the updates were failing).
I would recommend contacting Azure support as something may have to be done by an engineer to fix the issue and unfortunately classic VMs don't have the redeploy feature.
I've added only InboundPort 3389 RPD, and works well now.
I have a webAPI deployed on window azure, till last week I was able to run the WebAPI and debug but all of a sudden when I run the web application I get the below message.
Role instances are taking longer than expected to start. Do you want
to continue waiting?
And I tried to enable disable caching(default caching is disable) and also cleared the local storage but still the same issue persist, its happening in not only my machine but also on other dev machine as well. Could it be because of automatic software updates related to emulator or other SW or any other issue?
Happened withh me today. I ran into an issue of the Azure emulator not working. The roles were going in a continuous loop of Running, Busy and Suspended.
Initially I thought it might be due to some code I had changed ď. However, it turned out that a recent Windows update had caused this issue.
After spending a frustrating amount of time un-installing the recent updates one by one, I found the miscreant.
For Fix please un-install the Security Update KB3126593 (https://support.microsoft.com/en-us/kb/3126593).
While searching for the particular update, make sure you type âKB3126593â in the search bar. Typing 3126593 will not work.
I've been successfully using Azure for months. Today I'm getting the following error when I publish from via Web Deploy from Visual Studio 2013
Error 5 Web deployment task failed. (Could not connect to the remote computer ("waws-prod-hk1-001.publish.azurewebsites.windows.net"). On the remote computer, make sure that Web Deploy is installed and that the required process ("Web Management Service") is started. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_DESTINATION_NOT_REACHABLE.)
I tried downloaded a new Publishing Profile from the Azure Dashboard and turning off my firewall - no change.
I can't ping the listed server.
It seems to be the same issue as http://social.msdn.microsoft.com/Forums/windowsazure/en-US/83d4e635-2851-4526-b21b-31101d00aa86/web-deployment-task-failed-errorcouldnotconnecttoremotesvc?forum=windowsazurewebsitespreview
Any ideas? Thank you.
I had the exact same problem for a couple of days (sometimes I could published and sometimes not).
The problem was my internet configuration (not related to Microsoft or Azure in anyway).
To solve this issue I disconnected my modem (its actually modem+router) for 10 min and reconnect it and it was fixed!
Hope it will help someone someday...
Nevermind. It would appear that Azure was in a 'challenged' state.
It's working fine now..
What worked for me was disabling and re-enabling my network adapter.
The reasoning is, quite possibly naive, that having Fiddler running during a deployment will fail but it also changes the network state and that state continues
to exist even after exiting Fiddler (which disables the proxy).
Recently I published to my Azure Staging server (Asp.Net MVC App) and my app wouldn't come up. I checked the Event logs on the machine, and this was the error:
.NET Runtime version 4.0.30319.18033 - Loading profiler failed during
CoCreateInstance. Profiler CLSID:
'{F1260058-1A1F-4738-8BE2-0BF9D3A64219}'. HRESULT: 0x8007007e. Process
ID (decimal): 1872. Message ID: [0x2504].
The thing is that I am not using a profiler, everything worked fine yesterday (day old publish) - any ideas what could be causing this, and how I could fix it? Thank you.
Not to say there is not a better fix (I tried all I could find elsewhere, nothing seemed to relate to my specific problem) but here is what I ended up doing. Simply delete your deployment, and re-publish. This must re-set whatever turning on your profiler sets.
Remember that if this is a non domain dns instance, your address will be changed. Hope this can save someone a few hours.
Blog Post Here
I just built a simple hello world windows azure service containing just one web role, I used visual studio 2008 and Windows azure tools for VS 1.2 I am pretty new to this and I have been trying to deploy an application all afternoon now. I'm in australia and deploying in the region Asia anywhere.
I have pretty much followed the info provided on MSDN and it says uploaded 95% then after about ten minutes the deployment disappears. I have tried using the old windows azure developer portal and 30minutes later I can not access the service and it's status is either busy or stopped.
I have the introductory offer for an extra small compute instance on the subscription I am deploying to. Can anyone with experience with windows azure elaborate on the subject of deploying apps and the status on my application, I am very keen to get into the platform and this issue has just about spoiled my weekend.
Most likely it is related to the UseDevelopmentStorage=true for a connection string. I have accidentally done this a couple of times myself and things just magically don't work and there is no explanation. Missing DLL's are usually a little harder to track down as the application may or may not start depending on where the failure happens. Trace logging and/or infrastructure logging is the best way to find out if the DLL is missing if you can get your application to run that far.
As pointed out already, the best place to start is making the simplest "Hello World!" you possibly can and start extending from there. Yes it will take you a while to make progress but the experiences you gain from this will be invaluable moving forward.
Two things to check before deployment
1. Change Roles' Connection Strings to point to Azure Storage instead of UseDevelopmentStorage
2. All References not belong to asp.net framework should be set to "Copy Local=True"
I would guess that the deployment is going successfully but that the role instances are not able to start. The most common causes of this are eithe referrences to development storage while deployed (UseDevelopmentStorage=true) or a referrence to an assembly with copylocal!=true.