TechClassy
Tools

BSOD · reviewed 2026-09-01

DRIVER_PNP_WATCHDOG Stop Code diagnostic

Windows stopped because a driver failed to complete a Plug and Play operation within the allowed time. The Stop Code identifies a timed-out PnP path, not a specific storage controller, device, or driver package by itself.

High for the Stop Code familyLow until dump parameters and recurrence context are reviewed

Review the result here, then choose the context that matches what happened.

0 / 12,000 characters

Local processing · no upload

Ctrl/⌘ + Enter

Try a scenario
Resume a saved session — paste a Resume Capsule

The capsule is validated and restored only in this browser. An invalid capsule changes nothing.

Meaning & limits

What this diagnostic record establishes

Confirmed

  • Windows stopped because a driver failed to complete a Plug and Play operation within the allowed time. The Stop Code identifies a timed-out PnP path, not a specific storage controller, device, or driver package by itself.
  • The bug-check value associated with this family is 0x000001D5.

Not confirmed

  • The Stop Code alone does not identify the exact driver, device, or hardware part responsible.
  • A filename shown on screen or in a dump can be involved without being the original cause.
Applicable versions
Windows 11 on a currently supported release; Windows 10 only where Microsoft or the device vendor still supports the installed edition
Review status
verified · 2026-09-01
Evidence still needed
Exact Stop Code and bug-check value; Crash time and recurrence; Trigger scenario; Matching minidump; Recent driver, firmware, update, or hardware change

Context changes the route

At which Plug and Play stage did DRIVER_PNP_WATCHDOG appear?

Choose the context that matches your incident. These are alternatives, not a sequence of fixes. Follow only the matching check and keep its verification and rollback together.

Windows startup or restart

Likely layer: Plug and Play operation, device enumeration, driver installation, startup, update, power transition, or hardware path

First safe check: Check whether Windows produced time-matched crash evidence

Expected: A matching minidump, exact stage, and repeatable trigger provide stronger evidence than the Stop Code alone.

Steps, verification and rollback
  1. Record whether the stop occurs before the logo, during the spinning indicator, before sign-in, or after sign-in.
  2. If Windows reaches the desktop, look in %SystemRoot%\Minidump for a file whose timestamp matches the crash. If it does not reach the desktop, record that access limitation instead of forcing repeated boots.
  3. Record the Stop Code, any displayed filename, and whether the crash repeats in the same scenario.

Verify: Compare the dump timestamp and the next crash time. A displayed module is evidence to investigate, not a confirmed root cause.

Rollback: No system change is made by this check.

Link to Windows startup or restart check

Windows installation or update

Likely layer: Plug and Play operation, device enumeration, driver installation, startup, update, power transition, or hardware path

First safe check: Check whether Windows produced time-matched crash evidence

Expected: A matching minidump, exact stage, and repeatable trigger provide stronger evidence than the Stop Code alone.

Steps, verification and rollback
  1. Record the exact installation/update stage, percentage, and most recent visible message.
  2. If Windows reaches the desktop, look in %SystemRoot%\Minidump for a file whose timestamp matches the crash. If it does not reach the desktop, record that access limitation instead of forcing repeated boots.
  3. Record the Stop Code, any displayed filename, and whether the crash repeats in the same scenario.

Verify: Compare the dump timestamp and the next crash time. A displayed module is evidence to investigate, not a confirmed root cause.

Rollback: No system change is made by this check.

Link to Windows installation or update check

After connecting or changing a device

Likely layer: Plug and Play operation, device enumeration, driver installation, startup, update, power transition, or hardware path

First safe check: Check whether Windows produced time-matched crash evidence

Expected: A matching minidump, exact stage, and repeatable trigger provide stronger evidence than the Stop Code alone.

Steps, verification and rollback
  1. Record the exact device, port or connection type, and when it was added or changed. Do not disconnect active storage.
  2. If Windows reaches the desktop, look in %SystemRoot%\Minidump for a file whose timestamp matches the crash. If it does not reach the desktop, record that access limitation instead of forcing repeated boots.
  3. Record the Stop Code, any displayed filename, and whether the crash repeats in the same scenario.

Verify: Compare the dump timestamp and the next crash time. A displayed module is evidence to investigate, not a confirmed root cause.

Rollback: No system change is made by this check.

Link to After connecting or changing a device check

Sleep, wake, or shutdown

Likely layer: Plug and Play operation, device enumeration, driver installation, startup, update, power transition, or hardware path

First safe check: Check whether Windows produced time-matched crash evidence

Expected: A matching minidump, exact stage, and repeatable trigger provide stronger evidence than the Stop Code alone.

Steps, verification and rollback
  1. Record which power transition was in progress and whether the same device was connected each time.
  2. If Windows reaches the desktop, look in %SystemRoot%\Minidump for a file whose timestamp matches the crash. If it does not reach the desktop, record that access limitation instead of forcing repeated boots.
  3. Record the Stop Code, any displayed filename, and whether the crash repeats in the same scenario.

Verify: Compare the dump timestamp and the next crash time. A displayed module is evidence to investigate, not a confirmed root cause.

Rollback: No system change is made by this check.

Link to Sleep, wake, or shutdown check

Random or unknown

Likely layer: Plug and Play operation, device enumeration, driver installation, startup, update, power transition, or hardware path

First safe check: Check whether Windows produced time-matched crash evidence

Expected: A matching minidump, exact stage, and repeatable trigger provide stronger evidence than the Stop Code alone.

Steps, verification and rollback
  1. Record the exact stop time, recurrence count, and any recent driver, firmware, or hardware change without guessing which one caused it.
  2. If Windows reaches the desktop, look in %SystemRoot%\Minidump for a file whose timestamp matches the crash. If it does not reach the desktop, record that access limitation instead of forcing repeated boots.
  3. Record the Stop Code, any displayed filename, and whether the crash repeats in the same scenario.

Verify: Compare the dump timestamp and the next crash time. A displayed module is evidence to investigate, not a confirmed root cause.

Rollback: No system change is made by this check.

Link to Random or unknown check

Before any second repair step

Verify the observation and preserve the evidence

After the first safe check, record whether the reviewed intermediate result occurred, whether the original problem was retested, and the exact output. An expected observation is not automatically a repair.

Outcome boundaries

  1. Observed as expected
  2. Observed something different
  3. Result unclear
  4. Could not complete the check

Then separately record whether the original problem still occurs, was not reproduced once, or has not been retested yet. Every session ends in stop, one repeat of the same check, one named missing fact, or escalation—never an open-ended repair sequence.

Evidence fields for this task

  • Exact crash timeLocal date and time from the most recent crash
  • Trigger or workloadStartup, sleep/wake, game, update, idle, or unknown
  • Recurrence patternOnce, count, frequency, and whether the Stop Code repeats
  • Minidump statusExists/missing and the time shown; do not upload it here

The browser-local Evidence Pack combines the selected context, safe action, actual observation, sources, review date, missing evidence, and stop boundary. It can be copied or printed without creating an account or uploading a log.

After you perform the safe check

Read the evidence you collected

Paste a bounded msinfo32 or DxDiag text report and extract the Windows build, system model, firmware mode, memory, DirectX, display-driver, and explicitly reported problem-device facts without uploading the report.

Windows System Information Snapshot ReaderOne bounded excerpt · no upload · no root-cause ranking

Review trail

Official and first-party sources

Same task chain

MEMORY_MANAGEMENTSevere memory-management errorIRQL_NOT_LESS_OR_EQUALInvalid kernel memory access at a raised IRQLDRIVER_POWER_STATE_FAILUREDriver did not complete a power-state transitionDPC_WATCHDOG_VIOLATIONA high-priority kernel task exceeded its time limit

Local-first utility

Privacy

The diagnostic parser, evidence readers, verification loop, and Evidence Pack run in your browser. TechClassy does not intentionally store the raw text you paste, Event Viewer or update-log excerpts, full command output, usernames, local file paths, dump files, device serial numbers, observations, parsed summaries, or generated Evidence Packs.

No advertising, analytics, session replay, account system, upload surface, or third-party diagnostic script is loaded in this release. Standard hosting security logs may contain request metadata such as time, requested path, and network information; diagnostic and evidence text is not sent as a URL parameter or API body by the tool.

Use boundary

TechClassy organizes evidence and reviewed next checks. It is not a substitute for Microsoft, an OEM, an employer's IT team, or a qualified repair professional. Results distinguish confirmed facts from possible causes and do not guarantee a repair.

Back up important data before making system changes. Stop when an action requires credentials, firmware changes, disk work, account recovery, or a command whose prerequisites you cannot verify.

Independent operation

This is a newly researched, independently operated diagnostic product. It does not claim to be the prior TechClassy editorial team or a continuation of prior authorship.

Open the permanent page