My ASUS V16 laptop was stable until 10/09/2026, when it began showing unusually high CPU clock speeds followed by VIDEO_MEMORY_MANAGEMENT_INTERNAL (0x10E). Updating the NVIDIA driver to version 616.92 was followed by DPC_WATCHDOG_VIOLATION (0x133), so I clean-installed the older 616.56 driver. The laptop worked briefly, including during an hour of gaming, but later crashed again shortly after opening Brave.
I have since updated the BIOS, tried several older and newer Intel and NVIDIA drivers, and briefly saw SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (0x7E). I also changed permissions on nvlddmkm.sys, which was probably not appropriate. The system sometimes runs normally, but after roughly 26 minutes the GPU reaches 100% usage, the CPU runs between 3 and 5 GHz, and another 0x133 crash occurs.
Because the problem appeared around the time of the September 2026 Windows 11 security and .NET updates, I suspect an update may be involved, although I am not certain. My system is an ASUS V16 with an Intel Core 7 240H, 32 GB RAM, Windows 11 Home Single Language 25H2, and an RTX 5060 Laptop GPU with 8 GB VRAM. The post lists build 26200.9168, although that may not match the September update mentioned. I would appreciate help interpreting the crashes and deciding whether the issue is caused by a driver, Windows update, or failing hardware.
3 Answers
The most useful next step is to inspect the crash dumps rather than guessing from the stop-code names. Check C:WindowsMinidump and collect several files if they exist. If no dumps are being created, configure Windows to use small memory dumps and reproduce the crash. The dump analysis can show whether the failures consistently point to nvlddmkm.sys, an Intel driver, storage, or another component.
Since you changed permissions on nvlddmkm.sys, restore the system files with sfc /scannow. Then use a clean driver-removal process in Safe Mode, removing both the NVIDIA and Intel graphics drivers separately before reinstalling fresh versions from ASUS or the hardware manufacturers. Avoid manually modifying driver-file permissions.
It is also reasonable to pause Windows Update temporarily and uninstall the recent updates for testing. If Windows immediately reinstalls them, use the update history and recovery options to remove them, then test whether the crashes stop. However, the timing alone does not prove that Windows Update is responsible; the dump files and hardware diagnostics are still needed.
I tried removing the updates, but Windows detected that they were missing and installed them again. I will focus on restoring the drivers and system files instead of assuming the graphics driver is automatically the cause.
The dump-file upload appears to be empty, so there is not enough evidence to analyze the crashes yet. Also, build 26200.9168 appears inconsistent with the September update information in the post, so confirm the current build with winver and capture a fresh set of dumps after the next crash. Multiple different stop codes can still come from one underlying driver or hardware problem, so the changing codes do not by themselves rule out the graphics stack.
I uploaded the dump archive, but it may not have been downloaded correctly. I will also verify that the Windows build number and update dates in the system information are accurate.