When a Windows PC boots, the operating system needs to learn far more about the machine beneath it than a CPU identification register can report. It needs to know how many logical processors are present, how to put the system into low power sleep states, how to query a laptop battery, and how to react when a thermal zone crosses a safe temperature limit. None of that information lives in a downloadable datasheet. Instead, the motherboard firmware publishes structured binary data blocks called ACPI tables, and Windows parses them during initialization to build a detailed map of the platform. ACPI, the Advanced Configuration and Power Interface, is the standardized language that lets firmware describe hardware inventory, power management behavior, thermal policy, and battery interfaces in a form the kernel can consume programmatically.
This article explains what ACPI tables are, how Windows locates and parses them at boot, how they describe system topology and inventory, how power and sleep states are encoded, how thermal zones and battery control methods work, and how engineers can inspect and troubleshoot them on real machines.
What ACPI Is and How the Tables Are Organized
ACPI is an open standard originally developed by Intel, Microsoft, Toshiba, HP, and Phoenix in the mid 1990s, and now maintained by the UEFI Forum. It replaced vendor specific power management schemes such as APM with a single specification that moves policy control into the operating system while leaving machine specific knowledge in firmware. The central idea is a contract: firmware describes what the hardware can do, and the operating system decides what it should do.
The description is delivered as tables placed in system memory before the OS loader runs. Every table shares a 36 byte header containing a four character signature, a length, a revision, a checksum, an OEM identifier, and a creator field. Because of this uniform container, a parser can walk the entire set without knowing in advance which tables a machine provides, and unrecognized tables can be skipped safely.
Two primitive tables form the entry point. The RSDP, the Root System Description Pointer, is handed to the OS through the UEFI system table or a known memory region on legacy systems. The RSDP points to the RSDT or its 64 bit successor the XSDT, which are directories of physical addresses pointing to every other table, identified by signature alone.
Windows mirrors this hierarchy in the kernel. The ACPI driver, acpi.sys, reads the root pointer, validates checksums, enumerates each table address, and loads the corresponding handlers. A table that fails checksum validation is typically ignored rather than trusted, which is one reason machines with buggy firmware often boot but misbehave subtly in power or thermal behavior.
How Windows Locates and Loads the Tables During Boot
On UEFI systems, the RSDP is located through a configuration table entry in the EFI system table, which provides a well defined GUID for ACPI 2.0 and later. On legacy BIOS systems, the pointer is found by scanning a small memory range in the Extended BIOS Data Area or the region just below 1 MB. Once the RSDP is found, Windows resolves the XSDT or RSDT and walks each entry.
The FADT, the Fixed ACPI Description Table, is loaded early because it contains register addresses the kernel needs before anything else, including the PM1 control and status blocks, the PM timer, and the General Purpose Event array. It also carries a bitfield describing fixed capabilities such as power and sleep button behavior.
Next comes the DSDT, the Differentiated System Description Table, plus any SSDT instances. These tables contain AML, ACPI Machine Language bytecode, executed by an interpreter inside Windows. AML code builds a tree of named objects called the namespace, with paths such as \_SB.PCI0.LPCB.EC0, where the backslash and underscores are literal parts of ACPI naming rules.
The result is a machine wide inventory tree that Windows merges with data from PCI configuration space and SMBIOS tables. Device Manager entries, power buttons, battery icons, and firmware exposed sensors all trace back, directly or indirectly, to objects defined in ACPI tables by the platform vendor.
Tables That Describe Hardware Inventory and Topology
Several tables encode structured facts about processors, memory, buses, and interrupt wiring in ways Windows treats as authoritative. The main recurring signatures are: the MADT describes programmable interrupt controllers and their topology; the FADT defines fixed feature registers and boot flags; the DSDT and SSDTs define devices and control methods; the SRAT describes NUMA proximity domains; and the SLIT describes relative distances between those domains.
The MADT, the Multiple APIC Description Table, is especially important on x86 machines. It enumerates local APIC instances for each logical processor, I/O APICs, interrupt source overrides that remap ISA IRQ assignments, and Non Maskable Interrupt structures. When Windows initializes its processor park and scheduler, the MADT tells it which IDs correspond to real execution units and how interrupt inputs are wired. Errors here can cause boot failures or strangely skewed interrupt loads.
The SRAT and SLIT matter on larger systems. The SRAT assigns memory ranges and processors to proximity domains so Windows can inform the memory manager and scheduler about NUMA locality, while the SLIT provides a matrix of relative distances between domains. Incorrect SRAT entries are a classic source of performance regressions on multi socket servers, where everything works but cross socket memory access silently dominates.
The DSDT namespace adds a rich inventory layer. Each device object can expose a \_HID hardware identifier, a \_CID compatible identifier list, and a \_CRS current resource settings method. Windows Plug and Play uses these identifiers to match devices against drivers, so an ACPI enumerated controller appears in Device Manager precisely because firmware declared it in AML with a stable ID string.
Power States Sleep Behavior and the FADT
ACPI power management uses a family of state labels. The G states describe global states from G0 working through G3 mechanical off. The S states describe sleeping levels inside G1, from S1 through S4 hibernate. The D states describe per device power levels, and the C states describe idle behavior of individual processors while the system stays in G0. Windows policy decides which state to enter; the tables define how each state is reached.
The FADT carries addresses for the PM1 event and control blocks, the PM timer, and the SLP_TYP fields used when writing to the sleep control register. Even on systems flagged as Hardware Reduced ACPI, where much of this is abstracted by UEFI, the FADT remains the backbone descriptor for sleep semantics because it enumerates which S states the platform supports.
Inside the namespace, sleep is tied to named objects. The \_S1 through \_S4 objects return package values describing the sleep type register values for each state. For S3 standby, Windows writes the SLP_TYP value from the \_S3 package plus the SLP_EN bit into the PM1 control register, and the chipset powers down the main rails while memory stays in self refresh. Modern Standby systems change the software model but still rely on ACPI to describe deepest idle entry and wake sources.
Wake behavior is equally table driven. Devices that can signal wake expose a \_PRW object listing the General Purpose Event bit and the lowest supported wake state. When a laptop resumes instantly from a keypress, that path passed through a wake mask configured from these firmware objects, and misprogrammed \_PRW values are a common reason systems fail to wake from USB or network sources.
Thermal Zones Sensors and Cooling Policy
ACPI thermal management is built around the thermal zone, a logical region with sensors and cooling thresholds. Windows reads each zone from the namespace and subscribes to its notifications, letting the OS respond to temperature changes without constant polling. This mechanism drives fan coordination, processor throttling under heat, and emergency shutdown at critical limits.
Each zone declares a \_TMP method returning the current temperature in tenths of a kelvin, plus threshold values. The \_CRT value is the critical temperature at which Windows performs an emergency shutdown. The \_HOT value, slightly lower, requests a suspend to S4. The \_PSV passive threshold tells Windows to begin reducing processor performance before active fans need to compensate.
Cooling devices appear through \_ALx active cooling lists enumerating fans, and \_PSL passive cooling lists enumerating processors that participate in throttling. When a zone crosses a threshold, the firmware issues a Notify event on the zone, the ACPI driver routes it to the Windows thermal framework, and the framework adjusts cooling states or requests processor throttling.
Sensor hardware usually sits behind an embedded controller or SMBus device, and the namespace exposes the operation regions and field definitions Windows needs to reach it. When those field definitions are wrong, monitoring tools can show implausible temperatures even though the underlying sensor works fine.
Battery Subsystem and Control Method Devices
The laptop battery interface is one of the most recognizable ACPI control method devices. Firmware declares a device with the hardware ID PNP0C0A and a consistent set of methods that Windows uses through the battery class driver and power manager. The visible percentage, charge state, design capacity, and estimated runtime all begin here.
The \_BIF method returns static information including design capacity, last full charge capacity, battery technology, design voltage, and model strings. The \_BST method returns dynamic status: whether the battery is discharging, charging, or critical, plus present rate, remaining capacity, and present voltage. Windows calls these methods on a managed cadence and on notification events, turning firmware data into the power flyout numbers.
Change notification flows through the \_BTP battery trip point method, which lets Windows tell the firmware which capacity boundaries should trigger an event. When charge crosses a boundary, the embedded controller signals a Notify on the battery device, and Windows re-evaluates \_BST. The AC Adapter device with hardware ID ACPI0003 follows the same pattern, with a \_PSR method reporting whether AC power is online, letting Windows distinguish charging and discharging states for power policy.
Practical Inspection and Troubleshooting on Windows
Engineers can see what the firmware published without a development kit. The kernel debugger command !acpitable, used in WinDbg against a live system or a dump, lists every loaded table with signature and address, and utilities such as RWEverything or acpidump render table contents on test systems. Windows also surfaces ACPI problems through the System event log, including ACPI BIOS Error entries when AML evaluation fails and Kernel-Power events that trace back to ACPI defined wake or sleep paths.
Several recurring symptoms point back to table content rather than driver defects. Devices that vanish after a BIOS downgrade often reflect a changed SSDT. Systems that wake randomly usually expose an incorrect GPE wake mask or \_PRW entry. Fans that never ramp, or ramp constantly, often trace to thermal thresholds defined in the wrong units.
The practical takeaway is that ACPI tables are the authoritative description of what a machine claims to be and how it claims to behave under power and thermal stress. When Windows produces odd device lists, refuses to sleep, misreports battery capacity, or ignores thermal policy, the strongest first evidence is the tables and namespace the firmware handed over at boot, and the fix frequently lies in a BIOS update or firmware setting rather than in Windows itself.