Stay organized with collectionsSave and categorize content based on your preferences.
LinuxWindows
Use core dumps to analyze the causes of an unresponsive virtual machine (VM)
instance.
To collect core dumps on Compute Engine, you must configure your
VMs to receive aNon-Maskable Interrupt (NMI)signal, and then run aSendDiagnosticInterruptcommand to prompt a kernel panic or blue screen in
your operating system. A kernel panic or blue screen starts a core dump
collection by the guest operating system. These core dumps can then be used for
debugging purposes especially in scenarios that are hard to reproduce, such as
a kernel freeze.
Before you begin
Sending NMI signals are counted in the defaultQueriesAPI quota. For
more information, seeAPI rate limits.
If you haven't already, set upauthentication.
Authentication verifies your identity for access to Google Cloud services and APIs. To run
code or samples from a local development environment, you can authenticate to
Compute Engine by selecting one of the following options:
Select the tab for how you plan to use the samples on this page:
gcloud
Installthe Google Cloud CLI.
After installation,initializethe Google Cloud CLI by running the following command:
To ensure that your user or service account has the necessary
permission to send NMI signals to a VM,
ask your administrator to grant your user or service account theCompute Instance Admin (v1)(roles/compute.instanceAdmin.v1)
IAM role on your project.
For more information about granting roles, seeManage access to projects, folders, and organizations.
This predefined role contains thecompute.instances.sendDiagnosticInterruptpermission,
which is required to
send NMI signals to a VM.
Your administrator might also be able to give your user or service account
this permission
withcustom rolesor
otherpredefined roles.
Overview
To use core dumps to help debug an unresponsive VM or a security issue,
you need to complete the following steps:
A VM's response to receiving an NMI interrupt signal depends on the VM's
operating system configuration.
Each operating system writes its core dump logs in a different location. For
example in Ubuntu operating systems the crash dump file is saved to/var/crash/by default.
To configure your guest OS to generate a crash dump when an NMI signal is
received, review the documentation for the supported operating system.
VM_NAME: instance ID or name of the VM that
you want to collect core dumps from
API_KEY: your API key
The output is similar to the following:
<Empty Response>
For a complete list of outputs, see the next section in this document
about "NMI command responses".
NMI command responses
One of the following responses are returned when you attempt to send an
NMI signal.
State
Body
Notes
SUCCESS
<Empty Response>
SUCCESSshows that the NMI signal is delivered to the
operating system. It does not guarantee that the core dump is collected, or
that the VM shuts down or reboots. These behaviors are determined by the
operating system configuration.
FAIL
UNSUPPORTED_OPERATION
This occurs when the operating system fails to receive the NMI signal. There
are multiple reasons for this. Common scenarios are that the VM is beinglive migratedor the VM
is not properly configured to receive NMI signals. To resolve this, you can try the following:
Verify that the VM is properly configured. SeeConfigure VM.
Wait and retry theSendDiagnosticInterruptrequest.
FAIL
Required 'compute.instances.sendDiagnosticInterrupt' permission for [..]
The command failed because the user making the request does not have
sufficient permissions.
To resolve this, you can assign a role to the user that contains thecompute.instances.sendDiagnosticInterruptpermission.
Review core dumps
Review the crash dump file in the configured or default location for your
operating system.
For example in Ubuntu operating systems, by default, the crash dump file is
saved to/var/crash/.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-04 UTC."],[[["\u003cp\u003eCore dumps from unresponsive virtual machines (VMs) can be collected by configuring the VMs to receive a Non-Maskable Interrupt (NMI) signal and then sending a \u003ccode\u003eSendDiagnosticInterrupt\u003c/code\u003e command.\u003c/p\u003e\n"],["\u003cp\u003eCollecting core dumps requires specific permissions, namely the \u003ccode\u003ecompute.instances.sendDiagnosticInterrupt\u003c/code\u003e permission, typically granted through the Compute Instance Admin (v1) IAM role.\u003c/p\u003e\n"],["\u003cp\u003eThe process involves configuring the VM's operating system to generate core dumps, which varies by OS, and then sending the NMI signal via either the Google Cloud CLI or REST API.\u003c/p\u003e\n"],["\u003cp\u003eThe success of the NMI signal delivery is indicated by an empty response, but the actual collection of the core dump depends on the VM's OS configuration, and the VM will likely be unreachable after.\u003c/p\u003e\n"],["\u003cp\u003eIf an NMI signal fails, it may be due to reasons such as the VM undergoing live migration, improper OS configuration, or a lack of required permissions, with troubleshooting steps provided.\u003c/p\u003e\n"]]],[],null,["# Collecting core dumps\n\nLinux Windows\n\n*** ** * ** ***\n\nUse core dumps to analyze the causes of an unresponsive virtual machine (VM)\ninstance.\n\nTo collect core dumps on Compute Engine, you must configure your\nVMs to receive a [Non-Maskable Interrupt (NMI)](https://en.wikipedia.org/wiki/Non-maskable_interrupt) signal, and then run a\n`SendDiagnosticInterrupt` command to prompt a kernel panic or blue screen in\nyour operating system. A kernel panic or blue screen starts a core dump\ncollection by the guest operating system. These core dumps can then be used for\ndebugging purposes especially in scenarios that are hard to reproduce, such as\na kernel freeze.\n\nBefore you begin\n----------------\n\n- Sending NMI signals are counted in the default **Queries** API quota. For more information, see [API rate limits](/compute/docs/api-rate-limits).\n- If you haven't already, set up [authentication](/compute/docs/authentication). Authentication verifies your identity for access to Google Cloud services and APIs. To run code or samples from a local development environment, you can authenticate to Compute Engine by selecting one of the following options:\n\n Select the tab for how you plan to use the samples on this page: \n\n ### gcloud\n\n 1.\n [Install](/sdk/docs/install) the Google Cloud CLI.\n\n After installation,\n [initialize](/sdk/docs/initializing) the Google Cloud CLI by running the following command:\n\n ```bash\n gcloud init\n ```\n\n\n If you're using an external identity provider (IdP), you must first\n [sign in to the gcloud CLI with your federated identity](/iam/docs/workforce-log-in-gcloud).\n | **Note:** If you installed the gcloud CLI previously, make sure you have the latest version by running `gcloud components update`.\n 2. [Set a default region and zone](/compute/docs/gcloud-compute#set_default_zone_and_region_in_your_local_client).\n\n ### REST\n\n\n To use the REST API samples on this page in a local development environment, you use the\n credentials you provide to the gcloud CLI.\n 1. [Install](/sdk/docs/install) the Google Cloud CLI. After installation, [initialize](/sdk/docs/initializing) the Google Cloud CLI by running the following command: \n\n ```bash\n gcloud init\n ```\n 2. If you're using an external identity provider (IdP), you must first [sign in to the gcloud CLI with your federated identity](/iam/docs/workforce-log-in-gcloud).\n\n\n For more information, see\n [Authenticate for using REST](/docs/authentication/rest)\n in the Google Cloud authentication documentation.\n\n### Required roles\n\n\nTo ensure that your user or service account has the necessary\npermission to send NMI signals to a VM,\n\nask your administrator to grant your user or service account the\n\n\n[Compute Instance Admin (v1)](/iam/docs/roles-permissions/compute#compute.instanceAdmin.v1) (`roles/compute.instanceAdmin.v1`)\nIAM role on your project.\n\n\nFor more information about granting roles, see [Manage access to projects, folders, and organizations](/iam/docs/granting-changing-revoking-access).\n\n\nThis predefined role contains the\n` compute.instances.sendDiagnosticInterrupt`\npermission,\nwhich is required to\nsend NMI signals to a VM.\n\n\nYour administrator might also be able to give your user or service account\nthis permission\nwith [custom roles](/iam/docs/creating-custom-roles) or\nother [predefined roles](/iam/docs/roles-overview#predefined).\n\nOverview\n--------\n\nTo use core dumps to help debug an unresponsive VM or a security issue,\nyou need to complete the following steps:\n\n1. [Configure your VM](#configure-os) to generate core dumps\n2. [Send an NMI signal](#send-nmi) to generate core dumps\n3. [Review](#review-core-dumps) the core dumps\n\nLimitations\n-----------\n\nFor VMs that have Secure Boot enabled, you must disable Secure boot before you send\nan NMI interrupt signal. For instructions, see\n[Modifying Shielded VM options on a VM instance](/compute/docs/instances/modifying-shielded-vm#modify-shielded-vm-instance).\n\nConfigure VM\n------------\n\nA VM's response to receiving an NMI interrupt signal depends on the VM's\noperating system configuration.\n\nEach operating system writes its core dump logs in a different location. For\nexample in Ubuntu operating systems the crash dump file is saved to\n`/var/crash/` by default.\n\nTo configure your guest OS to generate a crash dump when an NMI signal is\nreceived, review the documentation for the supported operating system.\n\nSend NMI to generate core dumps\n-------------------------------\n\nAfter you configure the VM, you can then send the NMI signal to the VM by using\neither the [Google Cloud CLI](/compute/docs/gcloud-compute), or\n[REST](/compute/docs/reference/rest/v1).\n**Note:** When you configure your VM to trigger kernel panic and generate crash dumps, the VM becomes unreachable after the NMI signal is sent. If you want to connect to the VM after the signal is sent, you need to restart the VM. \n\n### gcloud\n\nTo send the NMI signal, use the\n[`instances send-diagnostic-interrupt` command](/sdk/gcloud/reference/compute/instances/send-diagnostic-interrupt). \n\n```\ngcloud compute instances send-diagnostic-interrupt VM_NAME \\\n --zone=ZONE\n```\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eVM_NAME\u003c/var\u003e: instance ID or name of the VM that you want to collect core dumps from\n- \u003cvar translate=\"no\"\u003eZONE\u003c/var\u003e: the zone where your VM is located\n\nThe output is similar to the following: \n\n```\n\u003cEmpty Response\u003e\n```\n\nFor a complete list of outputs, see the next section in this document about\n\"NMI command responses\".\n\n### REST\n\n1. Optional. If not already available, create an API key.\n For more information about creating API keys, see\n [Creating an API key](/docs/authentication/api-keys#creating_an_api_key).\n\n2. To send the NMI signal, make a `POST` request to the [`sendDiagnosticInterrupt` method](/compute/docs/reference/rest/v1/instances/sendDiagnosticInterrupt).\n\n ```\n POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instances/VM_NAME/sendDiagnosticInterrupt?key=API_KEY\n ```\n\n For, example, you can use the `curl` command to make the request as follows: \n\n ```\n curl --request POST 'https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instances/VM_NAME/sendDiagnosticInterrupt?key=API_KEY' \\\n --header 'Authorization: Bearer $(gcloud auth print-access-token)' \\\n --header 'Accept: application/json' \\\n --compressed\n ```\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e: ID of the project to create the VM in\n - \u003cvar translate=\"no\"\u003eZONE\u003c/var\u003e: the zone where your VM is located\n - \u003cvar translate=\"no\"\u003eVM_NAME\u003c/var\u003e: instance ID or name of the VM that you want to collect core dumps from\n - \u003cvar translate=\"no\"\u003eAPI_KEY\u003c/var\u003e: your API key\n\n The output is similar to the following: \n\n ```\n \u003cEmpty Response\u003e\n ```\n\n For a complete list of outputs, see the next section in this document\n about \"NMI command responses\".\n\n### NMI command responses\n\nOne of the following responses are returned when you attempt to send an\nNMI signal.\n\nReview core dumps\n-----------------\n\nReview the crash dump file in the configured or default location for your\noperating system.\n\nFor example in Ubuntu operating systems, by default, the crash dump file is\nsaved to `/var/crash/`."]]
