WHEA-Logger 17 A corrected hardware error has occurred
The Windows Hardware Error Architecture logs Event 17 when a component detected an error and successfully corrected it. Nothing crashed and no data was lost, which is why most people never notice these until they go looking. The diagnostic value is not in any single entry - it is in how many arrive, and when.
What you are looking at
In Event Viewer the matching entries look like this:
Log Name: System
Source: Microsoft-Windows-WHEA-Logger
Event ID: 17
Level: Warning
A corrected hardware error has occurred.
Component: PCI Express Root Port
Error Source: Advanced Error Reporting (PCI Express)
Bus:Device:Function: 0x0:0x1:0x0
Vendor ID:Device ID: 0x10DE:0x2782
Class Code: 0x30000What the error actually means
Modern hardware expects a certain amount of error. PCI Express links run at multi-gigahertz signalling rates over traces and connectors that are never electrically perfect, so the specification builds in detection and retry. When a packet arrives corrupted, the link retries it, the transfer succeeds, and the component reports what happened through Advanced Error Reporting. Windows records that as Event 17.
So the word to focus on is corrected. This event is a report of a problem that was already handled. That is genuinely different from Event 18, which is a fatal error the hardware could not recover from.
The catch is that correction is not free and it is not unlimited. A link that needs to retry constantly is a link operating near its margin, and margins tend to move in one direction over the life of a machine. A steady background rate of Event 17 is normal. A rate that is climbing is a component telling you something well before it fails outright.
Reading the parameters
The body of the event contains the information that matters. These are the fields worth reading.
| Parameter | What it holds |
|---|---|
| Component | Which part of the platform reported the error. PCI Express Root Port is by far the most common. Memory and Processor Core appear too, and each points somewhere completely different. |
| Error Source | The reporting mechanism. Advanced Error Reporting (PCI Express) confirms this came from the PCIe subsystem rather than the CPU's machine-check banks. |
| Bus:Device:Function | The address of the device on the PCIe topology, usually written as 0x0:0x1:0x0. This is how you find out which physical card or chip is involved - see the identification step below. |
| Vendor ID:Device ID | Two hex values identifying the manufacturer and the exact part. 0x10DE is NVIDIA, 0x1002 AMD, 0x8086 Intel. Searching the pair identifies the device precisely. |
| Primary/Secondary Bus | Present on root port and bridge errors. It distinguishes an error on the port itself from one on the link running downstream of it - useful when a riser or a long trace sits between the two. |
What actually triggers it
Almost everything on this list is about signal integrity or power, not about a component being broken in an obvious way.
| Cause | How often | Detail |
|---|---|---|
| Link power-management transitions (ASPM) | Common | PCIe links drop to low-power states when idle and renegotiate on wake. Those transitions are the hardest moment electrically, and a marginal link fails there first. This is why so many people see these errors on an idle machine and none at all under load - which feels backwards until you know the mechanism. |
| Aggressive link speed for the physical path | Common | Gen4 and Gen5 signalling leaves far less margin than Gen3. A slot, cable or riser that was fine at one generation can produce constant corrected errors at the next one up. |
| Riser cables and physical connection quality | Common | Vertical GPU mounts, cheap risers, dust or oxidation on contacts, and a card that is not fully seated all show up exactly like this. |
| Firmware and chipset driver bugs | Occasional | Vendors do ship BIOS updates that specifically address spurious AER reporting. Worth checking the changelog for your board before assuming a hardware fault. |
| Power delivery and PSU ripple | Occasional | Noisy rails degrade signal integrity across the whole board. An ageing or overloaded PSU produces errors that appear to come from several unrelated devices at once. |
| A degrading device or board | Occasional | Solder fatigue, a damaged trace or a failing controller. This is the diagnosis you arrive at by elimination, and the one that ends in a warranty claim rather than a fix. |
Narrowing it down
The first question is never "how do I stop these appearing" - it is "how many are there, and which device."
Count them and plot them over time
A single event tells you nothing. The distribution tells you almost everything. Run this in an administrator PowerShell window:
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'} |
Group-Object Id |
Sort-Object Count -Descending |
Format-Table Name, Count -AutoSizeThen look at how they are spread across time, bucketed by hour:
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'; Id=17} |
Group-Object { $_.TimeCreated.ToString('yyyy-MM-dd HH:00') } |
Sort-Object Name |
Format-Table Name, Count -AutoSizeA handful spread evenly over months is background noise - leave it alone. Hundreds arriving inside a couple of minutes is a storm, and storms mean a link that has lost its margin. Note whether the bursts land at idle or under load, because that distinction drives everything that follows.
Identify the actual device
Translate the Bus:Device:Function from the event into a name. This lists every PCI device with its location string:
Get-PnpDevice -PresentOnly | Where-Object InstanceId -like 'PCI*' | ForEach-Object {
$loc = (Get-PnpDeviceProperty -InstanceId $_.InstanceId -KeyName 'DEVPKEY_Device_LocationInfo').Data
[pscustomobject]@{ Location = $loc; Device = $_.FriendlyName }
} | Sort-Object Location | Format-Table -AutoSizeMatch the bus and device numbers from the event against the Location column. Bear in mind that the reporting component is often the root port - the connection upstream of the card - rather than the card itself.
Knowing whether the errors come from the GPU link, an NVMe drive or the chipset uplink decides which of the fixes below are even relevant.
Check what else is in the log at the same timestamps
Filter the System log around a storm and look for neighbours: display driver timeouts, storage controller resets, unexpected shutdowns, bugcheck records.
Corrected errors that arrive alone are worth monitoring. Corrected errors immediately preceding a driver timeout or a stop error mean the correction mechanism is being overwhelmed, and the two are the same fault seen from different angles.
Test whether load changes anything
Run a sustained GPU and CPU load for an hour and count the events before and after. Then leave the machine idle overnight and count again.
Errors that increase under load point at thermals or power delivery. Errors that appear only at idle point at link power-management transitions and a weak physical link - a signature that stress testing will never reproduce, which is exactly why stress tests so often come back clean on these machines.
Fixes, cheapest first
Start with the free and reversible. Note that none of these is a fix if the link is physically degrading - in that case they buy time and, more usefully, they help you prove the fault.
Update BIOS and chipset drivers
Check the board or system vendor's changelog for anything mentioning PCIe, AER, WHEA or link stability. Firmware changes to link training and ASPM behaviour are common and do resolve genuine cases.
Reseat the card and remove any riser
Power down fully and unplug at the wall. Remove the card, inspect the gold fingers and the slot for dust or discolouration, clean the contacts with isopropyl alcohol, and reseat firmly.
- If a riser cable is in use, connect the card directly to the board instead - even temporarily, purely as a test.
- If the board has a second full-length slot, try the card there and see whether the errors follow the card or stay with the slot.
- Recount the events over the following days using the PowerShell above.
Watch outWhether the errors follow the card or stay with the slot is the single most valuable data point you can gather, and it costs nothing but time. It separates a faulty card from a faulty board.
Force a lower PCIe generation
In UEFI, find the PCIe link speed setting for the affected slot - usually under advanced chipset or onboard device configuration - and set it one generation lower, for example Gen4 down to Gen3.
Real-world performance loss is small, typically low single-digit percentages for a graphics card. If the errors stop dead, you have confirmed a signal-integrity problem rather than a logic fault.
Disable PCIe link power management
If the errors cluster at idle, this is the highest-value test available. Disable ASPM in two places, because they are independent.
- In Windows: Power Options, change plan settings, advanced settings, PCI Express, Link State Power Management, set to Off.
- In UEFI: locate ASPM, or Native ASPM, or PEG ASPM, and disable it.
- Reboot and recount events over the next few days.
Watch outIdle power draw rises slightly, and on a laptop that costs battery life. Accept that trade only while diagnosing, then decide whether it is worth keeping.
Rule out the power supply
If you can borrow a known-good supply of adequate capacity, swap it in for a week. Use separate PCIe power cables for each connector on the graphics card rather than a single daisy-chained cable.
An ageing supply is a genuinely common cause of errors that appear to come from several devices at once, and it is one of the few remaining possibilities that is cheap to replace.
When it is the hardware, not Windows
These patterns mean the useful troubleshooting is over and the useful documentation should begin:
- Storms of hundreds of corrected errors within minutes, rather than a slow trickle.
- The rate is increasing week over week - the clearest single indicator of degradation.
- Errors appear at idle and cannot be reproduced under any synthetic load.
- The same errors persist after a clean Windows install, a BIOS update, a reseat and a different slot.
- Event 18 or Event 1 - the uncorrected variants - start appearing alongside the corrected ones.
- Other symptoms join in: display driver timeouts, silent reboots without a dump, or a display that dies with the system still running.
The last one on that list matters more than people expect. Corrected errors escalating into uncorrected ones is the hardware equivalent of a warning light turning into a breakdown, and it is the strongest evidence you can bring to a support call. Export the events to a file, keep them, and note the dates. Vendor diagnostics run short synthetic tests and routinely pass machines that fail this way - so a passing diagnostic is not the end of your case, it is just one data point that needs to sit alongside your logs.
Frequently asked
Is Event 17 dangerous, or can I ignore it?
A few over a period of months are normal and safe to ignore - PCIe is designed to correct errors and it did. What matters is the rate and the trend. If the count is climbing, or arriving in bursts, treat it as an early warning rather than noise. Nothing is being lost right now, but the margin protecting you is shrinking.
What is the difference between Event 17, 18, 19 and 47?
Broadly: 17 and 19 are corrected errors that the hardware recovered from, 18 and 1 are fatal errors that it could not. Event 17 most often comes from PCI Express, Event 19 from the processor's machine-check banks, and Event 47 from memory. Always read the Component field in the event body rather than relying on the ID alone, because the exact mapping varies between platforms and firmware versions.
Can I just stop Windows logging these?
You can suppress AER reporting through firmware settings or boot configuration, and you should not. The errors continue happening; you simply stop being told. The logging is the only visibility you have into a link that is degrading, and it is also the evidence a warranty claim rests on. Silencing a warning light does not repair the engine.
Everything passes stress testing. Does that clear the hardware?
No, and this trips up a lot of people. If the fault lives in link power-management transitions, stress testing is the worst possible test for it - a sustained load keeps the link in its highest-power state, which is precisely the condition where a marginal link behaves. Errors that appear only at idle and vanish under load are a recognisable signature, not a contradiction. Test idle behaviour deliberately instead.
The component says PCI Express Root Port. Is the motherboard faulty?
Not necessarily. The root port is the board-side end of the link, and it reports errors it observes on that link - which can originate at either end, or in the connector and traces between. Establishing whether the errors follow the card into a different slot is what distinguishes the two. If they stay with the slot while the card behaves elsewhere, the board becomes the prime suspect.