What is causing and how to fix BugCheck error 0x0000009f in Windows 11 Pro

Question

OS Name: Windows 11 Pro

Version: 10.0.22621 Build 22621

Manufacturer: Lenovo

Event Viewer Event Info

Source: BugCheck

Event ID: 1001

The computer has rebooted from a bugcheck. The bugcheck was: 0x0000009f (0x0000000000000003, 0xffff8503145c2db0, 0xfffffa82c7677718, 0xffff850314aa09a0). A dump was saved in: C:\WINDOWS\MEMORY.DMP. Report Id: 56e24b79-f77f-446c-bd3b-82cb9117d8a0.

I would upload the MEMORY.DMP but it is 2Gbs in size. Which I find appalling. If there is a way to upload it somewhere else please let me know.

Answer 1

Hello Tuned Loop Labs,

How often does the crash occur? If it happens reasonably frequently, you could try the following: disable starting of the "Microsoft Link-Layer Discovery Protocol" (e.g. sc config mslldp start= demand).

LLDP just sends LLDP messages to managed switches so that the system appears in LLDP neighbours tables, so disabling it for test purposes may be OK.

The reason for suspecting mslldp involvement in the problem is this stack trace:

nt!KiSwapContext+0x76

nt!KiSwapThread+0xb05

nt!KiCommitThreadWait+0x137

nt!KeDelayExecutionThread+0xf9

mslldp!lldpWaitForValueToZero+0x31

mslldp!lldpWaitForTxCompletion+0x69

mslldp!lldpProtPauseBinding+0x3b

mslldp!lldpProtNetPnPEvent+0x2f6

ndis!ndisInvokeNetPnPEvent+0x7e

ndis!ndisDeliverNetPnPEventSynchronously+0xcf

ndis!ndisPnPNotifyBinding+0x18e

ndis!ndisPnPNotifyBindingUnlocked+0x44

ndis!ndisPauseProtocolInner+0x79

ndis!ndisPauseProtocol+0xb1

ndis!Ndis::BindEngine::Iterate+0x162

ndis!Ndis::BindEngine::UpdateBindings+0xe3

ndis!Ndis::BindEngine::DispatchPendingWork+0x4a

ndis!Ndis::BindEngine::ApplyBindChanges+0x54

ndis!ndisPrepForLowPowerCommon+0xa4

ndis!ndisPrepForLowPower+0x24

ndis!ndisSetDevicePower+0x38619

ndis!ndisSetPower+0x9f

ndis!ndisPowerDispatch+0x11e

nt!PopIrpWorker+0x261

nt!PspSystemThreadStartup+0x57

nt!KiStartSystemThread+0x34

A set power IRP has not completed within a reasonable time because the mslldp driver is waiting for something that will now probably never happen.

I used italics in the expression "mslldp involvement in the problem" because the "bug"/"root cause" is probably not mslldp (for example, it might be the Realtek rtump64x64 driver).

There is probably more information to be gleaned from the dump file; if one really wants to get to the bottom of the problem then some controlled testing with Event Tracing for Windows (ETW) would probably help.

Gary

Answer 2

Please run the V2 log collector and post a share link into this thread using one drive, drop box, or google drive.

BSOD - Posting Instructions - Windows 10 Forums (tenforums.com)

BSOD - Posting Instructions | Windows 11 Forum (elevenforum.com)

--please don't forget to upvote and Accept as answer if the reply is helpful--

Answer 3

Here's a link to the MEMORY.DMP

https://1drv.ms/u/s!Avix-KewMJf120Q2pgEgX4CelXkI?e=qaNMrP

Answer 4

The memory dump was corrupt.

Please run the V2 log collector and coordinate a time for downloading.

After the download it can be deleted.

--please don't forget to upvote and Accept as answer if the reply is helpful--

Answer 5

Hi Gary Nebbett,

The memory dump debugging using Windbg displayed:

THIS DUMP FILE IS PARTIALLY CORRUPT.

KdDebuggerDataBlock is not preset or is unreadable.

GetContextState failed , 0x80004002

ReadControl failed - kernel symbols must be loaded first

Unable to get current machine context , HResult 0x80004002

etc.

Debugging other mini and memory dumps has continued to work without problems.

Only this memory dump displayed the partially corrupt message.

Without other supporting log files the OP must rely on your May 8, 2023, 2:43 AM post.