Azure Cloud Services Not Working, Diagnosed and Fixed (2026 Guide)

When an Azure Cloud Services role instance is recycling, the single best source of truth is the Microsoft Azure Event Log. This isn't the Windows Application or System event log you're thinking of, it's a separate log that captures Azure-specific diagnostics: role starts and stops, startup task execution, OnStart and OnRun lifecycle events, crashes, and recycle events. Most developers skip straight to their application logs and miss it entirely.

To access it, you'll need to RDP into a healthy role instance (if you have multiple instances and at least one is running) or use Azure Diagnostics to pull logs remotely. Go to the Azure portal, navigate to your Cloud Service, click Roles and instances, select the problematic instance, and click Connect to download the RDP file.

Once connected, open Event Viewer (search for it in the Start menu or run eventvwr.msc). Expand Applications and Services Logs → Microsoft → WindowsAzure → Status. Look for recent Warning or Error entries.

What you're looking for is something like this:

AppDomain Unhandled Exception for role ZipEngine_IN_0
Exception: Could not load file or assembly 'WorkerAssembly,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
or one of its dependencies. An attempt was made to load a
program with an incorrect format.
at ZipEngine.WorkerRole.OnStart()

That stack trace tells you everything: the exception is thrown from OnStart(), the assembly it can't load is WorkerAssembly, and the reason is BadImageFormatException, a platform mismatch. The process hosting the worker role, WaWorkerHost.exe, is a 64-bit executable and it's refusing to load a 32-bit DLL. Once you've confirmed this in Event Viewer, you know exactly what you're fixing.

If the Azure Event Log shows a different error, a null reference, a missing config key, a database connection timeout, that's valuable too. The role recycling loop is always caused by an unhandled exception somewhere in your lifecycle code. Find the exception in this log first, then fix the actual problem.

When Event Viewer confirms you have a System.BadImageFormatException or a generic assembly load failure, the next layer of detail comes from the .NET Assembly Binding Log, commonly called the Fusion Log. This is built into the .NET runtime and records exactly what the CLR tried to load, where it looked, what it found, and why it failed. It's incredibly precise.

To enable Fusion logging on the Azure role instance, you'll need to make registry changes. While RDP'd into the instance, open Registry Editor (run regedit as Administrator). Navigate to this path:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion

If the Fusion key doesn't exist, right-click Microsoft and choose New → Key, name it Fusion. Then create the following DWORD values inside it:

EnableLog        = 1
LogFailures      = 1
LogResourceBinds = 1
LogPath          = C:\FusionLogs\

Now create the C:\FusionLogs directory and grant the Everyone group Full Control permissions on it. Right-click the folder → Properties → Security → Edit → Add → type "Everyone" → Full Control → OK.

Restart the role instance from the Azure portal (Roles and instances → right-click → Restart) so it attempts the failed assembly bind again with logging enabled. Then check C:\FusionLogs. You'll find one or more .htm files per failed bind. Open the one for WorkerAssembly (or whatever your failing DLL is named).

The log will show you the exact bind failure reason:

Bind result: hr = 0x8007000b.
An attempt was made to load a program with an incorrect format.
Assembly manager loaded from:
  D:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Running under executable E:\base\x64\WaWorkerHost.exe
ERR: Invalid assembly

Notice the detail here: the CLR is loading from Framework64, and WaWorkerHost.exe is in x64. Your assembly is not. That's the mismatch, and now you have documented proof of exactly which DLL is the problem.

Now that Fusion logging has confirmed which assembly is the culprit, it's time to fix the build configuration. Head back to your local Visual Studio solution.

Open the Configuration Manager (Build menu → Configuration Manager). You'll see a grid of all your projects and their platform targets. Look for any project set to x86, every single one of those needs to change to Any CPU or x64.

For each problem project, right-click → Properties → Build tab. Set Platform target to Any CPU. If the Prefer 32-bit checkbox is visible and checked, uncheck it. Save the project file.

If the failing assembly is a third-party library you reference directly (not via NuGet), check whether you have a 64-bit version of that DLL. If the vendor only ships x86 binaries, you have a bigger problem, you'll need to find an alternative library or request an x64 build. Platform-only native DLLs (like some COM interop wrappers or legacy C++ libraries) are a common gotcha in Azure worker role deployments.

For NuGet packages, run this in the Package Manager Console to see which packages include native binaries:

Get-ChildItem -Path .\packages -Recurse -Filter "*.dll" |
  Where-Object { $_.DirectoryName -like "*x86*" }

Any x86-only native DLL found there is a candidate for your problem. Once you've updated all platform targets, do a full rebuild: Build → Clean Solution, then Build → Rebuild Solution. Check the Output window for any lingering warnings about platform mismatches. Then package and redeploy your Cloud Service.

In the Azure portal, watch the role instance status. A successful fix shows the instance moving from Busy → Starting → Running and staying there. No more recycling loop.

There's a second common Azure Cloud Services worker role failure that trips people up, and it looks completely different from the assembly format issue. This one surfaces in the AssemblyBinder role as a System.IO.IOException with the message "Not enough space." I know, the instinct is to immediately go check your Azure storage quotas or the role instance's disk size. That's usually a dead end.

In the Azure Cloud Services context, this error typically doesn't mean you've literally run out of disk space on the VM. It means your worker role's startup task or OnStart() code is attempting to write to a directory path that either doesn't exist, isn't accessible to the worker host process, or is a mapped drive that isn't available in the execution context of the role host.

Start your diagnosis the same way: Event Viewer on the role instance → Microsoft Azure Event Log → look for the full stack trace. The trace will point to the specific line in your code that's triggering the IOException. Common culprits include:

• Writing temp files to a hardcoded local path that doesn't exist on the Azure instance (e.g., C:\MyApp\Temp\)
• Trying to access a network share that isn't mounted
• Using Path.GetTempPath() in a context where the TEMP environment variable isn't set
• Exceeding the local resource size configured in ServiceDefinition.csdef

For local storage, the right fix is to use Azure's built-in Local Resource support. In ServiceDefinition.csdef, declare a local resource:

<LocalResources>
  <LocalStorage name="TempStorage"
                sizeInMB="1000"
                cleanOnRoleRecycle="false" />
</LocalResources>

Then in your code, get the path through the Azure runtime rather than hardcoding it:

string tempPath = RoleEnvironment
  .GetLocalResource("TempStorage").RootPath;

This gives you a guaranteed-writable local path on the role instance VM. After making this change, redeploy and monitor the Event Log again to confirm the IOException is gone.

Your role instances are running fine, your CPU is climbing, and autoscale is sitting there doing absolutely nothing. This is a frustrating Azure Cloud Services not working scenario because everything looks right, the autoscale rules are configured, the metrics are flowing, but no new instances spin up. I've been through this with several teams and the root cause is almost always one of three things.

Problem 1: Wrong metric scope. Autoscale rules in Azure Cloud Services need to be configured against the correct aggregation scope. If you've set a rule that says "scale out when CPU > 70% on instance ZipEngine_IN_0," it's watching one instance. As that instance gets busy, it doesn't scale because you told autoscale to watch that specific instance, not the role average. Fix: change the metric aggregation to Average across all instances of the role.

Problem 2: Cool-down period conflicts. Azure autoscale has a default cool-down period of 5 minutes between scale actions. If you have both a scale-out and a scale-in rule, and they're both triggering rapidly, they can cancel each other out. Go to your autoscale settings in the Azure portal under Cloud Services → [your service] → Scale and check the cool-down values. Set scale-out cool-down to 5 minutes and scale-in cool-down to 20–30 minutes minimum to prevent thrashing.

Problem 3: Min/Max instance counts are equal. This sounds obvious but I've seen it more than once. If your autoscale profile has minimum instances set to 2 and maximum instances also set to 2, autoscale has nowhere to go. Check the profile bounds and make sure max > min.

To verify autoscale activity, go to the Azure portal → Monitor → Activity Log and filter by your Cloud Service resource. Successful autoscale events appear here as "Autoscale scale up succeeded" or similar. If you see no autoscale entries at all, the rules aren't triggering. If you see failure entries, expand them, they usually include a clear reason like "operation throttled" or "insufficient quota."

For the FileUploader role specifically: if the role processes uploads asynchronously and CPU usage is low even under heavy load (because the bottleneck is I/O, not CPU), autoscale on a CPU metric will never trigger. In that case, switch to scaling on a custom metric, queue depth from Azure Storage Queue is ideal. Configure it via Azure Monitor custom metrics rules.