TPM event logger error after cpu swap, Event id 86

Question

I just swapped out my cpu, my previous chip had died and just received my replacement, both 5950x, Upon boot I received " New cpu installed, fTPM/PSP NV corrupted" and it asked me to reset, which I did, now im receiving the following error:

SCEP Certificate enrollment initialization for Local system via https://AMD-KeyId-578c545f796951421221a4a578acdb5f682f89c8.microsoftaik.azure.net/templates/Aik/scep failed:

GetCACaps
GetCACaps: Not Found
{"Message":"The authority \"amd-keyid-578c545f796951421221a4a578acdb5f682f89c8.microsoftaik.azure.net\" does not exist."}
HTTP/1.1 404 Not Found
Date: Thu, 02 Sep 2021 14:27:28 GMT
Content-Length: 121
Content-Type: application/json; charset=utf-8
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000;includeSubDomains
x-ms-request-id: d623448f-ee97-4ff8-a54c-c552e6a999be

Method: GET(203ms)
Stage: GetCACaps
Not found (404). 0x80190194 (-2145844844 HTTP_E_STATUS_NOT_FOUND)

How can I fix this?

Answer 1

In the long of it, I believe you have "some" knowledge of what attestation involves I believe. The h/w & s/w must be trusted (e.g. UEFI/TPM = Trusted Computing [TC]). You CANNOT maneuver around the requirement for TC; albeit, every device must be certified and an Attestation (encrypted) Key generated on your device (PC). MS "Azure" server operates as the intermediary to negotiate the authenticity of the Attestation Key. In a nutshell, all h/w & s/w must roll up into the creation of the Attestation Key. Again, this occurs via UEFI/TPM - each device asserts it is certified - this effectively means an outdated driver, an old(er) incompatible h/w device or its associated outdated s/w will not pass certification to create an Attestation Key if the h/w or s/w device cannot be "attested". Each h/w & s/w device rolls up into the Attestation Key (I realize I'm repeating myself). That key is generated within two layers: (1) UEFI (which must be enabled=BIOS) and TPM (which must be enabled=BIOS); however, there's a small catch to this. While both UEFI and TPM are BIOS provisioning factors, that Attestation Key is created by the OS (in other words Microsoft). So, the Attestation Key is produced and sent to the MS Azure Server (intermediary) to certify the authenticity of the device (your PC - which includes all h/w & s/w running on your PC). If the Attestation Key fails on your machine, it can/will cause disruptions to either or both h/w &/or s/w running on the PC.

This will be a two part answer - I've exceeded the character(s) limit.

Answer 2

Two things for you to consider, perform either or both at your discretion to validate how your TC environment is behaving:

(1) Validate the state of your Attestation - Go To>Settings>Privacy & Security>Windows Security>Device Security. Ensure two things: (1) Secure Boot is on; then, (2) Go back to Device Security & click on "Security Processor Details" (located under the heading "Security processor". Note the state of Attestation for both "Attestation" and "Storage" - they should both read "Ready". If one or the other does not read "Ready", click on "Security Processor Troubleshooting" and follow the directions. This will renegotiate the Attestation Key on behalf of the Windows OS - this is rather key, note I stated the Attestation Key is being renegotiated on behalf of the Windows OS. This occurs via Windows as it communicates with the BIOS where UEFI and TPM are enabled. Then, the OS will Restart on its own. Go into Event Viewer to check for the SCEP Event ID86, and go back to Settings>etc. and check for Attestation again - it should be in the "ready" state for both "Attestation" and "Storage".

(2) Notice what we did (above) we performed these operations WITHIN the OS, we did not perform these operations w/in the BIOS. But, again, this is rather key - you CAN and I might suggest (depending on your level of confidence and abilities) go directly into the BIOS, go to the screen you established TPM w/in the BIOS. Clear the TPM keys, then simply recreate the keys - use the "default" keys is fine. This simply means you're renegotiating the encrypted TPM keys and creating a newly certified Attestation Key.

I hope this helps to address where you can find certain information and allow you to make informed decisions. If you have the time and/or inclination to learn more about TC, read the following. There are MANY areas on the Internet to find statements and documents regarding Attestation, Windows 11, TPM, etc. but note this - Windows 11 REQUIRES TC (Trusted Computing). Understanding what exactly that means will assist you greatly moving forward.

https://en.wikipedia.org/wiki/Trusted_Computing

Answer 3

Many may be interested in this read (below URL). IMO, I believe the absolute majority of BSOD issues (esp. for gamers) are related to increased (1) CPU L3 latency of the AMD family of processors and, (2) the notion of having to identify an AMD "best core" feature. This is my opinion ONLY, but others should read the article and formulate their own opinions regarding this type of information. Does this also effect SCEP attestation errors? Certainly the Attestation Key (assembled with CPU processor encrypted TC [Trusted Computing] algorithmic logic) must be able to accurately and consistently identify the "exact" processor. Does the "best core" processor get included in the Attestation Key? Does the "best core" processor change from minute-to-minute, after a Restart? I am completely unfamiliar with the process by which the Attestation Key is written at both the h/w & s/w level. None-the-less, something is amiss/askew with what appears to be AMD processors of a certain family and their ability to certify Attestation with the Azure server. I'm running Windows 11 OS build 22000.466 on ASUS PRIME X470-PRO Mobo, BIOS Vers 5861 AMD Ryzen 5 2600X with NVIDIA GeForce (GigaByte) GT1030 GPU. All of my drivers are up-to-date. I'm not a gamer, I have never received a BSOD, but the SCEP error comes and goes. My attestation as witnessed via the W11 OS is consistently in "ready" state.

https://www.pcworld.com/article/544602/windows-11-hurts-amd-ryzen-performance-even-more-than-we-thought.html

Answer 4

For all the future visitors. As for today, to get rid of the random freezes and error messages. This is the only way to fix the current issue.

Switch back to Windows 10 (Win11 licenses do work for Win10) and turn off TPM within BIOS. All errors are gone on Windows 10.

I own hardware from MSI and ASUS with the current 5k series line up and can say, that this is a AMD and MS issue. I expect it will also require a BIOS fix. For me it looks that this TPM reset and restore feature doesn't work 100% properly. I would not suggest to encrypt the harddisk on win11 because of that shaky setup.

EDIT also you m.2 disk does log all hard resets and propably this is not good for m.2 disks to get turned off like this frequently... otherwise it would be logged...

I remain follow this issue on my second build that remains on Windows 11.

Answer 5

Quick update.

It looks that after weeks of problems, my system is fine now. No crashes anymore in games or idle. I often had the problem that the system freezed but the mouse was fine or I had hard crashes into system reboot.

At the end, this is what I did.

• I installed Windows 11 by scratch, this was the result of a test as I tried Windows 10 but even on the old one, the problem remained.
• Only installed whats really required and no bloatware like antivirus, cleaners or other rubish like driver fix tools.
• Make sure you only connect devices by USB that you really need on a daily base. Don't use any USB extension cables or other fancy USB hubs - keep it simple.
• I installed a discrete TPM modul for about 20$ (propably not the reason but hey... get rid of any evenviewer error to reduce reasons for crashes)
• I fixed some 10016 events (https://www.kapilarya.com/fix-event-10016-error-the-application-specific-permission-settings-do-not-grant-local-activation-permission-in-windows-10)
• Checked then also Reliability Monitor but if you take pkt 2 seriously... then there should be no surprises
• This looks now fine as per default with a new OS installation but worth to check (https://www.tomshardware.com/how-to/disable-vbs-windows-11)
• Turned off the powersaving on my drives within windows
• Set the PSU on typical mode within BIOS.
• If you have WHEA errors with auto mode and no OC... then propably your CPU is broken. A regular AMD system should have ZERO WHEA errors except you overclock to limits..
• If you system crashes into system boot and the is no logical reason to explain.... then probably you PSU is broken or check the wires are often single cables can get loose especially with fancy sleeved cables. For example... my system was able to run stress test but crashed during games... it was the PSU.. makes no sense... then PSU..
• Only connect usb devices that you need but also change positions.. for example the front usb is different wired that the back usb... so try to use no other usb then the backplate.
• If you have messages like the disk was surprisingly removed with ID's you dont have... well thanks to you X-Box games.. MS does mount each game..
• If you have a custom PC... check that your fans do not consume more then the plug on the MB can handle..
• Make sure your beefy GPU if you have one is getting the power... if you have 3x8pin... you might need to switch to single rail mode. Do not overdrive the PSU at all..

I am aware that this is not SCEP related only... but I am sure many of you have similiar problems.