Blog Post

Azure Compute Blog
3 MIN READ

Recovery options for Azure Virtual Machines (VM) affected by CrowdStrike Falcon agent

KaushalGhai's avatar
KaushalGhai
Icon for Microsoft rankMicrosoft
Jul 20, 2024

We are aware of an issue that started on 19 July 2024 at 04:09UTC, 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.  

CrowdStrike has released a public statement on Windows Sensor Update - crowdstrike.com addressing the matter, and it includes recommended steps for a workaround. 

 

Customers with VMs in Azure that have the CrowdStrike Falcon agent installed have received communications via Azure Service Health (Tracking ID 1VT1-LX0). Microsoft worked with CrowdStrike to adjust the boot configuration used to start the impacted VMs and successfully download the corrected CrowdStrike signature files.

 

Customers can request Microsoft to apply the boot configuration by opening the Support+Troubleshooting blade in the Azure Portal for further assistance. The Subscription Owner or Contributor can provide consent by clicking the “?” in the top navigator bar of the Portal. 

 

For environments specific to Azure, further instructions are provided below: 

 

Recovery Options:  


We have noticed that some Azure VMs are successfully updating via the CrowdStrike Falcon agent after multiple manual Virtual Machine restarts. Customers can attempt to do so as follows: 

  • Using the Azure Portal - attempting 'Restart' on affected VMs 

https://learn.microsoft.com/en-us/cli/azure/vm?view=azure-cli-latest#az-vm-restart 

Please note in some cases multiple reboots may be required. Usually, the reboot of instance allows the CrowdStrike Falcon agent to update successfully. If a reboot doesn't resolve the issue, then leverage additional recovery options to resolve the issue. 

 

Additional options for recovery: 

 

Option 1: 

We recommend customers that can restore from a backup, preferably from before 19 July 2024 at 04:09UTC, when this faulty update started rolling out. 

 

Option 2:  

Customers can attempt to remove the C-00000291*.sys file on the disk directly and potentially not need to perform detach and reattach disc. 

Open Azure AZ CLI (minimum version needed is Powershell 5.1+) and run the following steps:

 

1.Create rescue VM with 

// Creates a rescue VM, same size as the original VM in the same region. Asks for Username and password.  

// Makes a copy of the OS Disk of the problem VM 

// Attaches the OS Disk as Data disk to the Rescue VM 

//az vm repair create -g {your-resource-group} -n {vm-name} --verbose 

az vm repair create -g RGNAME -n BROKENVMNAME --verbose 

 **NOTE: For encrypted VM run the following command:** 

az vm repair create -g RGNAME -n BROKENVMNAME --unlock-encrypted-vm --verbose

 

2.Then run: 

// Runs the mitigation script on the Rescue VM which fixes the problem (on the os-disk copy attached as a data disk) 

//az vm repair run -g {your-resource-group} -n {vm-name} --run-id win-crowdstrike-fix-bootloop --run-on-repair --verbose 

az vm repair run -g RGNAME -n BROKENVMNAME --run-id win-crowdstrike-fix-bootloop --run-on-repair --verbose 

 

3.Final step is to run: 

// Removes the Fixed OS-Disk Copy from the rescue VM 

// Stops the problem VM but it is not deallocated 

// Attaches the fixed OS-Disk to the original VM 

// Starts the original VM 

// Gives prompts to delete the repair vm 

//az vm repair restore -g {your-resource-group} -n {vmname} --verbose 

az vm repair restore -g RGNAME -n BROKENVMNAME --verbose 

Note: These steps would work for both managed and unmanaged disks. In case, if you run into capacity issues, please retry after some time. 

 

Option 3:  

Customers can attempt repairs on the OS disk by following these instructions: 

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. 

 

Note: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. 

 

 

Additional recovery option references for other Windows hosted services:

 

 

 

Updated Jul 24, 2024
Version 8.0
  • Hello Anthony_W

     

    Thank you for highlighting about the extra spaces in the command of Step 2. 

    They are removed now, and the blog is updated with the right command. 

  • TomMucha1's avatar
    TomMucha1
    Brass Contributor

    The az vm repair command works great on VMs natively deployed in Azure.  We had a bunch of machines migrated from on-prem that would throw this error when finalizing the restore step.  Didn't find any solutions and used the manual snapshot method instead.    If there are any ideas on how to use this in the future it would be great to have in our toolbox.

     

    ERROR: (PropertyChangeNotAllowed) Changing property 'osProfile' is not allowed.

  • preetshah's avatar
    preetshah
    Copper Contributor

    Hello Z004KR5J-A01 ,

     

    I recommend enabling Boot Diagnostics to view the startup screen and troubleshoot the issue further.

    To address this problem, please follow these steps:

    1. Create a disk from a snapshot: Create a snapshot of your original OS disk and then convert it into a new disk. Ensure you select the appropriate storage type.
    2. Attach the new disk: Attach the newly created disk to any existing VM in the same region.
    3. Remove the problematic file: Access the attached disk using Explorer, navigate to Windows/System32/Drivers/CrowdStrike, and permanently delete the file starting with "C-00000291*.sys".
    4. Detach the disk: Close Explorer, return to the Azure portal, and detach the disk.
    5. Swap the OS disk: Replace the OS disk of your main virtual machine with the modified disk.
    6. Start the VM and enable Boot Diagnostics: Start the virtual machine and wait for the startup screen to appear.
    7. No registry changes should be ideally required.

    Please let me know if the issue persists after following these steps.

     

    Above steps worked for us.

  • andrasdeak's avatar
    andrasdeak
    Copper Contributor

    Z004KR5J-A01 Instead of deleting the file, try renaming the "Windows/System32/Drivers/CrowdStrike/" folder into something like "CrowdStrike_faulty".

    That worked for us.

  • Z004KR5J-A01's avatar
    Z004KR5J-A01
    Copper Contributor

    We are unable to bring back the machine from 'not ready' status even after deleting the mentioned file and making changes to the registry.

    We had tried swapping the OS disk

  • Can you please fix the commands in Option 2 - step 2 and remove the extra spaces? 

     

    az vm repair run -g RGNAME -n BROKENVMNAME --run-id win-crowdstrike-fix-bootloop --run-on-repair --verbose