u/Breeze23412

I'm experiencing a severe upload issue with my Archer GE800 V1.0, firmware 1.4.1 Build 20260728, when using VPN Merge with Windscribe WireGuard.

Same Ethernet connection, completely different results:

• GE800 VPN Merge: ~1,400 Mbps down / 0.15 Mbps up
• Windows Windscribe WireGuard (VPN Merge OFF): ~1,430 Mbps down / 956 Mbps up
• PC1 Windows Ethernet through VPN Merge: 0.25 Mbps up
• PC1 Ubuntu Ethernet through VPN Merge: 7 Mbps up
• PC1 Wi-Fi through VPN Merge: 839 Mbps up

I've spent days troubleshooting. New WireGuard profiles, different ports/servers, MTU, NIC settings, router reboots, and restoring configurations from September and October all failed.

Even disabling IPv6 after discovering thousands of DHCPv6 errors made no difference.

Everything points toward the GE800's wired VPN Merge processing, but the exact cause remains unknown.

Has anyone experienced this or found a fix? Particularly interested in firmware bugs, hardware acceleration, or WireGuard forwarding issues.

Already contacted TP-Link support. Screenshots available.

I have no idea what happened here, i checked out with the "make wifi great again" promo and a minute later i have a full price charge on my account. I dont know how this happened and there is no human to chat with about this. This literally happened 5 mins ago and i just want this figured out. Im a relatively new patron and i just want to chat with support or a mod about this issue.

Edit: resolved super fast, major thanks to the staff at Windscribe. You guys are awesome!

I have been troubleshooting a pretty unusual instability problem on my main PC and I'm looking for ideas from people who have dealt with 13th/14th-gen Intel, Z790, WHEA errors, BIOS issues, or difficult CPU-vs-motherboard failures.

I'm trying to diagnose this methodically rather than randomly changing voltages, reinstalling Windows, or replacing parts until something happens to work.

SYSTEM

CPU: Intel Core i7-14700K

Motherboard: ASUS ROG Maximus Z790 Hero

RAM: 32 GB G.Skill Trident Z5 DDR5-6000, 2x16 GB in A2/B2

GPU: RTX 4090

PSU: EVGA SuperNOVA 1300 W

OS: Windows 11 Pro

Controlled testing has been done with:

XMP: Disabled

RAM: DDR5-4800

Manual CPU overclock: None

Manual undervolt: None

ASUS MCE: Disabled / Intel limits enforced

THE MAIN PROBLEM

I have been getting repeated:

IRQL_NOT_LESS_OR_EQUAL (0xA)

and several:

HYPERVISOR_ERROR (0x20001)

BSODs.

Windows often shows:

What failed: ntoskrnl.exe

but I'm not assuming ntoskrnl.exe itself is actually the cause.

I have full kernel dumps, and several of the 0xA crashes are unusually similar.

Multiple analyzed dumps converge around:

Arg1 = 0x483d3844

Arg2 = 0xff

PROCESS_NAME = System

nt!KiUpdateThreadHgsFeedback+0x20

Failure bucket:

AV_nt!KiUpdateThreadHgsFeedback

At least two dumps also produced the same failure hash.

Arg3 has differed, so they are not literally identical crashes.

The saved instruction at the reported fault location is:

mov r14b,r9b

which is just a register-to-register operation and doesn't obviously explain the reported access to 0x483d3844.

That makes me wonder whether the visible crash site is downstream of some earlier corrupted CPU/kernel state rather than the original fault.

WHEA CPU/CACHE ERRORS

One of the better captured incidents had WHEA Event 2 records immediately before the crash.

They decoded as:

ProcessorNumber: 14

APIC ID: 0x38

Generic Processor Error

Cache Error

Instruction Execution

Level 0

and:

ProcessorNumber: 15

APIC ID: 0x39

Generic Processor Error

Cache Error

Instruction Execution

Level 0

The associated 0xA kernel dump was also executing on processor 14 when it crashed.

I have NOT yet mapped ProcessorNumber 14/15 or APIC 0x38/0x39 to exact physical P/E cores, so I'm not claiming those are definitely one physical P-core.

THE BIGGEST CLUE: 7 P-CORES VS 8

With all 8 P-cores enabled:

Windows reports 28 logical processors.

The system is repeatedly unstable and crashes.

I changed the ASUS BIOS setting to only 7 active P-cores.

Windows then reported 26 logical processors:

7 P-cores with HT = 14 threads

12 E-cores = 12 threads

Total = 26

That made an enormous difference.

The machine survived about 90 minutes while I intentionally used it with:

Brave / ChatGPT

PowerShell

Hyper-V

WSL2

Docker Desktop

multiple Docker containers

normal Windows usage

During that test:

No new WHEA

No BugCheck 1001

No Kernel-Power 41

No Event 6008

I later returned it to all 8 P-cores / 28 logical processors.

The instability came back.

I don't yet know exactly which physical P-core the ASUS BIOS removes when set to 7, so I'm NOT saying this proves one bad core.

But this is currently the strongest behavioral clue I have.

BIOS TIMELINE

The motherboard was originally running ASUS BIOS 3001.

A rarer version of this same unusual 0xA crash family had already happened on BIOS 3001, so I cannot honestly say the newest BIOS created the underlying fault from nothing.

I then updated the Z790 Hero to BIOS 3202.

The severe crash storm began on the FIRST Windows boot after that BIOS update.

From that point onward I started getting repeated:

0xA

HYPERVISOR_ERROR

WHEA processor/cache errors

at a much higher frequency than before.

Because the timing was so obvious, I eventually rolled the board back from BIOS 3202 to 3001.

Unfortunately, the rollback has not immediately fixed it.

First boot after rollback:

The machine crashed before I got to a usable Windows desktop.

Second boot:

Windows loaded and lasted about five minutes before another:

IRQL_NOT_LESS_OR_EQUAL (0xA)

with:

What failed: ntoskrnl.exe

I haven't analyzed that newest MEMORY.DMP yet, so I'm not claiming it has the exact same internal signature until I verify it.

I also have not yet recaptured every BIOS setting and active-core count after the rollback, so I'm NOT claiming that my known-good-ish "3001 + 7 P-core" configuration has failed.

Another complication is that ASUS says the newer Intel Management Engine firmware installed by BIOS 3202 remains even after rolling the BIOS image back.

So returning to BIOS 3001 does not necessarily restore the exact complete firmware state I had before installing 3202.

HYPER-V TESTING

Because I've had HYPERVISOR_ERROR crashes and the 0xA dumps involve KiUpdateThreadHgsFeedback, I tested Hyper-V separately.

I disabled:

hypervisorlaunchtype = Off

vsmlaunchtype = Off

The system still reproduced the recurring 0xA.

So Hyper-V is not required for the failure.

On the other hand, with only 7 P-cores active I was able to run:

Hyper-V enabled

VBS disabled

WSL2

Docker Desktop

without reproducing the crash during the long stability test.

That makes Hyper-V look more like something that can expose or amplify the instability rather than the root cause by itself.

SAFE MODE / CLEAN BOOT / HARDWARE MONITORING SOFTWARE

Safe Mode with all 8 P-cores initially survived noticeably better than normal Windows.

I also did a very broad Clean Boot and disabled roughly:

65 third-party services

12 Run entries

5 Startup entries

9 scheduled tasks

That also improved short-term stability.

This PC has several low-level hardware monitoring/control applications installed, including:

ASUS Armoury Crate / Fan Control

Corsair iCUE / CPUID

TT RGB PLUS / LibHWInfo / HWiNFO

AquaComputer

GPU-Z

MSI Afterburner

Intel XTU/platform components

I selectively restored some of them.

A few restore attempts happened at the same time as WHEA events or HYPERVISOR_ERROR crashes.

Other low-level monitoring drivers could be restored without immediately causing anything.

So I don't think I have enough evidence to blame one of those programs as the underlying root cause.

They may simply be hardware-polling triggers that make an already marginal CPU/platform condition easier to expose.

OTHER HARDWARE HISTORY

There was also one older, physically different failure where the entire PC instantly went black, motherboard decorative LEDs stayed illuminated, the case power button stopped responding, and I had to remove AC power before the system could restart.

That incident produced no dump and looked like a latched power/platform event.

I'm keeping that separate from the current repeated BSOD/WHEA family because the behavior was completely different.

The PSU is an EVGA SuperNOVA 1300 W and is around four years old.

So PSU/motherboard power behavior is still somewhere in the overall fault tree, but the current WHEA/cache/core evidence looks like a different failure mode.

CURRENT WORKING POSSIBILITIES

Right now I think the serious candidates are:

- marginal/degraded 14700K or one physical P-core/cache path

- motherboard/socket/VRM/platform issue

- BIOS / Management Engine / microcode interaction

- RAM / IMC problem

- low-level hardware driver triggering an otherwise marginal condition

- some combination of the above

I'm deliberately NOT assuming "bad CPU" or "bad BIOS" yet.

WHAT WOULD YOU TEST NEXT?

I'm especially interested in input on these:

1. Does 7 active P-cores being dramatically more stable than all 8 look like a realistic symptom of one marginal physical P-core?

2. Can WHEA Generic Processor Error + Cache Error + Instruction Execution be caused by motherboard/voltage/firmware issues, or does that strongly favor the CPU?

3. What is the best way to map:

   ProcessorNumber 14/15

   APIC 0x38/0x39

   to the actual physical cores on a 14700K?

4. Is there a reliable way to identify which P-core ASUS disables when selecting only 7 active P-cores?

5. Is there a sensible way to stress/test one physical P-core at a time without changing voltage or clocks enough to hide the actual failure?

6. Would you test CPU/cache first, RAM/IMC first, or substitute a known-good CPU first?

7. If another LGA1700 CPU completely fixes the problem in this board, is that enough evidence to RMA the 14700K?

8. If the 14700K shows the same problem in another Z790 board, I assume that would essentially settle the CPU question?

9. Is there any useful motherboard/VRM/socket test that can distinguish the board from the CPU before I start swapping hardware?

10. Has anyone here had a 13th/14th-gen Intel system where lowering the number of active P-cores produced this dramatic a stability improvement?

I have preserved:

full MEMORY.DMP files

minidumps

WinDbg output

WHEA records

Event Viewer logs

BIOS/core-count captures

7-vs-8-P-core test results

If there are specific WinDbg commands, WHEA details, CPU topology outputs or stress-test methods that would actually help isolate this, I can post them.

I'm mainly trying to figure out what failure layer this evidence points to and what the cleanest next discriminator is, rather than just finding settings that make the PC stop crashing.

I have been methodically investigating a recurring Windows 11 crash problem and now have enough dump/WHEA evidence that I am looking for help deciding what diagnostic branch to take next.

I'm specifically trying to distinguish:

CPU/core/cache instability

vs.

motherboard / firmware / IMC / platform instability

vs.

a low-level kernel driver interaction

rather than randomly changing settings until the machine appears stable.

SYSTEM

Motherboard: ASUS ROG Maximus Z790 Hero

CPU: Intel Core i7-14700K

RAM: 32 GB G.Skill Trident Z5 DDR5-6000, 2x16 GB in A2/B2

GPU: NVIDIA RTX 4090

PSU: EVGA SuperNOVA 1300 W

OS: Windows 11 Pro

Controlled tests have been run with:

XMP: Disabled

RAM: DDR5-4800

No current manual CPU overclock

No current manual undervolt

ASUS MCE disabled / Intel limits enforced

CURRENT FAILURE TYPES

The two recurring BSOD families are:

IRQL_NOT_LESS_OR_EQUAL (0xA)

and:

HYPERVISOR_ERROR (0x20001)

The 0xA failures have been unusually repeatable.

Multiple analyzed full/kernel dumps converge on:

Arg1 = 00000000483d3844

Arg2 = 00000000000000ff

PROCESS_NAME: System

SYMBOL_NAME:

nt!KiUpdateThreadHgsFeedback+0x20

FAILURE_BUCKET_ID:

AV_nt!KiUpdateThreadHgsFeedback

At least two dumps also produced the same failure hash.

Arg3 has differed between crashes.

The saved instruction at the faulting location was:

mov r14b,r9b

which is register-to-register and does not obviously account for the reported access to 0x483d3844.

That makes me suspect the debugger may be seeing a downstream crash site after some earlier state corruption rather than the original bad operation.

Windows displays ntoskrnl.exe on some BSODs, but I am not treating ntoskrnl.exe itself as the culprit.

WHEA EVIDENCE

Immediately before one well-captured crash, WHEA Event 2 records reported:

ProcessorNumber 14

APIC ID 0x38

Generic Processor Error

Cache Error

Instruction Execution

Level 0

and:

ProcessorNumber 15

APIC ID 0x39

Generic Processor Error

Cache Error

Instruction Execution

Level 0

The associated 0xA dump was also executing on processor 14 when the crash occurred.

I have not yet mapped those processor numbers/APIC IDs conclusively to the physical P/E-core topology.

MOST USEFUL CONTROLLED TEST SO FAR

With all 8 P-cores enabled:

28 logical processors

Frequent instability / crashes.

I reduced the ASUS BIOS setting to 7 active P-cores.

Windows then reported 26 logical processors.

That configuration survived approximately 90 minutes while actively running:

Brave/ChatGPT

PowerShell

Hyper-V

WSL2

Docker Desktop

multiple Docker containers

normal desktop use

During that observation period:

No WHEA

No BugCheck 1001

No Kernel-Power 41

No Event 6008

I subsequently restored all 8 P-cores / 28 logical processors.

The instability returned.

I do NOT yet know which physical P-core the firmware disables when selecting seven, so I do not consider this proof of a specific defective core.

It is nevertheless the strongest behavioral discriminator I've found.

BIOS TIMELINE

The board was previously running ASUS BIOS 3001.

A rare instance of this same unusual 0xA fault family occurred on BIOS 3001, so the underlying issue existed before the latest BIOS update.

I then updated the board to BIOS 3202.

The rapid crash storm began on the FIRST Windows boot after that update.

After 3202 I experienced repeat 0xA crashes, HYPERVISOR_ERROR crashes and WHEA events at a much higher frequency.

Because of that timing, I rolled the BIOS back to 3001.

The rollback did not immediately restore stability:

First post-rollback boot:

Crashed before reaching a usable Windows desktop.

Second post-rollback boot:

Reached Windows and lasted approximately five minutes before another IRQL_NOT_LESS_OR_EQUAL 0xA.

I have not yet analyzed that latest MEMORY.DMP, so I am not claiming its internal signature matches the earlier dumps until that is verified.

I also have not yet recaptured the exact active-core count and every BIOS option after the rollback.

Therefore I am NOT claiming that "BIOS 3001 + the known-stable 7-P-core configuration" has failed.

ASUS also states that the newer Intel Management Engine firmware installed by BIOS 3202 remains after rolling the BIOS image back, so this rollback does not completely recreate the old firmware environment.

HYPER-V / VBS TESTING

Because several crashes involve HYPERVISOR_ERROR, I explicitly disabled:

hypervisorlaunchtype = Off

vsmlaunchtype = Off

The same recurring 0xA still occurred.

Therefore Hyper-V is not required to reproduce the fault.

Conversely, the 7-P-core configuration later ran Hyper-V enabled, VBS disabled, WSL2 and Docker without failing during the long test.

That makes Hyper-V look more like a trigger/exposure path than a sufficient root cause.

SAFE MODE / CLEAN BOOT

Safe Mode with all 8 P-cores initially survived a short test considerably better than normal Windows.

I then performed a broad Clean Boot disabling roughly:

65 third-party services

12 Run entries

5 Startup entries

9 scheduled tasks

This substantially improved short-term stability.

The machine has several applications that use low-level hardware monitoring/control:

ASUS Armoury Crate / Fan Control

Corsair iCUE / CPUID

TT RGB PLUS / LibHWInfo / HWiNFO

AquaComputer

GPU-Z

Intel platform/XTU components

I performed controlled restoration tests.

Some restores happened at the same time as WHEA or HYPERVISOR_ERROR events.

Other low-level monitoring stacks could be restored without an immediate failure.

I therefore do NOT think the available evidence identifies one particular third-party service as the root cause.

It remains possible that these kernel/hardware-access drivers are simply exposing an underlying marginal hardware/platform state.

OTHER IMPORTANT HISTORY

There has also been a separate older incident where the entire machine instantly blacked out, motherboard decorative LEDs remained illuminated, the power button did nothing, and AC power had to be removed before the machine could restart.

That event produced no bugcheck or dump and looked more like a latched power/platform fault.

I am keeping that event separate from the current repeated 0xA / WHEA / HYPERVISOR_ERROR family because the physical behavior was very different.

PSU is an EVGA SuperNOVA 1300 W and is approximately four years old.

I mention this because it means motherboard/PSU/platform power delivery cannot be completely excluded, although the current repeatable processor/cache/WHEA behavior seems like a different failure mode.

WHAT I NEED HELP WITH

I'm not looking for a replacement-part recommendation. I'm looking for the next diagnostic that gives the highest information value.

Specifically:

1. How would you distinguish a marginal CPU/core/cache path from motherboard/firmware instability given this evidence?

2. Is the WHEA combination of Generic Processor Error + Cache Error + Instruction Execution strong evidence for the CPU itself, or can motherboard/firmware/voltage instability produce the same records?

3. What is the best way to map WHEA ProcessorNumber 14/15 and APIC IDs 0x38/0x39 to physical cores on this hybrid Intel CPU?

4. Is there a sound way to test one P-core at a time without changing voltage/frequency enough to mask the problem?

5. Would CPU affinity + a per-core stress workload provide meaningful isolation, and if so, what workload/logging methodology would you use?

6. Should I prioritize testing:

   - individual CPU cores/cache

   - memory/IMC

   - another CPU in this motherboard

   - this CPU in another motherboard

   - motherboard power/VRM behavior

   - some other discriminator

7. Is there additional WinDbg information I should pull from the existing full MEMORY.DMP files that could distinguish hardware corruption from a driver error?

8. For the HYPERVISOR_ERROR dump specifically, are there useful debugger extensions/fields beyond !analyze -v that could indicate whether the hypervisor died because of CPU/platform corruption?

9. Given that reducing active P-cores from 8 to 7 changes stability so dramatically, is there a way to determine exactly which core ASUS removed and reproduce that isolation deliberately?

10. What test would you run next if the goal was to prove CPU vs motherboard rather than merely achieve temporary stability?

I have preserved:

- full MEMORY.DMP files

- minidumps

- WinDbg !analyze output

- WHEA records

- Event Viewer logs

- BIOS/core-count captures

- the results of the controlled 7-vs-8-P-core tests

If specific debugger commands or logs would materially help, I can provide them.

I'm trying to keep this evidence-driven and avoid simultaneously changing voltage, clocks, drivers and hardware in ways that make the result impossible to interpret.

I'm looking for input specifically from Maximus Z790 Hero owners or people familiar with recent ASUS Z790 BIOS/ME behavior.

I want to be careful about separating chronology from causality here.

An apparently related IRQL_NOT_LESS_OR_EQUAL (0xA) fault family existed occasionally before BIOS 3202 while this board was running BIOS 3001.

However, the system changed from occasional instability to a severe crash storm beginning on the FIRST Windows boot after I updated my Maximus Z790 Hero to BIOS 3202.

I cannot say that 3202 caused the underlying problem. It may have caused something new, exposed/amplified an already marginal CPU or motherboard condition, or changed firmware/platform behavior enough to make an existing rare problem reproducible.

But the timing of the crash storm beginning immediately after the 3202 update is definite.

SYSTEM:

Motherboard: ASUS ROG Maximus Z790 Hero

CPU: Intel Core i7-14700K

RAM: 32 GB G.Skill Trident Z5 DDR5-6000, 2x16 GB in A2/B2

GPU: RTX 4090

PSU: EVGA SuperNOVA 1300 W

OS: Windows 11 Pro

Previous BIOS: 3001

Updated BIOS: 3202

Current BIOS: rolled back to 3001

During controlled testing:

XMP: Disabled

RAM: DDR5-4800

Manual CPU overclock: None

Manual undervolt: None

ASUS MCE: Disabled / Enforce All Limits

WHAT HAPPENED AFTER BIOS 3202:

Starting with the first Windows boot after installing 3202, I began getting repeated:

IRQL_NOT_LESS_OR_EQUAL (0xA)

and multiple:

HYPERVISOR_ERROR (0x20001)

along with WHEA processor/cache errors.

The 0xA crashes have been extremely repetitive.

Multiple analyzed dumps have converged around:

Arg1 = 00000000483d3844

Arg2 = 00000000000000ff

PROCESS_NAME: System

nt!KiUpdateThreadHgsFeedback+0x20

Failure bucket:

AV_nt!KiUpdateThreadHgsFeedback

At least two analyzed dumps also produced the same failure hash.

Arg3 has differed, so I am not saying every crash is bit-for-bit identical.

The instruction saved at KiUpdateThreadHgsFeedback+0x20 was:

mov r14b,r9b

which is register-to-register and does not obviously explain an access to 0x483d3844.

That makes me wonder whether kernel/trap/execution state is already corrupted by the time the bugcheck occurs.

The BSOD often displays ntoskrnl.exe, but I'm not treating ntoskrnl.exe itself as the root cause.

WHEA EVIDENCE:

One BIOS-3001 incident before the 3202 update generated WHEA Event 2 records that decoded as:

ProcessorNumber: 14

APIC ID: 0x38

Generic Processor Error

Cache Error

Operation: Instruction Execution

Level: 0

and:

ProcessorNumber: 15

APIC ID: 0x39

Generic Processor Error

Cache Error

Operation: Instruction Execution

Level: 0

The associated 0xA kernel dump was also executing on processor 14 when it crashed.

I have NOT yet conclusively mapped ProcessorNumber 14/15 and those APIC IDs to the physical P/E-core topology, so I'm not claiming they correspond to one particular physical P-core.

VERY IMPORTANT 7-P-CORE VS 8-P-CORE RESULT:

During the BIOS 3202 crash storm I reduced Active Performance Cores from all 8 P-cores to 7.

Windows then reported 26 logical processors:

7 P-cores x 2 threads = 14

12 E-cores = 12

Total = 26

That produced a dramatic stability improvement.

With 7 active P-cores the system survived about 90 minutes while deliberately running:

Brave/ChatGPT

PowerShell

Hyper-V

WSL2

Docker Desktop

Multiple Docker containers

Normal desktop activity

During that observation period:

No new WHEA

No BugCheck 1001

No Kernel-Power 41

No Event 6008

I then restored all 8 P-cores / 28 logical processors.

The recurring instability returned.

I do NOT yet know which physical P-core ASUS removes when Active Performance Cores is set to 7, so I cannot say this proves one specific defective P-core.

But 7 vs 8 P-cores is currently one of the strongest discriminators I have.

HYPER-V TESTING:

Because I have had HYPERVISOR_ERROR and KiUpdateThreadHgsFeedback crashes, I completely disabled Hyper-V/VBS:

hypervisorlaunchtype = Off

vsmlaunchtype = Off

The machine still reproduced the recurring 0xA.

Therefore Hyper-V is not required to cause the failure.

Conversely, with 7 P-cores I later ran:

hypervisorlaunchtype = Auto

vsmlaunchtype = Off

along with WSL2 and Docker and remained stable during the long test.

Hyper-V may expose/amplify the condition, but it does not appear to be the sole cause.

SAFE MODE / CLEAN BOOT:

Safe Mode with all 8 P-cores initially survived around 15 minutes.

I also performed a broad Clean Boot that disabled roughly:

65 third-party services

12 Run entries

5 Startup entries

9 scheduled tasks

That improved short-term stability substantially.

There are multiple low-level hardware-monitor/control stacks installed:

ASUS Armoury Crate / Fan Control / ASUS kernel interfaces

Corsair iCUE / CPUID

TT RGB PLUS / LibHWInfo / HWiNFO

AquaComputer

GPU-Z

MSI Afterburner

Intel XTU/platform components

Some controlled restores coincided with WHEA events or HYPERVISOR_ERROR.

However, I do NOT consider that sufficient evidence to blame any individual application.

For example, one ASUS restoration attempt was followed almost immediately by HYPERVISOR_ERROR, but AsusFanControlService itself was still stopped.

The Corsair/CPUID stack produced a WHEA Event 2 at the same time it was restored during another test.

TT RGB PLUS / LibHWInfo / HWiNFO, on the other hand, successfully loaded the HWiNFO kernel driver during a controlled restore without producing an immediate WHEA or crash.

These applications may simply trigger or amplify an already marginal firmware/hardware condition.

BIOS 3202 -> 3001 ROLLBACK:

Because the crash storm started immediately after 3202, I finally rolled the board back to BIOS 3001.

Unfortunately:

First boot after rollback:

The machine crashed before I reached a usable Windows desktop.

Second boot:

Windows loaded and survived approximately five minutes before another:

IRQL_NOT_LESS_OR_EQUAL (0xA)

with:

What failed: ntoskrnl.exe

I have not yet analyzed that newest MEMORY.DMP, so I'm not claiming its internal signature is identical to the earlier dumps yet.

I also have not yet recaptured every post-flash BIOS setting and the active P-core count, so I am NOT claiming that "BIOS 3001 + 7 P-cores failed."

There is another ASUS-specific complication:

ASUS states that BIOS 3202 updates Intel Management Engine firmware to 16.1.40.2765 and that the updated ME remains installed even if the BIOS is rolled back.

BIOS 3001 originally shipped with an older ME version.

So BIOS 3001 after having installed 3202 is not necessarily the same complete firmware environment I had before the update.

WHAT I KNOW VS WHAT I DON'T:

Known:

- This 0xA fault family existed occasionally before BIOS 3202.

- The severe crash storm began on the first Windows boot after installing BIOS 3202.

- 7 active P-cores dramatically improved stability.

- Returning to 8 P-cores brought the instability back.

- WHEA records have reported processor cache/instruction-execution errors.

- Hyper-V is not required to reproduce the 0xA.

- Rolling the BIOS image back to 3001 has not immediately restored stability.

- The newer ME firmware remains after BIOS rollback according to ASUS.

Unknown:

- Whether BIOS 3202 caused, exposed, or merely amplified the underlying problem.

- Whether the CPU has a marginal/degraded physical core.

- Whether the motherboard/VRM/socket/IMC is involved.

- Whether newer ME/microcode/platform behavior is relevant.

- Whether low-level monitoring software is a cause or only a trigger.

- Which physical core is removed by the ASUS "7 active P-core" setting.

QUESTIONS FOR MAXIMUS Z790 HERO OWNERS:

1. Has anyone with this exact board seen a major increase in WHEA, 0xA or HYPERVISOR_ERROR failures after BIOS 3202?

2. Has anyone gone from 3202 back to 3001 and found that behavior did NOT return to the old 3001 baseline?

3. Could BIOS 3001 + the newer 3202-era ME firmware behave materially differently from the original 3001 + older ME combination?

4. Would BIOS 3107 be a useful intermediate discriminator, considering the ME firmware will remain at the newer version?

5. Is there a way on the Z790 Hero to disable SPECIFIC individual P-cores rather than only choosing the number of active P-cores?

6. Does anyone know exactly which physical P-core ASUS disables when selecting 7 active P-cores?

7. What's the best way to map WHEA ProcessorNumber/APIC IDs to the physical P/E cores on this board/CPU?

8. Has anyone had 7 P-cores stable while 8 repeatedly crash, and did the eventual cause turn out to be CPU, board, BIOS or ME?

9. Are there ASUS-specific diagnostic settings/tests I should use before substituting the CPU or motherboard?

I have full MEMORY.DMP files, minidumps, WHEA records, WinDbg analysis, Event Viewer evidence and BIOS/core-count captures.

I'm trying to diagnose this rather than randomly add voltage or change settings until the crashes disappear.

Any input from Z790 Hero owners who have experience with 3001, 3107 or 3202 would be especially useful.

I'm not trying to overclock this CPU. I'm posting here because I need people familiar with Intel core topology, WHEA/APIC mapping, per-core behavior, V/F behavior and stability testing.

System:

i7-14700K

ASUS ROG Maximus Z790 Hero

32 GB G.Skill DDR5-6000 2x16 GB A2/B2

RTX 4090

Windows 11 Pro

Controlled testing has been done with:

XMP disabled

DDR5-4800

No manual CPU OC

No manual undervolt

ASUS MCE disabled / Intel limits enforced

REPEATED FAILURE:

I'm getting repeated:

IRQL_NOT_LESS_OR_EQUAL (0xA)

and occasional:

HYPERVISOR_ERROR (0x20001)

Several 0xA kernel dumps converge on:

Arg1 = 0x483d3844

Arg2 = 0xff

PROCESS_NAME = System

nt!KiUpdateThreadHgsFeedback+0x20

Failure bucket:

AV_nt!KiUpdateThreadHgsFeedback

At least two dumps also have the same failure hash.

Arg3 differs between some crashes.

The saved instruction at KiUpdateThreadHgsFeedback+0x20 is:

mov r14b,r9b

so it doesn't obviously account for a memory access to 0x483d3844.

That makes me suspect the visible crash site may be downstream of already-corrupted CPU/kernel state rather than the original fault.

WHEA:

Immediately before one previously analyzed crash I captured WHEA Event 2 records:

ProcessorNumber 14

APIC ID 0x38

Generic Processor Error

Cache Error

Instruction Execution

Level 0

and:

ProcessorNumber 15

APIC ID 0x39

Generic Processor Error

Cache Error

Instruction Execution

Level 0

The associated 0xA dump was also running on logical processor 14 when it crashed.

I have NOT yet mapped ProcessorNumber 14/15 or APIC 0x38/0x39 to the exact physical P/E core.

I tested:

All 8 P-cores enabled:

28 logical processors

Repeated instability/crashes.

7 P-cores enabled:

26 logical processors

Dramatic improvement.

The 7-P-core state survived roughly 90 minutes with:

Hyper-V enabled

VBS disabled

WSL2

Docker Desktop

multiple containers

Brave

PowerShell

normal desktop activity

with:

No WHEA

No BugCheck 1001

No Kernel-Power 41

No Event 6008

I then restored all 8 P-cores and the instability returned.

I understand that "7 works, 8 doesn't" does NOT automatically prove a bad P-core because I don't yet know which physical core the ASUS BIOS disables when reducing Active Performance Cores.

BIOS / MICROCODE HISTORY:

The system was previously on ASUS BIOS 3001.

A previous 3001 dump from this same crash family showed CPU microcode 0x12F.

I then updated to BIOS 3202.

The severe crash storm began on the FIRST Windows boot after installing 3202.

The same general 0xA family had occurred before 3202, so I cannot say the BIOS created the underlying problem. It may have exposed or amplified something marginal.

I've now rolled back to 3001.

First post-rollback boot crashed before usable Windows.

Second boot survived about five minutes and then produced another 0xA.

I still need to capture the exact post-flash P-core count/settings, so this is NOT yet a controlled 3001 7-vs-8 comparison.

Also, ASUS says the newer ME firmware installed with 3202 persists through BIOS rollback, so the platform has not completely returned to its original pre-3202 firmware state.

HYPER-V:

I completely disabled Hyper-V and VBS and still reproduced the recurring 0xA.

So Hyper-V is not required.

The 7-P-core state was also able to run Hyper-V + WSL2 + Docker successfully during the stable test.

This makes me think HYPERVISOR_ERROR may be another manifestation of underlying platform instability rather than Hyper-V being the root cause.

WHAT I WANT TO TEST NEXT:

I want to stop changing random software/services and directly characterize the CPU/platform.

Questions:

1. What's the most reliable way to map Windows logical ProcessorNumber 14/15 and APIC IDs 0x38/0x39 to the physical P/E cores on a 14700K?

2. Can I reliably identify which P-core ASUS removes when "Active Performance Cores = 7"?

3. Is there a good method to selectively disable one physical P-core at a time on Z790 rather than simply selecting a total active-core count?

4. What tool/test would you use to exercise individual P-cores independently while retaining useful WHEA/APIC attribution?

5. Is OCCT per-core cycling appropriate here, or is there a better test for cache/instruction-execution instability?

6. Would you test P-core affinity at fixed clocks/Intel-default voltage, and if so, what's the cleanest methodology?

7. Are WHEA Generic Processor Error + Cache Error + Instruction Execution records useful evidence of a marginal core even when the machine isn't overclocked?

8. Does the enormous difference between 7 and 8 P-cores look more like a marginal physical core, ring/cache problem, voltage/frequency curve problem, or something elsewhere in the platform?

9. Is there any diagnostic value in carefully testing fixed conservative ratios/voltage, or would that risk masking degradation rather than identifying it?

10. At what point would you stop testing and substitute/RMA the 14700K?

I have the full MEMORY.DMPs and can provide !analyze -v, !whea, !cpuinfo, processor topology or other WinDbg output if there are specific commands that would help.

My goal is not to "stabilize" a defective chip by feeding it voltage. I want to determine whether a particular core/cache/CPU path is actually faulty.

i had been chatting in a project char for about an hour when i switched to mobile app to use on the go. as soon as i did i realized the chat wasnt up to date so i pulled down as i usually would yo update the ui. instead of updating to the current chat history of the web browser instance i had been working in on my pc it stayed where it was in history. i went back to my pc and found that the last hour of chat had disappeared as well. the chat/gpt was unaware of the recent chat history and assumed i had branched the chat etc, which was not the case at all.

this happened to me once before and i basivally gaslit myself into thinking i had done something wrong or branched a chat and deleted it or something similar. this time its conclusive though, the chat history absolutely disappeared and im unable to recover it. thankfully it wasnt important project data but if it had been i would be really freaking out rn.

just seeing if anyone else has run into this and if theres either a way to rectify it or moreover to prevent it from happening in the future.

thanks all

just wanted to ask the community if they're having trouble logging into their newsdemon account via their official website. my login info is correct as I'm using it on SABNZB. I've tried using the trouble signing in section but never get an email to reset my password either.

i sent support and email yesterday but haven't heard back yet. I've logged into the site many times over the last few months but seems to have just started happening. I've had the user/pass saved in a pass manager since signing up so i know it hasn't been entered wrong nor have i forgotten the OG login.

Thanks all

Prices are wild, we all know this. I legitimately can not afford new prices so I'm hoping someone has a set i can afford.

Thanks so much for looking at my post :)

LC - Denver

ive always been a usenet guy but increasingly torrents have been becoming more and more necessary in my searches. Public trackers are fine and all but the reality of the situation is i need to get into some private trackers. Furthermore i need to figure out which trackers are worth persuing for an invite.

The invite game is a chore to be certain, i dealt with it in usenet until i was able to build a proper stack and now im set but i need to move my efforts to trackers. So anyone with support in this regard id truely appreciate. Maybe some guidance wouldnt hurt either.

Thanks all.

Iver heard they made upgrades recently, but when i tried using them a few months ago it wasnt that great with all the disconnects and high latency. my trial sub ran out and im considering whether i should pull the trigger. i got in while the doors were open so im on the fence whether to throw the opportunity away.

what do you all think? Anyone currently using them? My stack is DS, Ninja, Althub, finder, geek and nest(trial) w/ eweka and demon not sure if its even worth adding another at this point.

Got a message lock notifier while using my plus sub. The ui told me to upgrade to pro so naturally i considered it, my work requires i output results so i accepted the upgrade cost.

​

Even after doing so my account is still locked for the better part of 8 hours. Openai support chat gives the boiler plate "escalated to support specialist; you can expect a response in the coming days".

​

Is there anything i can do here? I upgraded to continue the work i was locked out of and the upgrade did nothing to resolve that issue. I feel like i was just swindled into a pro plan without reaping the benefit of continuing my work.

​

Any suggestions?

Got a message lock notifier while using my plus sub. The ui told me to upgrade to pro so naturally i considered it, my work requires i output results so i accepted the upgrade cost.

​

Even after doing so my account is still locked for the better part of 8 hours. Openai support chat gives the boiler plate "escalated to support specialist; you can expect a response in the coming days". I tried logging out, clearing browser data/cookies, reducing the model etc. Nothing works at all, complete lockout.

​

Is there anything i can do here? I upgraded to continue the work i was locked out of and the upgrade did nothing to resolve that issue. I feel like i was just swindled into a pro plan without reaping the benefit of continuing my work.

​

Any suggestions?

Every time i download something from torbox webui ill get maybe 5 or 6 mins of dl time on jdownloader before status changes to "connection problems" or "host problems?" It will count down from either 5 mins or 10 mins then start to dl again only to stop again in a few mins.

Is there a way to fix this? Theres no way to force a reconnect from what im seeing on jdownloader and i really dont think theres a connection problem, everything elae seems fine on torbox webui and my other downloads on different apps are fine/connection to internet is fine.

Super annoying.

I currently have my server in a Silverstone CS380 and while i love the fact that Silverstone has integrated SATA/SAS backplanes in their cases im willing to move away from them if it means more space in a tower/cube/workstation that accepts over 11x HDDs (what my CS380 currently accepts).

I am not going to put a restriction on what kind of case it has to be. The only stipulations are the ability to house 11x or more 3.5" HDDs, ATX mobo, ATX PSU, and a full size 40 series+ GPU. My goal is to turn my server into an AI/LLM brain so the ability to house a full size GPU is a necessity.

I really like cases like the Fractal Define 7 XL, Silverstone CS383, Phanteks Enthoo Pro 2, and Fractal Design Meshify 2 XL as a few examples.

Lmk what ya got and we can go from there, thanks!

Looking for a Coral M.2 Accelerator with Dual Edge TPU. If you have one let me know, new they are going for around $80

Need model#: G650-06076-01

Looking for a 4070 Ti Super 16gb. Im doing a bunch of AI stuff on my server and need that sweet 16gb Vram for the LLMs.

Lmk what ya got, shoot me a DM and weel go from there. Thanks!

Edit: Im in Denver for LC