Please Help
Please Help
To the best of my understanding, AMD CPUs with integrated GPUs belong to the G series. However, this particular chip appears to be tailored for gaming, featuring its own graphics chip, yet it doesn’t fit the G series classification. There seems to be no mention of graphics output support. Still, if testing with another GPU or confirming whether this CPU actually supports iGPU output could help clarify, it might simplify the issue.
It’s generally safe to turn off the monitor during tests and logging, though it depends on your setup. Since you’re running a long test session—18 hours—and are concerned about performance issues, it’s wise to be cautious. Just make sure you don’t miss any critical signs of slowdown or freezing. Once you return home, check if the problem persists. It might be worth trying again then, especially since you noticed similar issues during video playback.
The Wi-Fi forensic data from prime95 will prove valuable. I believe the network card isn’t the main culprit for widespread file damage or crashes; deeper issues like motherboard faults, SoC problems, or power delivery failures are more likely. That said, confirming the NIC is safe remains crucial, particularly since LatencyMon highlighted ndis.sys. Disabling the network adapter in BIOS or Device Manager can be helpful only if the issue continues after adjusting BIOS settings or voltage levels. Steps to consider: 1. Update BIOS! then 2. In BIOS: EXPO / DOCP > Disabled (temporarily) Global C-State Control > Disabled Power Supply Idle Control > Typical Current Idle CPPC & CPPC Preferred Cores > Disabled Precision Boost Overdrive > Disabled PCIe ASPM / Active State Power Management > Disabled If an iGPU option exists, keep it on Auto or Off for now, we can revisit later. 3. Adjust Windows power settings: Use High Performance plan, turn off USB selective suspend, hard drive timeouts, and display sleep in Device Manager > Network Adapter; uncheck “Allow this device to turn off to save power.” Disable Energy Efficient Ethernet if available, then reboot. 4. Run LatencyMon once more. If ndis.sys still reports high DPC/ISR values, try disabling the network adapter again and retest. Ensure the system baseline is stable before isolating parts. If LatencyMon remains normal, proceed to test on another machine. If problems persist, the root cause probably lies on the motherboard—power delivery, SoC instability, or firmware issues. A CMOS reset might temporarily resolve it, helping us identify further causes. Finally, consider Prime95 combined with HWinfo logs for more detailed analysis.
Updated bios didn't resolve the issue either before posting. My current setup is at 9800x3D, around 3.30. I think I can give it another shot if needed—power settings and network adapter included. This board has two ports, but one seems problematic. Expo doesn’t work here either. It should run for a couple of weeks before it starts looping and then shutting down. I’ll just disable it and leave it as is. I also found the overnight log; nothing too alarming except temperature readings. Probably the hardware is the culprit. My experience with Asrock suggests that, unlike my past ASUS builds. The problem shouldn’t appear when I actually attempt it, so I didn’t test anything during the run. I’ll watch a video online and record a clip when it happens. It might be clearer then. I need to upload the log somewhere—74MB max. Here’s the link: https://drive.google.com/file/d/1LuvSvRA...sp=sharing Thanks again for all the help and information. It’s been over a year dealing with this. Hah.
If the log displays nothing, we'll perform a detailed scan at 50 milliseconds intervals, not overnight but only until the lag occurs, since many values will be recorded. The log currently takes about 2 seconds. I'll update you tomorrow. The first 450 lines from several thousand sensors appear normal, but we'll verify again later. Thanks for sharing; I need to sleep now and will review it after work.
Those logs reveal significant communication issues on the PCIe bus, highlighted by high error rates in 8B10B and LCRC. This usually indicates problems with signal quality or power stability, leading to data corruption. The system didn’t completely crash; instead, PCIe transfers stopped, which aligns with symptoms like freezing and audio distortion. The absence of BSOD suggests a partial failure rather than a total shutdown. Key factors include aggressive PCIe signaling errors, voltage fluctuations on the SoC rails, and failed EXPO profiles. VRM performance was erratic—dropping to 18% efficiency and spiking up to 100%—which is unusual for stable operation. These patterns point to power delivery problems or motherboard faults. The evidence strongly supports a defective board. You should proceed with an RMA if the warranty applies. This confirms your device is faulty and needs replacement.
Hey man! That sounds pretty solid and really impressive. Let's move forward. Thanks a ton for checking it out. I'm planning to purchase something new tomorrow, and I got a warranty from my micro center a year ago for this one. Appreciate your help and patience. Confirmed solution!