一个关于WinDbg 的问题想来讨论下 （已解决）

hushong1989

前景介绍：昨晚半夜突然断网，路由器死活不拨号（桥接模式）想着拿主机连光猫电脑直接拨号看看。

插上网线就开始问题来了，新建拨号刚点击确认就直接蓝屏。
蓝屏截图如下


看着这个，可能之前装了某个分析软件带的驱动导致。但是程序里面已经没类似软件了，就准备上 WinDbg  查下看看具体哪个引起的

结果不查还好，查了就发现日志好像不约而同的都指向了 内存。如下图




这一下给我整懵了，难道真是内存问题？？ 关机-关XMP，恢复默认一样还是蓝屏。
想下思路不对啊，切换另一套系统看看，没蓝屏死机了。还是问题出在网卡驱动那块。

切换回来，删除网卡以及驱动，从新安装驱动后正常。

因为抓的蓝屏日志不是全量的，也没法完全分析。但是这个报内存错误一直还是会有。

所以想来讨论下，这个WinDbg 跑诊断到底我这个内存是不是有不稳定情况（重度游戏无异常，当时调好内存后跑过游戏和内存诊断都无异常）。


今晚准备说拿下这个问题点，换个思路，用全量DMP 试试，设置完后蓝屏重启发现日志文件只有 200K 更小了就有点不对劲。
查看后发现  WIN 系统下面存在一个BUG ，当你之前选择过  200K小日志时候生成 Minidump  文件夹后，改成全量 都会默认保存在这个文件夹，且不会正常生成正确的全量 DMP文件。
删除 Minidump 文件夹后，蓝屏重启后正常生成约为 2G的 文件。

当使用老版本 WinDbg 发现文件无法读取，提示报错。搜索一番后得知软件版本过老导致，更新之后
读取这2G 文件最终查到幕后真凶！


Debugging Details:
------------------

Unable to load image \SystemRoot\system32\DRIVERS\klim6.sys, Win32 error 0n2

KEY_VALUES_STRING: 1

    Key  : Analysis.CPU.mSec
    Value: 1765

    Key  : Analysis.Elapsed.mSec
    Value: 31772

    Key  : Analysis.IO.Other.Mb
    Value: 18

    Key  : Analysis.IO.Read.Mb
    Value: 1

    Key  : Analysis.IO.Write.Mb
    Value: 31

    Key  : Analysis.Init.CPU.mSec
    Value: 1562

    Key  : Analysis.Init.Elapsed.mSec
    Value: 563579

    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 96

    Key  : Analysis.Version.DbgEng
    Value: 10.0.27829.1001

    Key  : Analysis.Version.Description
    Value: 10.2503.24.01 amd64fre

    Key  : Analysis.Version.Ext
    Value: 1.2503.24.1

    Key  : Bugcheck.Code.KiBugCheckData
    Value: 0x7c

    Key  : Bugcheck.Code.LegacyAPI
    Value: 0x7c

    Key  : Bugcheck.Code.TargetModel
    Value: 0x7c

    Key  : Dump.Attributes.AsUlong
    Value: 0x21800

    Key  : Dump.Attributes.DiagDataWrittenToHeader
    Value: 1

    Key  : Dump.Attributes.ErrorCode
    Value: 0x0

    Key  : Dump.Attributes.LastLine
    Value: Dump completed successfully.

    Key  : Dump.Attributes.ProgressPercentage
    Value: 100

    Key  : Failure.Bucket
    Value: 0x7C_21_klim6!unknown_function

    Key  : Failure.Hash
    Value: {568de04b-98a1-7d6a-4ebc-c96d7832ad75}

    Key  : Hypervisor.Enlightenments.ValueHex
    Value: 0x7417df84

    Key  : Hypervisor.Flags.AnyHypervisorPresent
    Value: 1

    Key  : Hypervisor.Flags.ApicEnlightened
    Value: 0

    Key  : Hypervisor.Flags.ApicVirtualizationAvailable
    Value: 1

    Key  : Hypervisor.Flags.AsyncMemoryHint
    Value: 0

    Key  : Hypervisor.Flags.CoreSchedulerRequested
    Value: 0

    Key  : Hypervisor.Flags.CpuManager
    Value: 1

    Key  : Hypervisor.Flags.DeprecateAutoEoi
    Value: 1

    Key  : Hypervisor.Flags.DynamicCpuDisabled
    Value: 1

    Key  : Hypervisor.Flags.Epf
    Value: 0

    Key  : Hypervisor.Flags.ExtendedProcessorMasks
    Value: 1

    Key  : Hypervisor.Flags.HardwareMbecAvailable
    Value: 1

    Key  : Hypervisor.Flags.MaxBankNumber
    Value: 0

    Key  : Hypervisor.Flags.MemoryZeroingControl
    Value: 0

    Key  : Hypervisor.Flags.NoExtendedRangeFlush
    Value: 0

    Key  : Hypervisor.Flags.NoNonArchCoreSharing
    Value: 1

    Key  : Hypervisor.Flags.Phase0InitDone
    Value: 1

    Key  : Hypervisor.Flags.PowerSchedulerQos
    Value: 0

    Key  : Hypervisor.Flags.RootScheduler
    Value: 0

    Key  : Hypervisor.Flags.SynicAvailable
    Value: 1

    Key  : Hypervisor.Flags.UseQpcBias
    Value: 0

    Key  : Hypervisor.Flags.Value
    Value: 55185662

    Key  : Hypervisor.Flags.ValueHex
    Value: 0x34a10fe

    Key  : Hypervisor.Flags.VpAssistPage
    Value: 1

    Key  : Hypervisor.Flags.VsmAvailable
    Value: 1

    Key  : Hypervisor.RootFlags.AccessStats
    Value: 1

    Key  : Hypervisor.RootFlags.CrashdumpEnlightened
    Value: 1

    Key  : Hypervisor.RootFlags.CreateVirtualProcessor
    Value: 1

    Key  : Hypervisor.RootFlags.DisableHyperthreading
    Value: 0

    Key  : Hypervisor.RootFlags.HostTimelineSync
    Value: 1

    Key  : Hypervisor.RootFlags.HypervisorDebuggingEnabled
    Value: 0

    Key  : Hypervisor.RootFlags.IsHyperV
    Value: 1

    Key  : Hypervisor.RootFlags.LivedumpEnlightened
    Value: 1

    Key  : Hypervisor.RootFlags.MapDeviceInterrupt
    Value: 1

    Key  : Hypervisor.RootFlags.MceEnlightened
    Value: 1

    Key  : Hypervisor.RootFlags.Nested
    Value: 0

    Key  : Hypervisor.RootFlags.StartLogicalProcessor
    Value: 1

    Key  : Hypervisor.RootFlags.Value
    Value: 1015

    Key  : Hypervisor.RootFlags.ValueHex
    Value: 0x3f7

    Key  : SecureKernel.HalpHvciEnabled
    Value: 0

    Key  : WER.OS.Branch
    Value: ge_release

    Key  : WER.OS.Version
    Value: 10.0.26100.1


BUGCHECK_CODE:  7c

BUGCHECK_P1: 21

BUGCHECK_P2: ffff9381889689a0

BUGCHECK_P3: ffff9381907d28e8

BUGCHECK_P4: 0

FILE_IN_CAB:  MEMORY.DMP

DUMP_FILE_ATTRIBUTES: 0x21800

FAULTING_THREAD:  ffff9381883cc040

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXPNP: 1 (!blackboxpnp)


BLACKBOXWINLOGON: 1

PROCESS_NAME:  System

STACK_TEXT:  
ffffa48f`1757f298 fffff806`0e087ef8     : 00000000`0000007c 00000000`00000021 ffff9381`889689a0 ffff9381`907d28e8 : nt!KeBugCheckEx
ffffa48f`1757f2a0 fffff806`22b5204f     : ffff9381`907d28e8 ffffa48f`1757f3d9 00000000`00000000 00000000`00000000 : ndis!NdisAllocateCloneOidRequest+0x2c8
ffffa48f`1757f320 fffff806`0e08836a     : 00000000`00000000 ffff9381`80c31da0 ffff9381`889689a0 ffffa48f`1757f3d9 : klim6+0x204f
ffffa48f`1757f350 fffff806`7a89a4d4     : ffff9381`907d28e8 00000000`00000000 00000000`00000000 ffff9381`88968a30 : ndis!ndisFDoOidRequestInternal+0x39a
ffffa48f`1757f440 fffff806`7a89a3ed     : fffff806`0e087fd0 ffff9381`889689a0 ffff9381`80e641a0 00000000`00000000 : nt!KeExpandKernelStackAndCalloutInternal+0xd4
ffffa48f`1757f4b0 fffff806`0e08418e     : ffff9381`80e641a0 00000000`00001001 00000000`00000000 00000000`00000000 : nt!KeExpandKernelStackAndCalloutEx+0x1d
ffffa48f`1757f4f0 fffff806`0e083037     : 00000000`0001010e 00000000`00000028 fffff806`315bb000 ffff9381`907d28e8 : ndis!ndisQueueOidRequest+0x52e
ffffa48f`1757f6a0 fffff806`0e0da07f     : ffff9381`907d28e8 fffff806`0e0d806d 00000000`0001010e fffff806`0e0d9190 : ndis!ndisMOidRequest+0xe7
ffffa48f`1757f770 fffff806`315c0293     : ffff9381`907d2a00 ffff9381`907d28e8 00000000`000000ff fffff806`0e193198 : ndis!NdisOidRequest+0x3f
ffffa48f`1757f7c0 fffff806`315c61fd     : ffff9381`907d28b0 ffff9381`8d0c9e01 00000000`00000003 00000000`00000010 : raspppoe!PrSetPacketFilterForAdapter+0xbf
ffffa48f`1757f7f0 fffff806`315bf8d9     : ffff9381`8fb5c280 ffff9381`91acc050 ffff9381`8d0c9e10 ffff9381`99377001 : raspppoe!ChangePacketFiltersForAdapters+0x1d9
ffffa48f`1757f830 fffff806`315c0488     : ffff9381`8fb5b320 ffff9381`99377080 ffff9381`99377080 ffffa48f`1757f8d0 : raspppoe!ExecBindingWorkItem+0x109
ffffa48f`1757f860 fffff806`0e0d73e1     : ffff9381`972c6c50 00000000`00000000 ffff9381`972c6c50 ffff8738`016e6202 : raspppoe!WorkItemExec+0x28
ffffa48f`1757f890 fffff806`7a8bf8e2     : ffff9381`0000000a ffff9381`972c6c50 ffff9381`972c6c50 00000000`00000000 : ndis!ndisDispatchIoWorkItem+0x11
ffffa48f`1757f8c0 fffff806`7a930553     : ffff9381`883cc040 ffff9381`719bdae0 ffffd180`0c2d1100 ffff9381`883cc040 : nt!IopProcessWorkItem+0x502
ffffa48f`1757f950 fffff806`7aaa2d1a     : ffff9381`883cc040 ffff9381`883cc040 fffff806`7a9303b0 ffff9381`719bdae0 : nt!ExpWorkerThread+0x1a3
ffffa48f`1757fb30 fffff806`7aca61b4     : ffffd180`0c2d1180 ffff9381`883cc040 fffff806`7aaa2cc0 00009888`0000000a : nt!PspSystemThreadStartup+0x5a
ffffa48f`1757fb80 00000000`00000000     : ffffa48f`17580000 ffffa48f`17579000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x34


SYMBOL_NAME:  klim6+204f

MODULE_NAME: klim6

IMAGE_NAME:  klim6.sys

IMAGE_VERSION:  30.1831.0.762

STACK_COMMAND: .process /r /p 0xffff9381716d8040; .thread 0xffff9381883cc040 ; kb

BUCKET_ID_FUNC_OFFSET:  204f

FAILURE_BUCKET_ID:  0x7C_21_klim6!unknown_function

OS_VERSION:  10.0.26100.1

BUILDLAB_STR:  ge_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

FAILURE_ID_HASH:  {568de04b-98a1-7d6a-4ebc-c96d7832ad75}

Followup:     MachineOwner
---------
既然是 卡巴斯基，卸载卡巴斯基后一切恢复正常。至此问题解除。。。。
klim6.sys  这个驱动就是卡巴斯基的驱动，跟网卡好像八字不合。

ttt5t5t

这种蓝屏一般都是某个程序指针乱来搞出来的
不一定是内存不稳定 有可能单纯这个驱动乱搞

hushong1989

ttt5t5t 发表于 2025-5-28 15:24
这种蓝屏一般都是某个程序指针乱来搞出来的
不一定是内存不稳定 有可能单纯这个驱动乱搞 ...

嗯，确实，但是查不到是哪个照成的，后面把蓝屏文件改成全量看会不会抓到问题。

有时候有些问题莫名其妙。

还有个神奇的问题就是同样  WIN 11  24H2 装在我这台电脑上，点击开始关机键会一会才会弹出关机重启按钮，同样的系统装在另一台上就不会。

ttt5t5t

hushong1989 发表于 2025-5-28 15:33
嗯，确实，但是查不到是哪个照成的，后面把蓝屏文件改成全量看会不会抓到问题。

有时候有些问题莫名其妙 ...

有时候确实如此 机房同配置机器有几台就是反应慢

anymore911

1. 你的这几个BugCheck全是7C，按经验DRAM损坏导致的BugCheckCode一般不会是固定一个。当然排除的话也很简单，BIOS恢复默认关XMP跑下内存测试就知道了;

2. WinDbg的 !analyze -v 自动分析有时候很坑的，结果误导人…… System、ntoskrnl 这些是常见背锅侠，有时候甚至给你一个只跑在User Mode的Process Name，然后不懂的人对着这个Process疯狂卸载、重装、更新，结果下一次蓝屏自动分析又给你指向另一个Process Name；

3. 0x0000007C：This bug check indicates that the operating system detected an error in a networking driver.，巨硬参考手册很明了了，网络驱动程序出现错误。看你几次BugCheck给到的Arg1都是0x21，那么按照手册Arg2就是处于非法状态的驱动程序的句柄，巨硬建议你跑下 !ndiskd.minidriver或者 !ndiskd.filterdriver 来获取这个句柄的更多信息，具体用法：

# !ndiskd.minidriver Arg2的值
!ndiskd.minidriver ffff93847d8119a0

# !ndiskd.filterdriver Arg2的值
!ndiskd.filterdriver ffff93847d8119a0

YsHaNg

我一般参照pnp blackbox设备总线挂载位置

hushong1989

anymore911 发表于 2025-5-28 17:22
1. 你的这几个BugCheck全是7C，按经验DRAM损坏导致的BugCheckCode一般不会是固定一个。当然排除的话也很简 ...

今天晚上改成全量 然后用老  WinDbg  跑提示文件错误。
然后查了一圈发现，WinDbg版本过老！！！！！需要更新
这就去微软商店更新后从新跑诊断，终于揪出问题所在了。。。。

SYMBOL_NAME:  klim6+204f

MODULE_NAME: klim6

IMAGE_NAME:  klim6.sys

IMAGE_VERSION:  30.1831.0.762

STACK_COMMAND: .process /r /p 0xffff9381716d8040; .thread 0xffff9381883cc040 ; kb

BUCKET_ID_FUNC_OFFSET:  204f

FAILURE_BUCKET_ID:  0x7C_21_klim6!unknown_function

OS_VERSION:  10.0.26100.1

BUILDLAB_STR:  ge_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

FAILURE_ID_HASH:  {568de04b-98a1-7d6a-4ebc-c96d7832ad75}

Followup:     MachineOwner


卡巴斯基

hushong1989

YsHaNg 发表于 2025-5-28 23:52
我一般参照pnp blackbox设备总线挂载位置

诊断工具过老，才会误报。。。。
今晚刚测试出来问题点了。