Adding Third-Party RAM to My HP OMEN 30L Broke Normal Boot | Two Days of Troubleshooting with ChatGPT and Claude Code Before Giving Up on CFD

Introduction: I tried to upgrade to 64GB, but spent two days reverting to the original 32GB

I tried to add two 16GB CFD memory modules to my HP OMEN 30L to reach 64GB. It failed. Windows never successfully completed a normal boot with 64GB. I gave up on the CFD modules and decided to buy HP genuine memory instead.

The strange part was that the BIOS correctly recognized the 64GB. It passed the UEFI memory test, and Safe Mode ran stably for hours. Yet during a normal boot, the white spinning ring under the OMEN logo would stop and never progress. I had seven recorded failed attempts at a normal boot with 64GB, and zero successes.

I could not fully identify the cause. I have no evidence to say the CFD memory is defective. All I know is that adding the two CFD modules causes it to hang, while the original two modules work fine.

This article records how I used ChatGPT on my smartphone and Claude Code on my Mac to isolate the cause over about a day and a half. I honestly describe what I tried, the results, where following AI advice worked, and where it was dangerous, in chronological order.

What you will learn from this article:

• The order of troubleshooting steps when only normal boot hangs
• How to access a PC running in Safe Mode via SSH from a Mac
• A story about tweaking the BIOS based on AI suggestions, which resulted in it failing even POST
• Which memory to choose if you are upgrading memory on the same model

My Setup and Why I Wanted 64GB of RAM

Here is the configuration of the PC I am using.

Item	Details
PC	HP OMEN 30L Desktop (GT13-0xxx series)
Motherboard	HP 8703 (Intel Z490)
BIOS	AMI F.20 (2021-08-27)
CPU	Intel Core i9-10850K (10 cores, 20 threads)
GPU	NVIDIA GeForce RTX 3080 (10GB VRAM)
Original Memory	Kingston HP-specific module HP32D4U8D8HD-16XR (16GB×2, DDR4-3200, 2-rank). I thought it was "HyperX"
Empty Slots	DIMM2, DIMM4

According to HP's official specifications, the system has four DDR4 memory slots and supports up to 64GB (16GB×4). HP itself shipped configurations with 16GB×4. So, upgrading to 64GB was within the supported specifications.

However, HP Japan's specification sheet includes a note stating that "HP does not sell genuine memory as an option" and that "operation after self-upgrading is not covered by support." In other words, any upgrade is at your own risk.

Why I Wanted 64GB

I use this PC to run local LLMs at home. I keep Ollama running constantly.

When I tested large MoE models, I ran them by offloading the portion that did not fit in 10GB of VRAM to main memory. However, with 32GB, the weights did not fully fit in RAM, so the rest had to be read from the SSD every time, which made it slow. During testing, free RAM hovered around 0.1GB.

I estimated that with 64GB, the weights would fully fit in RAM, achieving speeds comparable to 27B-class models running on a Mac. However, this was an inference; I could not measure it without upgrading to 64GB. In the end, I never got to verify it.

I let AI research memory options: it listed both recommendations and “unverified” items

On October 12, 2026, I had Claude Code on my Mac (an AI agent) research candidate memory modules for an upgrade. The recommended “Option A” was the CFD Standard W4U3200CS-16G (16GB×2). This is a DDR4-3200, CL22, 1.2V, JEDEC-compliant, 1-rank product (using 16Gb chips).

The reasons for the recommendation were as follows.

• It matches the original modules’ “3200, CL22, 1.2V” specs, so XMP (settings to run memory faster than standard) is not required
• HP ships configurations with 16GB×4
• Kingston’s compatibility list by model states “16GB modules in pairs, up to 64GB,” and it included 1-rank 16GB models
• Major retailers have stock, and their listings mention a 30-day compatibility guarantee (return policy for compatibility problems) after purchase

On the other hand, the same research clearly listed “unverified points” as well.

• The original modules are inferred to be 2-rank. Adding 1-rank CFD modules would mix 2-rank and 1-rank modules in the same channel. Operation with this BIOS is unverified
• With BIOS F.20, it is unverified whether four mixed-brand modules will run at 3200
• HP’s community (unofficial) has posts stating “memory other than HP may drop to 2400” and “this motherboard is picky about memory”

The research itself stated that it would not call this recommendation a “compatible part.” In other words: it might work, but nobody had checked.

I bought the CFD 16GB×2 on Amazon for about 30,000 yen.

In hindsight, I stumbled exactly on these “unverified” parts. I should have read the AI’s research beyond just the recommendation text, including the section on points that had not been verified.

Day 1: Beep codes, a dead battery, and the white spinning ring that stopped

All times below are Japan time (JST). In the afternoon of November 1, I installed the two CFD modules in the empty DIMM2 and DIMM4 slots and turned on the power. It emitted beep codes, and no image appeared on the screen. The lights on the chassis blinked on and off repeatedly, appearing as if it was trying to boot but stopping.

In my memory, the beep codes were "two low beeps, three high beeps." However, since I am not certain, I do not treat this as an accurate beep code sequence.

I removed the CFD modules, went back to the original two, and it booted. For a moment, a message saying "CMOS Reset (502)" appeared. Later, when I read the OMEN logs, I found that the BIOS clock had reverted to January 1, 2018 every time I unplugged the power cord. The CMOS battery was already dead.

With the original 32GB, I successfully completed a normal boot three times in the afternoon (15:19, 16:28, 17:21). Between 15:23 and 16:28, I also manually ran the Windows Memory Diagnostic (standard test), which inspected the 32GB and passed with 0 errors.

Around 22:20 at night, I replaced the CMOS battery with a new one and inserted all four modules (64GB). The BIOS screen displayed "65536MB," "DDR4," "3200," and "Dual Channel," recognizing all four modules as 16384MB each.

However, during normal boots around 22:23 and 22:34, the white spinning ring under the OMEN logo stopped and did not progress. I waited for more than 10 minutes with no change. There was no blue screen and no unexpected restarts.

From 22:38, I ran the "Fast Test" for memory using HP PC Hardware Diagnostics UEFI (the diagnostic tool opened by pressing Esc → F2 immediately after powering on). It passed at 23:14. The tested capacity was 63.7GB.

Time (11/1)	Action	Result
Afternoon	Installed the CFD modules in DIMM2 and DIMM4 and powered on	Beep codes, no screen, lights blinking on and off
Afternoon	Removed the CFD modules and booted with the original two	Booted (displayed "CMOS Reset (502)")
15:19 / 16:28 / 17:21	Normal boot with the original 32GB	All three successful. Memory diagnostic also passed between 15:23 and 16:28
Around 22:20	Replaced the CMOS battery and installed all four modules	BIOS displayed 65536MB, DDR4, 3200, Dual Channel
Around 22:23 / Around 22:34	Normal boot	The white spinning ring stopped (no change for over 10 minutes)
22:38–23:14	HP UEFI diagnostics, memory Fast Test	Passed (63.7GB tested)

The situation at this point is as follows. The BIOS recognizes 64GB, and the memory tests pass. "The memory seems fine, so why won't Windows boot?" Replacing the battery resolved a separate issue (the clock reverting), but the boot failure remained.

Morning of Day 2: It works with 64GB in Safe Mode

Around 05:42 on November 2, Automatic Repair ran. However, the result was “Could not repair.” Looking at the log (SrtTrail.txt), all 29 tests were normal, and there were 0 root causes.

At 05:49, I selected “4: Enable Safe Mode” in Startup Settings on the recovery screen. It booted to the desktop with the full 64GB. Task Manager showed memory 64.0GB, DDR4, speed 3200 MT/s, slots used 4/4, and hardware reserved 136MB.

My consultant up to this point was ChatGPT on my smartphone. I took photos of the BIOS screen, beep codes, and recovery screen, had it read them, and asked for the next steps on the spot. ChatGPT also compiled a consultation history (Markdown) that distinguished events with ambiguous times as “time unknown.”

The key point is this pattern: it works in Safe Mode but stops during normal boot. Is the memory itself the cause, or is it a driver loaded only during normal boot? I cannot distinguish between these at this stage.

To read the logs properly, I wanted Claude Code on my Mac to look inside the OMEN. However, in Safe Mode without Networking, there is no IP address, and the SSH server (sshd) stopped with error “1084.” This was the next wall.

SSH into a PC in Safe Mode from a Mac

Error 1084 means "This service cannot be started in Safe Mode." I first tried to reboot using "5: Enable Safe Mode with Networking."

However, when I restarted while holding the Shift key, it entered normal boot midway and stopped at the white spinning ring again. I powered it off, re-entered the recovery screen via F11, and successfully booted into Safe Mode with Networking at 08:53.

Even then, when I connected via SSH from my Mac, the connection to port 22 timed out after 8 seconds. Ping worked, with a response time of less than 1 ms. It was not a connection refusal or an authentication failure. There was simply no listener. In Safe Mode, only services listed in the registry key SafeBoot\Network start. The working theory was that this was why (an inference).

In the meantime, Claude Code created a timeline of when the OMEN was on the network using logs from another automated process remaining on the Mac side (records of a process that periodically connects to the OMEN). On the afternoon of November 1, normal boot succeeded three times. After 21:51, it did not appear on the network even once until 08:53 the next morning. This weakened the theory that "Windows is running in the background even while stuck at the white spinning ring."

As a countermeasure, I registered sshd as a "Service" in the registry key HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Network and started sshd. The procedure written by Claude Code included commands to take a backup before changes, the content of the changes, the scope of effect, and how to revert. I executed these in the OMEN's administrator command prompt.

• Take a backup: reg export HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Network SafeBoot_Network_before.reg
• Register: reg add HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Network\sshd /ve /t REG_SZ /d Service /f
• Start: sc.exe start sshd

sshd started at 12:47, and SSH from the Mac went through at 13:06.

Note: With this setting, you can SSH in from the LAN even while in Safe Mode. This is a temporary setting intended to be reverted after the investigation is complete.

What the logs told me: Normal boot succeeded only with 32GB

After SSH connected, Claude Code created a read-only PowerShell diagnostic script. I verified via SHA-256 that the file sent to the OMEN matched the one on my Mac before executing it (1.9 minutes), then retrieved the results as a ZIP file back to my Mac for analysis.

Here is what I learned from the physical machine's records:

Finding	Evidence
Normal boot succeeded only with 32GB	The configuration file (SHIM.json) written by an NVIDIA app at 17:21:54 states "approx. 32GB physical memory" and "RAM 32768MB DDR4 3200"
Failed normal boots left no records	Zero event log entries. The system halted before the event log started (during kernel and driver initialization)
It was not a Blue Screen of Death	The "Kernel-Power 41" in the next boot has a bug check code of 0. This matches the pattern of force-terminating the halted boot via the power button
Memory breakdown	DIMM1 and 3 are Kingston (2-rank), DIMM2 and 4 are CFD (1-rank). All four report "3200, 1.2V"
The OMEN clock was 32 minutes and 18 seconds behind	After CMOS initialization, Windows synced the clock to the last shutdown time (inference). This is not the cause of the boot failure

The deciding factor was the NVIDIA app's log. At 17:21, when the last successful normal boot occurred, I could not recall from memory whether the fourth stick was already installed. I had started working on the CFD install before 17:00. The single line written by the app at startup indicated that "it was 32GB at that time." In other words, a normal boot with 64GB has never succeeded.

I also kept the GPU as a candidate. Every normal boot on November 1 recorded corrected PCIe errors (WHEA-Logger 17) from the GPU, and there were records of GPU-related Blue Screens in September.

The AI made one correction. This memory does not have ECC (error detection and correction), so memory errors are not logged to WHEA in the first place. Claude Code initially wrote "zero WHEA memory errors" as evidence of normality, then corrected itself later.

The diagnostic script itself had failures. An exception occurred in the summarization step. A specification to check hidden files was missing, causing pagefile and others to be incorrectly recorded as "none." It failed to read the boot log delimiters. Furthermore, it collected information related to the OEM version Windows product key in the BIOS, so I redacted the copy on my Mac. Even with read-only access, one must be careful about the scope of data collection.

Narrowing it down: boot logs, GPU, and memory limits

The logs alone don't tell me whether the memory or a driver is the cause. So in the afternoon, I tried changing conditions.

What I tried	Goal	Result
Enable boot logging and perform a normal boot (Startup Settings option 2)	See how far the boot process gets before stopping	Stopped at the white spinning ring. ntbtlog.txt did not gain a single line for this boot, meaning it stopped before boot logging even started. The boot record (bootstat.dat) cut off right where Boot Manager read the Code Integrity policy
Disable the NVIDIA GPU and perform a normal boot (pnputil)	Check if the GPU driver is the cause	Stopped in the same way. The NVIDIA driver was ruled out as a suspect. I re-enabled the GPU immediately
Limit Windows memory usage to 32GB (bcdedit truncatememory)	Check if it can boot with only 32GB without removing physical RAM	Rejected with the message "Cannot be changed because it is protected by Secure Boot policy." Nothing changed
Command to reboot into the BIOS screen (shutdown /r /fw)	Open BIOS remotely	Not available on this model due to error 203. I powered off and pressed F10 to open BIOS

After I told Claude Code to run the tests itself, it disabled the GPU over SSH. Before running it, we had already decided on the command to revert the change, so I reverted it immediately after seeing the result.

At this point, two candidates remained.

1. The 4-module, 64GB configuration itself is unstable during the early stages of a normal boot (memory side)
2. A component other than NVIDIA that is loaded only during a normal boot (driver side)

It stays stable for hours in Safe Mode, but stops at the exact same spot every time during a normal boot. Claude Code explained that this does not rule out the memory side. In the early stages of boot, memory is accessed in nearly the same order every time, so it is possible for unstable memory to cause a stop at the same point (inference).

I tweaked the BIOS based on AI's suggestion, and now it won't even pass POST

Next, I decided to look at the BIOS settings themselves. I took six photos of the BIOS screen with my smartphone and had ChatGPT read them. I then passed that summary to Claude Code on my Mac. Claude Code did not see the photos directly.

Inside "Advanced," there was a screen called "Memory Overclocking." The values for "Default profile" are as follows.

Item	Value
DRAM Frequency	1600 (=3200 MT/s)
tCL / tRCD / tRP	22 / 22 / 22
tRAS	52
tRFC	560
tWTR_S	0
tREFI	12480
NMode	2
Memory voltage field	1.35V

Here is Claude Code's interpretation (inference). A tRFC of 560 equals 350ns when running at 3200. This is a value intended for 8Gb chips (Kingston's 2-rank). For 16Gb chips (CFD's 1-rank), it requires 550ns, which means 880. So, it suggested changing only tRFC from 560 to 880. It also included a recovery method: if the screen doesn't appear, try powering off and on several times, and finally remove the CMOS battery.

I switched to a manual profile and set tRFC to 880. The result backfired. When I powered it on, it emitted beep codes of three low tones and two high tones, and it didn't even pass POST (the self-diagnosis immediately after powering on). It was the same no matter how many times I restarted it. Eventually, I removed the CMOS battery to reset the settings, and finally got it back to normal.

Why did POST fail? According to Claude Code's inference, when switching to manual mode, other values displayed on the screen might have been used as-is. In particular, "0" for tWTR_S is a value that requires 4 or more according to the specification.

Next, I set tRFC to 880 and tWTR_S to the minimum specified value of 4, changing only these two spots. This time, there were no beep codes, and it passed POST. However, normal boot still stopped at the white spinning ring. It became clear that the tRFC mismatch was not the sole cause.

The lesson is clear. The AI's suggestion was logical when checked against the specifications. Yet, on the actual hardware, it broke POST. Claude Code itself recorded that "changing timings manually in BIOS should only be done when there are no other options." Since I had asked about the recovery method beforehand, I was able to restore it.

The Deciding Factor: Reverting to the Original Two Sticks Changed the BIOS Screen Entirely

I asked Claude Code, “What are the chances that updating the BIOS will fix it?” The answer was “About 10–20%. It’s an estimate, not a number based on evidence,” and it did not recommend doing it for now. There were three reasons.

• The issue occurs after POST and memory checks have passed, which is not a typical case fixed by a BIOS update
• If the write fails, there is a risk of becoming unable to boot
• The mention of a newer BIOS (F.30 Rev.A) comes from posts in the HP Community; I have not verified it on actual hardware

Instead, I decided to verify points I had not yet isolated. The successful normal boot with 32GB happened only before the battery replacement. The hang with 64GB happened only after the battery replacement. “The combination of four sticks” and “the BIOS reset caused by the battery replacement” were happening simultaneously.

Around 16:57, I removed the two CFD sticks and kept only the original two Kingston sticks (32GB). When I opened the BIOS with F10, the entire “Advanced” heading had disappeared. It seems the Memory Overclocking screen appears only when non-HP memory is installed. There are posts in the HP Community stating that a “page for overclocking settings for non-HP memory” was added in F.20.

I then attempted a normal boot, and it succeeded (16:58). I checked via SSH; it was a normal boot, not Safe Mode, and I was logged in. Ollama was running, and the visible capacity was approximately 31.9GB.

This leads to the following conclusions.

• The battery replacement, BIOS reset, and Windows state are not the cause
• The cause has been narrowed down to “adding the two CFD sticks”
• It is either CFD itself (or how the BIOS handles non-HP memory) or the combination of four sticks mixing two types

To distinguish which one it is, I need to boot using only the two CFD sticks. I have not performed that check.

Conclusion: Give up on CFD and buy HP genuine memory instead

On November 2 at 17:04, I decided to "give up on CFD and buy HP genuine memory instead."

Claude Code had already provided the basis for this decision. Even if I tried with just the two CFD modules, the outcome would lead to nearly the same fix in either case.

• If it boots: The cause is "mixing two types." The fix is to make all four modules the same type
• If it fails: The cause is "CFD itself, or how the BIOS handles non-HP memory." The fix is to use HP genuine (HP-specific) memory

Either way, matching everything to HP memory is the most reliable option. A BIOS update was estimated at a "10–20%" chance of success and was not recommended.

Candidate memory modules

These are the candidates I had Claude Code research and summarize via email.

Candidate	Details	Notes
1st choice	Two used units of the same Kingston HP-specific module that is already installed (HP32D4U8D8HD-16XR; a different revision of the part number is also fine)	New units are rarely sold. Before buying, verify the "HP32D4U8D8" and "2Rx8" markings via photos of the label
2nd choice	New HP genuine accessory "HP 16GB DDR4-3200 DIMM (13L74AA)"	Retailer information indicates 2-rank, 1.2V, CL22. Since this is for business PCs, it is not verified whether it works with OMEN

Avoid the following three items.

• 1-rank 16GB
• Non-HP-branded memory
• Gaming memory that assumes XMP

Once it arrives, I will first check in BIOS that the total is 64GB and that the "Advanced" heading does not appear. If it does not appear, it seems safe to assume it is being treated as HP memory. After confirming this, I will perform a normal boot.

What I have not done

• Booting with only the two CFD modules
• Updating the BIOS
• Running the Quick Test and Extensive Test in HP's UEFI diagnostics
• Checking by lowering memory speed

I have not yet bought the HP genuine memory as of this article. The OMEN is currently running normally with the original 32GB.

What I Was Glad to Delegate to ChatGPT and Claude Code, and What Almost Went Wrong

This time, the division of labor was: smartphone ChatGPT read the screen in front of me, while Claude Code on my Mac investigated and recorded what was inside the PC. That was because, while the PC would not boot properly, the only way to get the screen contents to an AI was through the smartphone camera. We also compare the two assistants' strengths in ChatGPT vs Claude.

Task	AI Used	Result/Assessment
Read a photo of the screen and guide the steps	ChatGPT	I did not get stuck on the spot
Summarize the consultation history chronologically	ChatGPT	I could distinguish entries with ambiguous times as "time unknown"
Restore the time the OMEN was on the network from Mac-side logs	Claude Code	Weakened the theory that "Windows might be running in the background"
Get SSH working in Safe Mode	Claude Code	The procedure, which included a backup of the previous state and how to revert, was helpful
Read-only diagnostic script	Claude Code	It had a bug and ended up collecting information related to the product key
Proof that it was 32GB	Claude Code	Found records in an NVIDIA app
Test with GPU disabled	Claude Code	I gave permission to run it and reverted it immediately
Suggestion to change tRFC in BIOS	Claude Code	POST no longer passed
Expectation that a BIOS update would fix it	Claude Code	"10–20%". The AI itself stated this was an estimate without evidence
Memory selection in October	Claude Code	Got stuck on points marked as "not verified" (mixed usage, BIOS handling)

The reason it worked well was that I made them report by separating the types of information. Actual machine records, my memory, information from documents (such as forums), and inference. I made them write these four categories without mixing them. I also corrected the PC clock drift before cross-referencing the times.

When changing settings, I performed reads first. When making changes, I had it write down the previous value and how to revert before executing. I decided whether to execute. I changed only one place at a time.

The dangerous part was that AI suggestions are often "correct in terms of specifications." They do not know the quirks of OEM BIOS or the specific circumstances of my machine. It is safer not to request changes that cannot be reverted.

For those with the same symptoms: a checklist for verifying in order

Based on my experience over these two days, I would verify things in this order.

1. Verify your current memory before adding more: Check the model number and rank on the actual hardware. The original memory in my OMEN was Kingston 2-rank memory intended for HP.
2. Choose how you buy: Look at the manufacturer's compatibility list by model and buy from a store with a compatibility guarantee.
3. Don't feel safe just because of the BIOS capacity display: Even if it showed 64GB, I could not perform a normal boot.
4. Compare normal boot and Safe Mode: If only Safe Mode works, suspect both memory and drivers.
5. Enable boot logging and boot: See where it stops. If nothing is written, it is stopping at a very early stage.
6. Rule out the GPU driver: Disable the device, attempt a normal boot, and immediately revert.
7. Manually changing BIOS values is the last resort: First verify how to reset (removing the CMOS battery).
8. Revert to the original configuration and verify it works: This narrows the cause down to "what was added."
9. Check the CMOS battery too: If the clock resets to 2018 or similar every time you unplug the power, the battery is dead.

What I observed on OMEN 30L (Board 8703, BIOS F.20)

• Inserting non-HP memory causes "Advanced" (Memory Overclocking) to appear in the BIOS
• The default values on that screen included a display of 1.35V and tWTR_S set to 0
• When using only HP memory, this heading disappeared

However, I cannot say that if you have the same symptoms, this is definitely the cause. Behavior can change depending on the state of the machine or the BIOS version.

Summary

The 64GB configuration succeeded in the BIOS display and memory tests. However, it failed to perform a normal boot in Windows. Reverting to the original two modules made it work, so I narrowed the cause down to adding the CFD modules. That said, I cannot say the CFD modules are defective. I will retry the upgrade using HP genuine memory.

The AI was very fast and accurate at cross-referencing logs to build a timeline. On the other hand, its suggestion to change the BIOS settings backfired on the actual hardware. "Separate facts from inferences" and "ask about the rollback method first." These two points were the most effective this time.

If I can achieve 64GB with HP genuine memory, I will write the continuation.