OK: here’s a new one on me. This weekend, I updated the UEFI on the Lenovo P16 Mobile Workstation. Along that update path, the P16 posts mysterious memory training message. Something along the lines of “the screen will go dark for 2 minutes while the system performs memory training.” I’d not enountered this terminology before so I was taken aback. Turns out it’s a well-known thing, tho…

Learning Ensues When P16 Posts Mysterious Memory Training Message

Apparently memory training — or as Lenovo calls it in the P16 Maintenance manual: “memory retraining” — can happen after hardware changes or following UEFI updates. Online research eventually led me to a document that explained what’s going on. It’s called DDR4 SRAM: Initialization, Training and Calibration, and it’s darned informative. In fact, it’s worth a read-through for those interested in going beyond the basics I’ll present here.

For my purposes, it was enough to know the following:

1. Device or firmware changes can affect memory timing and performance
2. Training uses an iterative approach to altering timing values
3. It converges on settings that provide a workable trade-off between speed (faster performance) and stability (fault-free memory access)
4. If your motherboard uses JEDEC timings, training/retraining is not usually required (or performed)

In fact, it’s a lot like what I used to read at Tom’s Hardware about over-clocking PC memory back in the late 1990s. Start from a safe setting, increment and try. If it works, increment again. Repeat until a failure occurs. Back off to the preceding increment. Done!

Changes Sometime Cause (Re)Training

The bottom line is that what I was entirely normal. I’d either never seen or never noticed such warnings before, but they’re typical following hardware (usually RAM module swap-outs) or firmware (including UEFI) changes. Now I know. And it gave me a good excuse to download and read around the maintenance manual for the P16. That’s always fun, too.

This morning, I recalled the value of occasional “check-and-clean” operations on the Windows Component Store (aka WinSxS). Check the “Before and After” screencap at the top of this story. It shows that applying updates can leave old components behind. Checking the component store tells you what’s up. Performing a DISM component store cleanup recovers wasted space. To wit: 1.72 GB in reported size, and 1.47 GB in actual size.

How to run DISM Component Store Cleanup

What you see in the before (left) and after (right) image is syntax to check the Windows Component Store. Run it in an admin cmd or PowerShell session, like so:

DISM /online /cleanup-image /analyzecomponentstore

Two notes. One, the output from the before (left) tells you how many reclaimable packages are found (2, in this instance). Two, it tells you whether or not component store cleanup is recommended (yes, this time around). Running the check and report syntax shown above takes 1-2 minutes on most Windows 10 and 11 PCs.

Performing the Actual Cleanup

As with the check and report DISM command, the cleanup command must also run in an administrative cmd or PowerShell session. That syntax is slightly different:
DISM /online /cleanup-image /startcomponentcleanup
Depending on how many reclaimable packages are found, and how big they are, cleanup can take upwards of 5 minutes on most Windows 10 or 11 PCs. That wait goes up, as the number (and total) size of packages increases. Be patient! I’ve only had this fail a handful of times over the years I’ve been using this tool (and many of those failures were self-inflicted because of prior use of /resetbase, which locks existing packages into place in the Component Store).

Nevertheless, this is an excellent and recommended Windows cleanup technique, which I try to run after each month’s Cumulative Update (CU) is installed. The check and report command doesn’t always find something to cleanup, but when it does, I follow up with the /startcomponentcleanup to trim down the Component Store footprint. It’s a great technique for regular Windows image management, in fact.