Fix TPM_E_PER_NOWRITE (0X8028003F) in Windows

When You See This Error

You're updating your TPM firmware on a Dell Precision 5820 or Lenovo ThinkPad P1, and the updater spits out TPM_E_PER_NOWRITE (0X8028003F) with the message "There is no protection on the write to the NV area." This also happens when you try to define a new NV index using the TPM Base Services API in a custom app — the write just gets rejected even though you have admin rights. I've seen it most often during motherboard swaps or after a BIOS update that resets TPM ownership.

Why It Happens

The TPM's Non-Volatile (NV) area stores things like keys, attestation data, and platform configuration registers. Every NV index has a write-lock attribute — a hash or policy that protects it from being overwritten accidentally. When that protection is missing or corrupted, the TPM halts the write with 0x8028003F. Think of it like a safe without a combination lock: the TPM refuses to put anything valuable inside because the lock isn't working.

Root causes I've tracked down:

Corrupted TPM NV storage after a failed firmware update.
Partial TPM ownership change — you took ownership but the NV indices weren't reset properly.
BIOS-level write-lock flag stuck — some motherboards have a physical or UEFI switch that enables NV write protection, and it's stuck in an inconsistent state.

The Fix: Clear the NV Index

Skip reinstalling the TPM driver — that won't touch NV storage. The real fix is to clear the specific NV index that's failing. You'll need the tpm.msc console or PowerShell with admin rights.

Step 1: Identify the Problematic NV Index

Press Win + R, type tpm.msc, hit Enter.


  In the TPM Management console, look under TPM Actions → Clear TPM. Don't click it yet — we need the index first.
  Open PowerShell as Administrator and run:

  Get-TpmEndorsementKeyInfo -HashAlgorithm Sha256
  This lists all NV indices. Look for any with a status of Conflict or Uninitialized. If you're chasing a specific app error, search for the index value in the error log (often shown as an 8-digit hex number like 0x001000A0).



Step 2: Clear the NV Index
If you're sure which index is corrupted (common ones are 0x001000A0 for TPM 2.0 storage keys), use PowerShell to delete it:
Clear-Tpm -ProvisioningMethod FullWipe
This wipes all NV indices and TPM keys. On a domain-joined machine, you'll need to re-enroll BitLocker and sign back into Windows Hello. If you want to clear just one index, try (rarely works but worth a shot):
Remove-TpmNvIndex -Index 0x001000A0

Step 3: Reprovision the TPM

  After clearing, close everything and reboot.
  Open PowerShell as Admin again and run:

  Initialize-Tpm -AllowPhysicalPresence
  
  Confirm the physical presence prompt (yes, you'll need to press a key during boot on some systems).
  Run:

  Set-TpmOwnerAuth -OwnerAuth (ConvertTo-SecureString -String "yourpassword" -AsPlainText -Force)
  Use a strong password — this locks the TPM from unauthorized writes.


If It Still Fails
Check three things:

  BIOS/UEFI setting — Reboot into BIOS (F2 on Dell, F1 on Lenovo). Look for TPM State or NV Write Protection. On some HP ZBooks, there's a hidden option called "TPM NV Policy" that must be set to Enabled (default). If it's disabled, the TPM won't write new NV indices.
  TPM firmware version — Run wmic /namespace:\\root\cimv2\Security\MicrosoftTpm path Win32_Tpm get SpecVersion. Anything below 1.2 is ancient; TPM 2.0 devices should be at firmware 5.63 or higher. Update the firmware from your OEM's support site.
  Physical presence (PPI) — Some cheap SSDs or USB hubs interfere with TPM commands. Unplug all non-essential peripherals (especially external drives) and try the clear again.

If none of that works, you're looking at a hardware-level TPM failure. On a desktop, you can replace the TPM module (Dell sells them for ~$30). On a laptop, it's soldered — time for a warranty claim.