Random STATUS_ACCESS_VIOLATION and BSODs with Discord, Chromium, and an RTX 5090

0
0
Asked By MellowOrbit42 On

I'm troubleshooting a series of crashes that began after recent Windows 11 and NVIDIA updates. The system has Windows 11 Pro 25H2, a Ryzen 9 9950X3D, Gigabyte X870E AORUS ELITE WIFI7, 64 GB of RAM, and an RTX 5090. The PC had been stable before these updates.

The failures include Brave's STATUS_ACCESS_VIOLATION errors, Discord and other CEF subprocess crashes with 0xc0000005, dwm.exe crashes involving dwmcore.dll, and several BSODs. The stop codes have included HYPERVISOR_ERROR, DRIVER_OVERRAN_STACK_BUFFER, and PAGE_FAULT_IN_NONPAGED_AREA.

The most repeatable BSOD pattern is a 0x50 crash with NVDisplay.Cont as the active process and a stack through dxgkrnl!DxgkEscape and dxgkrnl!memcpy. WinDbg identified the invalid access as a write, although nvlddmkm.sys does not appear directly in the stack. Another HYPERVISOR_ERROR pointed toward AMD CPU idle and power-state handling.

I rolled Windows back to build 26200.9168, disabled Global C-States, disabled hardware video decoding in Brave, used DDU, and tested NVIDIA driver 616.92. The crashes continued. I then tested driver 610.74, but the same graphics-kernel crash eventually returned, so this no longer looks specific to 616.92.

Memory Diagnostic, OCCT memory, CPU/RAM, VRAM, and 3D tests all passed for about an hour each. Gaming and heavy workloads are generally stable, while crashes happen more often during light desktop use, browsing, Discord, Spotify, or idle periods. Updating the AMD chipset drivers did not help.

Disabling VBS, Memory Integrity, and SVM made HypervisorPresent report False and appears to have stopped the HYPERVISOR_ERROR crashes, but Brave and CEF instability continued. I'm currently testing a minimal NVIDIA installation with only the graphics driver and PhysX, without the NVIDIA App, overlays, or extra components. If that fails, I plan to update the motherboard BIOS/AGESA.

Does this pattern point more toward a graphics-stack problem, unstable memory or CPU settings, firmware, or something else?

4 Answers

Answered By KernelKite88 On

The dump files are the most useful next step here. Several different bugchecks and application access violations can be caused by one underlying memory-corruption problem, even when the crash names point at the GPU, browser, or Windows memory manager. Comparing multiple minidumps should help determine whether the same driver or corrupted address appears repeatedly.

Answered By SilverMango53 On

A minimal NVIDIA installation is a good isolation test. Keep the system in that state long enough to reproduce the normal Brave, Discord, and Spotify workload, then compare the results with the older driver. I’d also test with browser and Discord hardware acceleration disabled, verify the motherboard BIOS and chipset package, and run a longer memory test outside Windows if the crashes continue.

Answered By QuietCedar19 On

The fact that heavy gaming and stress tests pass while browsing and idle use fail is consistent with a low-power or state-transition problem rather than a simple load problem. Disabling SVM and the hypervisor stopping the HYPERVISOR_ERROR is a useful clue, but it doesn’t explain the remaining CEF and graphics crashes. BIOS/AGESA updates, completely stock BIOS settings, and testing without memory overclocking or other tuning would be sensible next steps.

Answered By ByteHarbor7 On

The crashes don’t prove that the NVIDIA driver is defective. A failure in dxgkrnl while NVDisplay.Cont is active can also be the result of corrupted memory, firmware, PCIe issues, or another kernel component damaging data earlier. Since the same PAGE_FAULT pattern returned on both 616.92 and 610.74, I would broaden the investigation beyond that driver version.

Related Questions

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.