Is Azure down?
Current Azure status is UP

We are aware of an issue that started on July 18, which resulted in customers experiencing unresponsiveness and startup failures on Windows machines using the CrowdStrike Falcon agent, affecting both on-premises and various cloud platforms (Azure, AWS, and Google Cloud).
It’s important to clarify that this incident is separate from the resolved Central US Azure outage (Tracking Id: 1K80-N_8). Microsoft is actively providing support to assist customers in their recovery on our platforms, offering additional guidance and technical assistance.
CrowdStrike has released a public statement on Windows Sensor Update - crowdstrike.com addressing the matter, and it includes recommended steps for a workaround. For environments specific to Azure, further instructions are provided below:
Updated: We approximate impact started as early as 04:09 UTC on the 18th of July, when this update started rolling out.
Update as of 10:30 UTC on 19 July 2024:
We have received reports of successful recovery from some customers attempting multiple Virtual Machine restart operations on affected Virtual Machines. Customers can attempt to do so as follows:
https://learn.microsoft.com/en-us/cli/azure/vm?view=azure-cli-latest#az-vm-restart
We have received feedback from customers that several reboots (as many as 15 have been reported) may be required, but overall feedback is that reboots are an effective troubleshooting step at this stage.
Additional options for recovery:
We recommend customers that are able to, to restore from a backup, preferably from before 04:09 UTC on the 18th of July, when this faulty update started rolling out.
How to restore Azure VM data in Azure portal
Troubleshoot a Windows VM by attaching the OS disk to a repair VM through the Azure portal
Once the disk is attached, customers can attempt to delete the following file:
Windows/System32/Drivers/CrowdStrike/C-00000291*.sys
The disk can then be attached and re-attached to the original VM.
We can confirm the affected update has been pulled by CrowdStrike. Customers that are continuing to experience issues should reach out to CrowdStrike for additional assistance.
Additionally, we're continuing to investigate additional mitigation options for customers and will share more information as it becomes known.
This message was last updated at 17:43 UTC on 19 July 2024

We have been made aware of an issue impacting Virtual Machines running Windows Client and Windows Server, running the CrowdStrike Falcon agent, which may encounter a bug check (BSOD) and get stuck in a restarting state. We approximate impact started around 19:00 UTC on the 18th of July.
We recommend customers that are able to, to restore from a backup from before this time.
Alternatively, customers can attempt to repair the OS disk offline by following these instructions: 
Attach an unmanaged disk to a VM for offline repair
Disks that are encrypted may need these additional instructions:
Unlocking an encrypted disk for offline repair
Once the disk is attached, customers can attempt to delete the following file. 
Windows/System/System32/Drivers/CrowdStrike/C00000291*.sys
The disk can then be attached and re-attached to the original VM.
We recommend customers that are continuing to experience issues to reach out to CrowdStrike for additional assistance.
Additionally, we are continuing to investigate additional mitigation options for customers and will share more information as it becomes known.
This message was last updated at 09:26 UTC on 19 July 2024

Impact Statement: Starting at approximately 21:56 UTC on 18 Jul 2024, a subset of customers may experience issues with multiple Azure services in the Central US region including failures with service management operations and connectivity or availability of services.
Current Status: We are aware of this issue and have engaged multiple teams. We’ve determined the underlying cause. A backend cluster management workflow deployed a configuration change causing backend access to be blocked between a subset of Azure Storage clusters and compute resources in the Central US region. This resulted in the compute resources automatically restarting when connectivity was lost to virtual disks. Mitigation has been confirmed for all Azure Storage clusters, the majority of services are now recovered. A small subset of services is still experiencing residual impact. Impacted customers will be continuing to communicate throuhg Azure service health portal. The next update will be provided in 60 minutes, or as events warrant.
https://learn.microsoft.com/azure/architecture/resiliency/recovery-loss-azure-region .
This message was last updated at 04:45 UTC on 19 July 2024

Impact Statement: Starting at approximately 21:56 UTC on 18 Jul 2024, a subset of customers may experience issues with multiple Azure services in the Central US region including failures with service management operations and connectivity or availability of services.
Current Status: We are aware of this issue and have engaged multiple teams. We’ve determined the underlying cause. A backend cluster management workflow deployed a configuration change causing backend access to be blocked between a subset of Azure Storage clusters and compute resources in the Central US region. This resulted in the compute resources automatically restarting when connectivity was lost to virtual disks. Mitigation has been confirmed for all Azure Storage clusters, the majority of services are now recovered. A small subset of services is still experiencing residual impact. Impacted customers will be continuing to communicate throuhg Azure service health portal. The next update will be provided in 60 minutes, or as events warrant.
https://learn.microsoft.com/azure/architecture/resiliency/recovery-loss-azure-region .
This message was last updated at 04:38 UTC on 19 July 2024

Impact Statement: Starting at approximately 21:56 UTC on 18 Jul 2024, a subset of customers may experience issues with multiple Azure services in the Central US region including failures with service management operations and connectivity or availability of services.
Current Status: We are aware of this issue and have engaged multiple teams. We’ve determined the underlying cause. A backend cluster management workflow deployed a configuration change causing backend access to be blocked between a subset of Azure Storage clusters and compute resources in the Central US region. This resulted in the compute resources automatically restarting when connectivity was lost to virtual disks. Mitigation has been confirmed for all Azure Storage clusters, we are continuing to mitigate residual and downstream impacted services. Customers should continue to see increasing recovery at this time as residual and downstream impact mitigation progresses. The next update will be provided in 60 minutes, or as events warrant.
https://learn.microsoft.com/azure/architecture/resiliency/recovery-loss-azure-region .
This message was last updated at 04:01 UTC on 19 July 2024