Fix TPM_E_BAD_PARAM_SIZE 0x80280019 on Windows

You're setting up BitLocker, enrolling Windows Hello, or running tpmtool getdeviceinformation, and instead of a clean result you get TPM_E_BAD_PARAM_SIZE (0x80280019) with the message "The paramSize argument to the command has the incorrect value." On some machines it shows up during OOBE. On others it appears after a BIOS update or a Windows cumulative update. Dell Latitudes with the Nuvoton NPCT750 and certain HP EliteBooks with Infineon SLB9670 firmware have both produced this in the wild after a bad vendor flash.

What's actually happening here

The TPM is a microcontroller that speaks a strict wire protocol. Every command you send it has a header with a fixed-size field called paramSize. That field tells the TPM how many bytes follow. If the number Windows puts in that field doesn't match the bytes actually sent, the TPM refuses the command and returns 0x80280019. It's not a hardware failure in the usual sense — it's a disagreement between the OS TPM driver and the firmware over how big the command should be.

Three things cause that disagreement:

Stale or mismatched TPM firmware. The TPM stores persistent state across reboots. An OS update that changes the driver's command framing without a matching firmware update leaves the two sides out of sync.
A corrupted TPM ownership blob. The owner auth and SRK live in NVRAM. If that region gets partially written — a hard power-off during a BitLocker enable is the classic trigger — subsequent commands carry wrong length prefixes.
Wrong TPM mode in UEFI. On AMD Ryzen boards with fTPM (AMD PSP) and Intel boards with PTT, switching between discrete and firmware TPM modes without clearing leaves the software side talking to a device that doesn't match its cached capability descriptor.

The reason this is confusing is that Device Manager often shows the TPM as healthy. The device enumerates fine. It's only when a command with a variable-length payload (attestation, sealing, key creation) hits the TPM that the size mismatch surfaces.

Fix it

Confirm it's the TPM and not something upstream. Open an elevated PowerShell and run:
```
tpmtool getdeviceinformation
Get-Tpm
```
If Get-Tpm reports TpmReady: False or TpmPresent: True, TpmEnabled: True, TpmOwned: False combined with a 0x80280019 in Event Viewer under Microsoft-Windows-TPM-WMI/Operational, you're in the right place.
Update the TPM firmware from the OEM, not Windows Update. Windows Update ships a generic driver; the firmware comes from Dell Command Update, HP Image Assistant, Lenovo Vantage, or your motherboard vendor's support page. Check the installed version first:
```
Get-WmiObject -Namespace root\CIMV2\Security\MicrosoftTpm -Class Win32_Tpm | Select-Object ManufacturerIdTxt, ManufacturerVersion, SpecVersion
```
Compare against the latest your OEM lists. Nuvoton and Infineon both shipped firmware revisions in 2022–2024 that explicitly fixed paramSize handling in attestation paths. Flashing is a one-click process but the machine reboots twice; don't interrupt it.
Clear the TPM if firmware is already current. This wipes the owner blob and forces Windows to reinitialize the command framing from scratch. It also destroys any keys sealed to the TPM, so suspend BitLocker first:
```
Suspend-BitLocker -MountPoint "C:" -RebootCount 2
Clear-Tpm
```
Then reboot. Windows will take ownership on next boot. If you use a PIN or Windows Hello, expect to re-enroll.
Check the UEFI TPM mode. Reboot into firmware setup. On Intel boards look for Security > PTT; on AMD look for Security > AMD fTPM or Firmware TPM. If the board has both a discrete TPM header and PTT/fTPM, make sure only one is active. Running both is a known cause of 0x80280019 because the ACPI table advertises one device while the driver binds to the other.
Re-enroll the TPM in Windows. After clearing, force a fresh handshake:
```
Initialize-Tpm -AllowClear -AllowPhysicalPresence
```
Then verify with Get-Tpm — you want TpmReady: True.

If it still fails

Run tpmtool getdeviceinformation again and look at the TPM version line. If it says Not Present after a clear, the TPM dropped off the bus — check Device Manager for a yellow-bang entry under Security devices and disable/re-enable it, or uninstall the driver and let Windows redetect. If it comes back but 0x80280019 persists, the persistent NVRAM is likely damaged at the silicon level and a firmware recovery flash (some vendors call it TPM Revoke or Manufacturer Reset) is the only remaining option. On a laptop that means an RMA if the OEM doesn't publish the tool.

Two more things worth checking: the system clock. TPM commands carry a nonce and some firmware validates timestamp-adjacent fields loosely against the RTC. A dead CMOS battery producing a 2019 date has triggered this error on Optiplex 7060 units. Also, if you're on a domain, policy Computer Configuration > Administrative Templates > System > Trusted Platform Module Services can block Clear-Tpm even for local admins — check Get-Tpm's LockedOut and LockoutHealTime values before assuming the clear worked.

Don't run Disable-TpmAutoProvisioning as a workaround. It hides the symptom and breaks attestation-based Conditional Access later.