Codex Computer Use - Diagnosing a Lenovo Laptop That Would Not Wake or Power On

This post is about using the Codex Windows app with computer use in a real troubleshooting workflow, but the larger story is about using Codex computer use as a practical diagnostic partner on a local machine.

The symptom was frustratingly physical: a Lenovo laptop would sometimes freeze completely or refuse to power back on after being put into sleep or hibernate. The computer still had power, but keyboard, mouse, touchscreen, lid wake, and even the normal power button path were ineffective. The only reliable recovery was to remove the bottom cover, disconnect the internal battery cable, wait, reconnect it, and then power on again.

That is not the kind of failure where Windows usually gives you a friendly error dialog. If the embedded controller or power controller gets wedged below the operating system, Windows may not know anything happened until the next boot.

The Pattern

The issue had two related forms:

1. The system froze while running.
2. The system would not wake or power on after being placed into sleep or hibernate.

The machine had a long history of rare freezes, but the no-power-after-wake behavior became more frequent after recent vendor updates. That made firmware and power-management changes suspicious, but not automatically guilty, because the broader issue predated those updates.

The important detail was the recovery method. Disconnecting the internal battery cable clears more than Windows state. It also removes standby power from always-on controller logic. That made the embedded controller, power controller, or system-board power state a prime suspect.

What Codex Could Do Locally

Using Codex in the Windows app, we were able to work directly on the machine instead of guessing from screenshots or isolated error messages.

Codex inspected Windows event logs, generated power reports, wrote capture scripts, parsed logs, checked installed driver versions, verified downloaded Lenovo packages, and compared repeated incidents. That changed the troubleshooting process from "try a setting and hope" into a timeline-based investigation.

That was the important shift. Instead of asking "what usually causes this model to freeze?", the investigation became "what did this machine record before, during, and after each specific failure?"

The most useful local tools were:

• Get-WinEvent for Event Viewer records
• powercfg /systempowerreport
• powercfg /sleepstudy
• powercfg /lastwake
• Windows Performance Recorder for heavier power tracing
• Lenovo UEFI diagnostics
• Lenovo Vantage hardware scan exports
• PowerShell scripts written by Codex to capture repeatable before-and-after evidence

Building a Timeline from Event Viewer

The first step was to stop looking at the logs as a giant pile of warnings and instead build timelines around each failure.

For hard freezes, the Windows logs showed the expected aftermath:

• Kernel-Power 41
• no bugcheck code
• no memory dump
• no WHEA hardware error
• no clean Windows explanation

That combination matters. Kernel-Power 41 does not mean "the power supply caused this." It often just means Windows noticed that the previous shutdown was not clean. In this case, the missing bugcheck and missing WHEA errors suggested that Windows did not crash in the normal sense. The machine stopped responding below the level where Windows could record the cause.

For sleep and hibernate cases, Codex compared successful and failed resumes. That was where the useful distinction appeared.

Successful sleep resumes used the normal standby path. Failed no-power cases clustered around hibernate or S4 resume behavior.

That was a major clue.

Sleep vs Hibernate Became the Practical Workaround

The laptop supported traditional S3 sleep and hibernate. It did not use Modern Standby.

Hibernate sounded attractive at first because it fully saves the session and powers down more completely. But the evidence showed that hibernate was the riskier path on this specific machine. After switching back to sleep instead of hibernate, lid-open wake behavior became normal again.

This did not prove that hibernate was the root hardware defect. It did prove that hibernate was the power path most likely to trigger the no-power state.

The practical fix was:

• stop using hibernate as the normal daily suspend method
• use sleep/S3 instead
• keep monitoring tools ready in case the deeper freeze returns

That is not a glamorous fix, and it is better described as a workaround than a board-level repair. But it was useful: the machine returned to a reliable wake pattern without replacing parts or making random firmware changes.

Custom Capture Scripts

One of the best parts of using Codex was that it created an automated, repeatable capture workflow.

Instead of manually remembering commands after every incident, Codex created a local PowerIssueMonitor folder with scripts to:

• enable extra power-related event logs
• start a capture run before reproducing the issue
• run a heartbeat logger
• optionally start Windows Performance Recorder
• stop the capture after recovery
• save event logs, power reports, and summaries into timestamped run folders

This mattered because intermittent power failures are easy to lose. If the machine only fails once every few days or months, the capture process has to be ready before the next incident.

Codex also debugged the scripts when they failed. One PowerShell helper used the same file for RedirectStandardOutput and RedirectStandardError, which Windows does not allow with Start-Process. Codex identified the error, modified the script to use separate output files, and kept the capture workflow usable.

That is a good example of computer use being more than a chatbot answer. It was local diagnosis, local scripting, local debugging, and local iteration on the same machine that had the problem.

Lenovo Diagnostics

Lenovo Vantage and Lenovo UEFI diagnostics were also used.

The hardware scans did not find a clear failing component. Battery health was reduced with age, but not obviously failed. CPU, motherboard, memory quick tests, fan, sensors, and storage checks did not explain the hard freeze or no-power wake behavior.

That result was still useful. Passing diagnostics did not rule out an intermittent embedded-controller or system-board power fault, but it reduced the likelihood of an obvious RAM, storage, fan, or battery-cell failure.

For this kind of issue, a clean diagnostic result should be read carefully:

• It does not prove the laptop is healthy.
• It does suggest the problem is intermittent or power-state-specific.
• It supports focusing on firmware, embedded controller behavior, suspend/resume transitions, and board-level power state.

Thunderbolt Noise in the Logs

The logs also showed recurring Intel Thunderbolt nhi driver errors. The repeated pattern included errors such as:

• 0xDC / 0xB1
• 0xDC / 0x7C
• 0x12D / 0x75
• 0xE0 / 0x4E

Codex traced these to Thunderbolt controller RTD3 transitions. RTD3 is a runtime low-power device state. The errors appeared during sleep and wake transitions, including successful ones.

That made them interesting, but probably not the main cause of the no-power problem.

Codex then checked the installed Thunderbolt driver and firmware state:

• The Thunderbolt controller driver was current for the model.
• Thunderbolt Control Center was installed.
• The Thunderbolt NVM firmware version matched Lenovo's current package level.
• Downloaded Lenovo Thunderbolt driver and firmware packages matched Lenovo's published checksums.

The conclusion was conservative: the Thunderbolt errors were not clean, and reinstalling the Lenovo Thunderbolt software and firmware package was a reasonable cleanup step, but the evidence did not support treating Thunderbolt as the primary cause of the dead-power behavior.

Why the Embedded Controller Stayed Suspect

The strongest clue remained the recovery procedure.

When a laptop will not respond to the power button, lid wake, keyboard, mouse, touchscreen, or external input, and only recovers after internal battery disconnect, the failure is likely below Windows.

That points toward components such as:

• embedded controller
• power-management controller
• system-board power rails
• firmware state machine
• battery or AC power handoff logic
• lid/power-button controller path

Windows can record the suspend request and the later resume, but it may not be able to record the dead interval itself. That is exactly what we saw. Some failed hibernate events did not produce a normal crash signature. Windows resumed later as though it had been hibernating, because from its perspective the operating system image was still there.

What Someone Else Can Try

If you have a similar Windows laptop issue, start with evidence before replacing hardware.

Useful checks:

1. In Event Viewer, inspect System logs around the exact freeze or failed wake time.
2. Look for Kernel-Power 41, bugcheck codes, WHEA errors, and Power-Troubleshooter wake records.
3. Run powercfg /a to see which sleep states your system actually supports.
4. Generate a power report with powercfg /systempowerreport.
5. Generate a sleep report with powercfg /sleepstudy if supported.
6. Compare successful wake events against failed wake events.
7. Check whether the failures happen more often with sleep, hibernate, hybrid sleep, lid close, AC disconnected, or docked use.
8. Run vendor diagnostics, preferably both Windows and bootable/UEFI diagnostics.
9. Check vendor firmware packages, but avoid installing random generic drivers when a model-specific package exists.
10. If the only recovery is battery disconnect or emergency reset, consider an embedded-controller or board-level power-state issue.

For this Lenovo case, the most useful behavioral test was simple: stop using hibernate and return to S3 sleep. The no-power-after-wake behavior stopped recurring during the observation window.

The Real Value of Codex Computer Use

The valuable part was not that Codex knew one magic fix. It did not, and for this kind of intermittent power failure, a single magic answer would have been suspicious anyway.

The value was that Codex could operate the computer like a careful technician:

• gather local evidence
• query Event Viewer directly
• create PowerShell tooling
• parse repeated log patterns
• compare incidents
• research model-specific Lenovo packages
• verify file hashes
• revise scripts when they failed
• keep the investigation grounded in timestamps instead of guesses

For intermittent Windows hardware and power issues, that workflow is often more important than any single command. The answer came from combining operating-system evidence, firmware context, vendor diagnostics, and repeated controlled tests.

In this case, the working resolution was to avoid hibernate and use sleep. The deeper suspected cause remained embedded-controller or system-board power-controller behavior, but the machine became usable again, and the capture tools were ready if the freeze ever returned.

That is the practical promise of Codex computer use for Windows troubleshooting: it can combine command-line access, log analysis, local scripting, web research, and careful comparison across incidents. For messy intermittent failures, that can be the difference between guessing and actually learning something.