Cowork: AMD APU laptops black-screen at boot when SVM is enabled unless UMA Frame Buffer Size is set to Auto

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Cowork uma framebuffer report · MD
Cowork: AMD APU laptops black-screen at boot when SVM is enabled unless UMA Frame Buffer Size is set to Auto
Summary

On AMD laptops with integrated Radeon graphics, enabling SVM (AMD-V) in firmware so that Cowork can start its sandbox can cause Windows to fail to boot — a black screen before the kernel initializes, with no error code and no crash dump. The machine is only recoverable by disabling SVM again.

The cause is not SVM itself and not the Hyper-V feature set. It is the UMA Frame Buffer Size setting in BIOS. When set to a manual value (1G, 2G, etc.), the integrated GPU's reserved memory block is hard-pinned at a fixed physical address and collides with memory the hypervisor claims during early initialization. Setting it to Auto resolves the boot failure completely.

This is not documented anywhere in Cowork's setup guidance, and the in-app error messages actively point users in the wrong direction.

Environment
ASUS TUF Gaming FX505DT (laptop)
AMD Ryzen 7 3750H with Radeon Vega Mobile Graphics
16 GB DDR4
BIOS: American Megatrends, version 316 (latest available for this model; released 2021)
EC version: FX505.D10
Windows 11 Pro, build 26200 (25H2); also reproduced on 24H2 (build 26100)
Claude Desktop with Cowork

Symptoms
Cowork reports HRESULT 0x80370102 — "hypervisor not running" — and states that hardware virtualization is disabled in firmware.
Enabling SVM Mode in BIOS causes Windows to black-screen at boot. Fans cycle up and down. No POST error, no BSOD, no stop code, no recovery environment.
Disabling SVM restores normal boot immediately and reliably.
Get-CimInstance Win32_ComputerSystem | Select HypervisorPresent returns False in every bootable configuration.
Event Viewer shows Microsoft-Windows-Hyper-V-Hypervisor Event ID 42 ("Hypervisor launch failed; Either SVM not present or not enabled in BIOS"), but only on boots that succeeded — i.e. boots where SVM was off while hypervisorlaunchtype was still Auto. The failed boots log nothing at all, because the failure occurs before Windows can write to disk.

What Should Happen?

Cowork should start its sandboxed environment on an AMD APU laptop with SVM enabled in firmware, without Windows failing to boot. Where the hypervisor cannot launch despite virtualization being enabled in firmware, the error message should say so rather than instructing the user to enable a BIOS setting that is already enabled.

Error Messages/Logs

Cowork: "Claude's workspace failed to start with HRESULT 0x80370102 (hypervisor not running). Hardware virtualization (Intel VT-x or AMD-V) is disabled in this device's firmware."

Event Viewer, Microsoft-Windows-Hyper-V-Hypervisor, Event ID 42: "Hypervisor launch failed; Either SVM not present or not enabled in BIOS." Logged only on boots that succeeded with SVM disabled. Failed boots produce no log entry and no crash dump.

Steps to Reproduce

On an AMD APU laptop (Ryzen 7 3750H with Radeon Vega), set UMA Frame Buffer Size in BIOS to a manual value such as 2G.
Install Windows 11 Pro. Enable the Hyper-V, VirtualMachinePlatform, and HypervisorPlatform optional features. Restart.
Launch Cowork. It reports HRESULT 0x80370102 and states that hardware virtualization is disabled in firmware.
Enter BIOS and enable SVM Mode. Save and exit.
Windows fails to boot — black screen, fans cycling, no POST error, no BSOD, no recovery environment.
Recover by disabling SVM Mode in BIOS.
Return to BIOS, set UMA Frame Buffer Size to Auto, and enable SVM Mode. Windows now boots normally, HypervisorPresent returns True, and Cowork's shell works.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

N/A — Claude Desktop (Cowork), not Claude Code

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

What did not work

For the benefit of anyone else searching, all of the following were tried and had no effect on the boot failure:

Upgrading from Windows Home to Pro (necessary, but not sufficient)
Enabling Microsoft-Hyper-V-All, VirtualMachinePlatform, and HypervisorPlatform
Disabling Windows Fast Startup (powercfg /h off) and cold-booting
bcdedit /set hypervisoriommupolicy disable
bcdedit /set hypervisorschedulertype classic
Disabling BIOS Fast Boot
Loading BIOS optimized defaults and re-enabling SVM from a clean state
Toggling SVM off and on across multiple reboots
Rolling back to Windows 24H2 by uninstalling the 25H2 enablement package (KB5054156)

Also verified as not the problem:

vfpext.sys was present in System32\drivers (this is a separate, unrelated failure mode reported by other users)
Memory Integrity / Core Isolation was not enabled — the toggle does not exist on this system
systeminfo showed all four Hyper-V requirements passing (VM Monitor Mode Extensions, SLAT, DEP, and firmware virtualization once SVM was on)
BIOS was already at the newest version ever released for this model
Suggested improvements
The error text is misleading. 0x80370102 currently tells the user that virtualization is disabled in firmware and to enable it in BIOS. In this case virtualization was enabled in firmware and Task Manager confirmed it — the user is told to do the exact thing they have already done. Consider distinguishing "virtualization not enabled" from "hypervisor present but not running."
Add UMA Frame Buffer Size to setup documentation. Any AMD APU system — which covers a large share of budget and mid-range laptops — is potentially affected. A single line in the Windows setup guidance would save users a great deal of time.
Consider detecting the pre-boot failure pattern. If Cowork can see that SVM is enabled in firmware but HypervisorPresent is False, that combination is diagnostic and could trigger targeted guidance rather than the generic BIOS message.
Related reports
microsoft/WSL issue #40344 — a user on an AMD system running Windows 11 25H2 build 26200 reports an identical pattern: SVM enabled plus hypervisorlaunchtype auto produces a boot failure, disabling SVM restores boot, and Event 42 appears in the log. That report attributes the cause to disk enumeration changes across multiple drives. This single-drive laptop reproduces the same failure, which suggests the disk theory is incorrect and the memory-layout explanation may apply there as well.
A Microsoft Learn Q&A thread reports Cowork failing on an AMD mini PC due to a missing vfpext.sys driver. That is a distinct failure mode from this one.