The next diagnostic path should focus on three areas: driver isolation, storage/file integrity checks, and crash-dump readiness.
- Prioritize driver and hardware-change isolation
- Since one earlier dump implicated
vgk.sys, uninstalling Riot Vanguard was a correct step. - Because the cold-boot crashes continued after removal, continue with the standard stop-code workflow for drivers and hardware:
- Remove or disconnect any recently added hardware, if any was added before the issue started.
- Open Device Manager by right-clicking Start and selecting Device Manager.
- Check for devices marked with an exclamation point (!).
- For any suspect device, right-click it and select Update driver.
- If updating does not help, disable or uninstall the device.
- Also check Event Viewer system logs for critical errors in the same time window as the stop codes. This is specifically recommended for bug check troubleshooting.
- Since one earlier dump implicated
- Use Safe Mode for controlled testing
- Since the failures happen during startup, use Safe Mode to reduce loaded drivers and services.
- Path:
- Go to Settings > Update and Security.
- Select Recovery > Advanced startup.
- Select Troubleshoot > Advanced Options > Startup Settings > Restart.
- After restart, choose option 4, 5, or 6 for Safe Mode.
- If the system is stable in Safe Mode after a cold boot, that strongly points toward a driver or service loaded during normal startup.
- Run file-system and system-file checks
- Since dump creation is failing and startup crashes can involve storage or corruption, run the checks Microsoft lists for stop-code troubleshooting:
- Scan disk: right-click the system drive, select Properties > Tools > Check now.
- System File Checker: run
SFC /scannow.
-
sfc /scannowwas already completed with no integrity violations, so the remaining supported check is the disk scan.
- Since dump creation is failing and startup crashes can involve storage or corruption, run the checks Microsoft lists for stop-code troubleshooting:
- Confirm free space and Windows updates
- Free space is not likely the issue here because Microsoft’s guidance is to keep roughly 10% to 15% free space available, and the reported free space appears to satisfy that.
- Still install the latest Windows updates from:
- Start > Settings > Windows Update > Check for updates
- For WHEA-related hardware stop errors, Microsoft also recommends using Windows Update to receive the latest updates and drivers before manually updating drivers.
- Check firmware and hardware basics
- Microsoft’s bug-check guidance recommends checking with the manufacturer for updated BIOS/UEFI firmware and ensuring hardware connections are sound.
- BIOS FA506NF.309 is already installed, so the remaining supported action is to verify with the manufacturer that this is still the latest BIOS for the device.
- Microsoft also recommends running the hardware diagnostics supplied by the system manufacturer for unexplained hardware-related stop codes.
- Run memory diagnostics and review results in Event Viewer
- Windows Memory Diagnostic was already run multiple times with no reported errors.
- If needed, Microsoft’s bug-check guidance says to review the result in Event Viewer under the system log and look for MemoryDiagnostics-Results.
- Crash-dump configuration and why dump creation may still fail
- The supported context confirms that crash dumps depend on page-file configuration.
- A manual kernel or complete memory dump is useful because it captures system memory at the time of the crash.
- The documented requirement is to set up page files appropriately for system crash dumps. Since automatic page-file management is already enabled and
C:\pagefile.sysexists, the next supported conclusion is that page-file configuration remains a key area to verify when dump creation fails. - The available context does not provide a supported root-cause mapping for Volume Manager event ID 161, so no specific cause should be assumed from that event alone.
- How to obtain a usable dump from the next crash
- Keep crash-dump collection enabled and ensure page-file support remains configured.
- If a crash dump is successfully written and later needs verification in a debugger session, Microsoft documents checking
IopFinalCrashDumpStatus; a value of zero means the dump process succeeded. - For deeper analysis, a kernel or complete memory dump is the most useful supported dump type mentioned in the documentation.
- What the current bugchecks suggest
- The available stop codes and the earlier
vgk.sysfinding are consistent with the Microsoft guidance that stop-code errors are commonly caused by a hardware device, its driver, or related software. - Because one crash implicated a third-party kernel driver and later crashes continued after its removal, the first subsystem to investigate is still drivers loaded during startup, followed by firmware/hardware diagnostics.
- The provided context does not support assigning
0xD1,0x162, or0x0Ato a specific ASUS, AMD, storage, ACPI, or graphics component.
- The available stop codes and the earlier
- If the issue continues after the above
- Use System Restore or other Recovery options in Windows if the issue began after a recent system change such as an update, driver installation, or app installation.
- If the system remains unstable even after Safe Mode comparison, Device Manager review, disk check, Windows Update, and manufacturer diagnostics, the remaining supported path is advanced bug-check troubleshooting with a proper crash dump.
References: