![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(172.8, 76%, 26%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EW%3C/text%3E%3C/svg%3E)
This dump does not identify the component that originally corrupted memory; configure an Automatic or Kernel memory dump, then use Driver Verifier selectively on third-party drivers to make the offending driver fail closer to the actual corruption.
What this dump establishes
- Bug check
0x13A, parameter 10x17, means Windows found a corrupted block in a delayed-free list, commonly consistent with use-after-free or an adjacent buffer overflow.^1^ -
appid.sysencountered the damaged heap while duplicating a process token. That makes it the detection context, not proof thatappid.syscaused the earlier write. - Likewise,
steamwebhelperis the user-mode process active at the time. User-mode processes rarely cause kernel stop errors directly; they more commonly expose a defect in a driver, hardware, or Windows component.^2^ - The submitted file is a Kernel Generated Triage Dump, so it may not retain the memory needed to trace the earlier corruption.
Do not replace appid.sys, and do not reinstall Windows again based on this dump.
1. Capture a richer dump
Since the crash continued after a fresh installation with minimal software, move to evidence collection rather than repeating system-file or reinstall procedures.
- Sign in with an administrator account.
- Open Control Panel → System and Security → System → Advanced system settings.
- Under Startup and Recovery, select Settings.
- Set Write debugging information to Automatic memory dump or Kernel memory dump.
- Leave the dump path as
%SystemRoot%\MEMORY.DMP. - Ensure the paging file on the Windows/boot volume is System managed. Dump capture depends on a paging file on that volume.
- Restart the computer.^3^
After the next natural crash, preserve:
-
C:\Windows\MEMORY.DMP - The new files from
C:\Windows\Minidump - The corresponding System event log
Kernel dumps can contain sensitive data from memory; share them only through a trusted support channel.
Open MEMORY.DMP in WinDbg and run:
!analyze -v
.bugcheck
lm t n
!blackboxpnp
!blackboxbsd
!analyze -v is the normal starting point, while lm lists loaded modules and their timestamps.^4^^5^
Compare several crashes. A recurring third-party .sys module is materially stronger evidence than PROCESS_NAME or a different Windows routine appearing at the point of detection.
2. If the richer dump still names only Windows components, use Driver Verifier selectively
Warning: Driver Verifier deliberately stresses drivers and can cause additional crashes or prevent a normal boot. Microsoft recommends it for testing/debugging systems, not routine permanent use.^6^
Before enabling it, record the recovery command:
verifier /reset
Then:
- Open Command Prompt as administrator and run
verifier. - Select Create standard settings → Select driver names from a list.
- Select only suspicious third-party drivers—start with recently installed device, graphics, network, storage, RGB, monitoring, anticheat, and virtualization drivers.
- Do not select every driver at once. Test groups of roughly 10–20; verifying everything can severely degrade performance and reduce diagnostic value.^2^
- Select Finish, restart, and use the PC until Verifier produces a new crash.
- Analyze that new dump with
!analyze -v. Verifier violations often identify the driver closer to the illegal operation. - Disable Verifier afterward:
verifier /reset
shutdown /r /t 0
If Windows cannot reach the desktop, enter Safe Mode, run verifier /reset from an administrator Command Prompt, and restart. Driver Verifier cannot run in Safe Mode.^2^
Once a third-party driver is identified, obtain its replacement from the PC, motherboard, or device manufacturer. If the same corruption persists with no third-party driver implicated across multiple kernel dumps, the clean-install history makes firmware and intermittent hardware instability the next branch: load default BIOS settings, remove overclocking/undervolting, update BIOS/firmware, and test with nonessential devices removed. Microsoft’s stop-error guidance specifically includes BIOS/firmware updates and relevant hardware tests at that stage.^2^
References