ChatGPT Analyzes Windows 11 Event Viewer Logs: BitLocker Gap, ASUS Service Crash and TPM Warnings

What the author did​

The author's starting complaint was a fan stuck at about 4,700 RPM after the laptop woke from sleep. He says ChatGPT translated the log jargon and found four silent anomalies. He documents fixes for three of them. The fan problem appears in the introduction, but the article never says whether any of the three fixes cured it.

Event Viewer on any healthy PC is full of red icons. A log entry is a clue, not a diagnosis. That is the main lesson here.

Problem 1: BitLocker was encrypted but not protecting​

What the author reports:

• ChatGPT noticed 26 identical Event ID 24641 errors over a few days. He describes them as failures to retrieve the BitLocker volume master key.
• Windows 11 Settings said Device Encryption was on.
• ChatGPT told him not to trust the Settings page and to run manage-bde -status C: in an elevated PowerShell window.
• The output showed the drive 100% encrypted, Protection Status Off, Lock Status Unlocked, and no key protectors found.
• He ran manage-bde -protectors -add C: -RecoveryPassword, backed up the resulting numerical password to his Microsoft account, and says the errors stopped.

Why the output matters. Microsoft's documentation lists protection status, lock status, percentage encrypted and key protectors among the fields manage-bde -status reports. Protection Off can read like "not encrypted" at a glance, but Conversion Status and Protection Status describe different states, as the racknotes.pro guide puts it. In practice, "100% encrypted" with protection off and no protectors means the data is not meaningfully locked. It also means there is no recovery path.

The command is documented. Microsoft's operations guide lists manage-bde.exe -protectors -add C: -RecoveryPassword for adding a recovery password protector to the OS volume. Its PowerShell equivalent is Add-BitLockerKeyProtector -MountPoint C -RecoveryPasswordProtector. Microsoft's protectors reference says protector IDs can be displayed with the manage-bde -protectors -get command.

What the article doesn't establish:

• Adding a recovery password does not by itself prove protection is now on. Re-run manage-bde -status C: and manage-bde -protectors -get C: afterward. You want to see protection on and the expected protectors, normally TPM plus a numerical password, as in Microsoft's own example output.
• The author says he backed up to a Microsoft account but gives no method. Microsoft documents -aadbackup for Entra ID and -adbackup for Active Directory. Each needs the protector ID, which the -get command displays.
• Work and school machines may have different policies. Managed devices may enforce BitLocker settings or key escrow through an organisation. Ask your IT team before changing anything on those.
• Keep a copy of the recovery password somewhere other than the encrypted drive.

The author's warning is sound. Don't clear TPM or firmware security keys as a guess while recovery access is uncertain. Microsoft's own operations guide separately says disabling BitLocker should happen when protection is no longer required, and not as a troubleshooting step. That is worth remembering if you're tempted to decrypt and start over.

Problem 2: ASUS RefreshRateService crash loop​

What the author reports:

• The Application log was full of Event ID 0 entries with a NullReferenceException tied to the ASUS RefreshRateService executable. The service kept crashing and restarting.
• He uses the third-party G-Helper tool rather than ASUS Armoury Crate for fan curves and GPU switching.
• ChatGPT said the service was redundant. He disabled it through services.msc by opening the service's Properties, setting Startup type to Disabled, and clicking Stop.
• He says refresh-rate control kept working through G-Helper and the errors vanished.

Caveats. This is one machine's result. G-Helper's own documentation advises against running it alongside Armoury Crate services, which can adjust the same settings. That supports the idea that overlapping controls cause conflicts. It does not prove RefreshRateService is safe to disable on every ASUS model.

If you try something similar:

1. Confirm the exact service name and executable in the log entry.
2. Note the original Startup type so you can restore it.
3. Confirm your replacement tool actually controls the feature on your model.
4. Test refresh-rate switching on battery and on AC after the change.

If you don't use G-Helper, disabling an OEM service may remove features you rely on.

Problem 3: CertEnroll Event ID 87 and the TPM scare​

What the author reports:

• A repeated CertificateServicesClient-CertEnroll Event ID 87 in the Application log carried a hex code that he reads as a TPM key not being loaded.
• ChatGPT had him run Get-Tpm in PowerShell and check TPM-WMI Event ID 1041.
• The TPM looked present and responsive. His conclusion was a recurring software handshake failure in Intel-hosted certificate enrollment, not failing hardware.
• He left it alone and let Windows retry on its own.

Caveats. The article doesn't give the exact message, the hex code, the Get-Tpm output or the TPM-WMI event text. That makes the "safe to ignore" conclusion hard to check. I found no official Microsoft documentation saying this CertEnroll event is harmless in general.

A healthy Get-Tpm result rules out one explanation. It does not clear every possible cause. Save the full event text, timestamp, error code and nearby events. Then check whether anything actually broke, such as BitLocker, Windows Hello or device registration. If something did, treat the event as a real lead.

Either way, don't clear the TPM or flash firmware just to silence a log line. That can affect access to protected data.

A sensible workflow for your own logs​

1. Filter Event Viewer to Critical and Error events. Export the log or copy the full text of the repeating entries.
2. Ask the AI to group entries by source and event ID, and to say which are repetitive noise.
3. Treat every suggested command as a hypothesis. Read Microsoft's documentation for it first.
4. Prefer read-only checks (manage-bde -status, manage-bde -protectors -get, Get-Tpm) before anything that changes state.
5. Back up important files and your recovery key before touching encryption or security settings.
6. Remove personal details such as machine names, usernames and account identifiers before uploading logs to any online service. That is general advice, not something the article covers.

Bottom line​

The strongest finding is the BitLocker one. A Settings toggle saying "on" doesn't confirm real protection, and manage-bde -status is a quick, documented way to check. The service-disable and TPM stories are plausible but model-specific and thinly documented. Use AI to generate questions, then check the answers against the system and Microsoft's documentation.