Quick Answer
Update your BIOS/UEFI firmware to the latest version. If that's not possible, override the offending ACPI table (usually DSDT or SSDT) using GRUB on Linux or a patched driver on Windows.
What's Actually Happening Here
The ACPI firmware tables (DSDT, SSDTs) contain AML bytecode that the OS interpreter runs to manage hardware power states, device enumeration, and thermal events. Error 0xC0140002 means the interpreter's internal call stack hit its limit — usually because a method recursively called itself or called too many nested sub-methods. This is almost always a firmware bug: the vendor wrote a table with an infinite loop or an overly deep call chain. It's not your OS's fault. I've seen this on Dell XPS laptops (circa 2019) after a Windows update that triggered a deeper evaluation path, and on some ASUS Z390 boards where a USB controller's _DSM method went haywire.
Fix Steps (In Order of Likely Success)
Step 1: Update Your BIOS/UEFI Firmware
This is the real fix. Vendors patch these bugs constantly. Go to your motherboard or laptop support page, find the latest BIOS, and flash it. On modern systems (UEFI class 3+), you can often update from within the firmware UI or via fwupdmgr on Linux.
# Linux: check for firmware updates
fwupdmgr get-devices
fwupdmgr refresh
fwupdmgr update
On Windows, check Windows Update for “firmware” updates, or use the vendor's own tool (Dell Command Update, Lenovo Vantage, etc.).
Step 2: Override the Corrupted ACPI Table via GRUB (Linux)
If you can't update the BIOS — say the vendor abandoned the board — you can replace the table at boot time. This is safer than it sounds; you're not flashing firmware, just telling the kernel to load your fixed AML instead of the built-in one.
- Extract the offending table. First, figure out which table is the culprit. The error
0xC0140002usually points to DSDT, but checkdmesgfor a line likeACPI Error: Stack overflow— it may name the table (e.g., SSDT1). - Dump it:
# Dump all ACPI tables
sudo acpidump -o acpi_dump.dat
# Decompile to AML
acpixtract acpi_dump.dat
iasl -d dsdt.dat # or ssdt1.dat, etc.
- Fix the bug in the .dsl file. This is the hard part. Look for recursive calls or deep nesting. Search for
Method (blocks that call themselves. A common pattern:
Method (_DSM, 4, Serialized)
{
...
Return (^^PCI0.PEG0.PEGP._DSM (Arg0, Arg1, Arg2, Arg3)) // bounce back — stack overflow
}
Comment out the recursion or reduce depth. Recompile:
iasl -tc dsdt.dsl # produces dsdt.aml
- Copy the AML file to
/boot/and tell GRUB to load it. Edit/etc/default/gruband add:
GRUB_ACPI_OVERRIDES="dsdt.aml"
Then update GRUB:
sudo update-grub
Reboot. Check dmesg | grep ACPI after boot — you should see ACPI: Table override: DSDT loaded from ....
Step 3: Use a Kernel Parameter to Disable the Problematic Subsystem (Linux)
If overriding the whole table is too much, you can sometimes work around by disabling the device that triggers the overflow. For example, if it's a Thunderbolt controller, add acpi=off or pci=noacpi to GRUB. These are sledgehammers — you lose power management and hotplug features — but they'll stop the crash.
# In GRUB edit line, add:
acpi=off
# Then boot. If that works, make it permanent in /etc/default/grub under GRUB_CMDLINE_LINUX_DEFAULT.
Alternative Fixes If the Main One Fails
Windows: Disable the Device in Device Manager
Not as clean, but quick. The overflow usually happens when a driver calls a specific ACPI method. Find the device that's associated with the error — check Event Viewer > Windows Logs > System for ACPI errors. Disable that device. For example, on Dell XPS 9570, disabling the Intel Serial IO I2C controller hid the bug.
Linux: Use acpi_osi="!Windows 2020"
Some firmware checks the OS string and changes behavior. Tricking it into thinking you're an older OS often skips buggy methods:
# In GRUB command line:
acpi_osi="!Windows 2020" acpi_osi="Windows 2015"
Prevention Tip
Don't buy hardware from vendors who don't provide firmware updates. For existing machines, set a calendar reminder to check for BIOS updates every 3 months. This bug is 100% vendor firmware — no amount of OS patching will truly fix it. If you're writing custom ACPI tables for embedded systems, always set a maximum recursion depth and validate your AML with iasl -va -g.