Skip to content

[Bug]: Host BSOD after repeated Windows sleep/resume cycles while VM is running normally (VMMR0.r0 / SYSTEM_SERVICE_EXCEPTION 0x3B) #632

@NHZEX

Description

@NHZEX

Version

7.2.6

Host OS Type

Windows

Host OS name + version

Windows 11 25H2 26200.8117

Host Architecture

x86

Guest OS Type

Linux

Guest Architecture

x86

Guest OS name + version

Ubuntu 24.04.3 LTS

Component

VMM

What happened?

The Windows host eventually crashed with a BSOD after the VM had been running normally for some time and the host had gone through multiple sleep/resume cycles.

This is not a case where the crash happens immediately on the first resume. The VM can boot and run normally, and the host can also resume successfully multiple times. However, after several host sleep/resume cycles, one later resume may trigger a host crash.

WinDbg !analyze -v shows:

  • Bugcheck: SYSTEM_SERVICE_EXCEPTION (0x3B)
  • Exception code: 0xC000001D
  • Process in dump: VBoxHeadless.exe
  • Module: VMMR0.r0
  • Faulting instruction: vmsave rax
  • Symbol: VMMR0+0x1f3da

Relevant excerpt from the dump analysis:

PROCESS_NAME:  VBoxHeadless.e
MODULE_NAME: VMMR0
IMAGE_NAME:  VMMR0.r0
BUGCHECK_CODE:  3b
BUGCHECK_P1: c000001d
SYMBOL_NAME:  VMMR0+1f3da
VMMR0+0x1f3da:
fffff805`2e21f3da 0f01db          vmsave  rax

Additional diagnostic data from !blackboxbsd

blackboxbsd output Version: 0xc8 Product type: 1

Auto advanced boot: FALSE
Advanced boot menu timeout: 30
Last boot succeeded: TRUE
Last boot shutdown: FALSE
Sleep in progress: FALSE

Power button timestamp: 0x0
System running: TRUE
Connected standby in progress: FALSE
User shutdown in progress: FALSE
System shutdown in progress: FALSE
Sleep in progress: 0
Connected standby scenario instance id: 0
Connected standby entry reason: 20
Connected standby exit reason: 1
System sleep transitions to on: 15
Last reference time: 0x1dccee7f689e71d
2026-04-18T04:00:58.327Z
Last reference time checksum: 0x3043fba9
Last update boot id: 65

Boot attempt count: 1
Last boot checkpoint: TRUE
Checksum: 0xd0
Last boot id: 65
Last successful shutdown boot id: 64
Last reported abnormal shutdown boot id: 64

Error info boot id: 0
Error info repeat count: 0
Error info other error count: 0
Error info code: 0
Error info status: 0x0

Power button last press time: 0x0
Power button cumulative press count: 0
Power button last press boot id: 0
Power button last power watchdog stage: 0
Power button watchdog armed: FALSE
Power button shutdown in progress: FALSE
Power button last release time: 0x0
Power button cumulative release count: 0
Power button last release boot id: 0
Power button error count: 0
Power button current connected standby phase: 0
Power button transition latest checkpoint id: 0
Power button transition latest checkpoint type: 0
Power button transition latest checkpoint sequence number: 0

Power transition Shutdown Device Type: 255
Power transition Setup In Progress: FALSE
Power transition OOBE In Progress: FALSE
Power transition Sleep Checkpoint Source: 0
Power transition Sleep Checkpoint: 16
Power transition Connected Standby Entry Reason Category: 0
Power transition Connected Standby Exit Reason Category: 0
Power transition Connected Standby Entry Scenario Instance Id: 0x176

Feature Configuration State : Boot Pending

windbg-analyze.txt

How can we reproduce this?

I cannot provide a 100% reliable reproduction yet, but the pattern is approximately:

Start a VM normally from the VirtualBox GUI.
Use the VM normally for some time.
Let the Windows host go through sleep and resume multiple times while the VM remains in use across those cycles.
The host may eventually crash on one later resume.
Important notes:

The crash does not necessarily happen on the first sleep/resume cycle.
The problem seems to require repeated host sleep/resume cycles before it occurs.
The issue happens on the Windows host side, not as a guest OS crash.

VBox.log.1.redacted.txt

Note: some uploaded log files were partially redacted before upload to mask privacy-sensitive information, including user names, local file system paths, repository names/paths, and possible network identifiers. I only replaced those strings with clearly marked placeholders and did not intentionally alter the technical content relevant to the crash. This is not a one-time occurrence. The same host crash has happened multiple times, and the attached dump/logs are from the most recent occurrence.

Did you upload all of your necessary log files, screenshots, etc.?

  • Yes, I've uploaded all pertinent files to this issue.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions