[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-08-27。"],[[["\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/`."]]