2026年7月

一、Dump文件

当Windows发生严重错误时：系统会自动保存崩溃现场

这些文件称为：

Dump File

Dump文件里面记录：

  • 崩溃线程
  • 调用堆栈
  • 驱动状态
  • CPU寄存器
  • 内存信息

二、收集崩溃转储文件

设置-系统-高级系统设置-启动和故障恢复-设置-写入调试信息-核心内存转存储

Image

举个例子

  • 小内存转储（256KB）—— 最常用

  • 核心内存转储

    • 内容：包含分配给内核和硬件抽象层 (HAL) 的所有内存，以及分配给内核模式驱动程序的内存
    • 优点：包含了分析大多数驱动程序和系统内核问题所需的全部信息，但不包含未分配的内存或分配给用户模式应用程序的内存
    • 文件大小：通常取决于你系统安装的内存容量，但远小于“完全内存转储”

  • 完全内存转储

    • 内容：保存崩溃瞬间物理内存中的所有内容。
    • 优点：信息最全，可以分析任何复杂的死锁或隐藏很深的代码逻辑问题。
    • 缺点：文件体积巨大（和你电脑的物理内存一样大，比如 32GB 内存就会生成 32GB 的文件）。

  • 自动内存转储

    • 特点：这是 Windows 8 之后引入的默认设置。
    • 区别：它在内容上与“核心内存转储”一致，但它允许系统更灵活地管理分页文件的大小，以确保能成功写入 dump 文件

  • 活动内存转储

    • 特点：主要用于虚拟机或服务器环境。
    • 内容：类似于完全内存转储，但会自动剔除那些对排查问题没有帮助的内存页（如虚拟机管理程序占用的内存），从而减小文件体积

三、安装WinDbg

3.1 安装配置

  1. 直接下载安装：https://learn.microsoft.com/zh-cn/windows/apps/windows-sdk/downloads
  2. 在MicrosoftStore中安装：https://apps.microsoft.com/detail/WinDbg%20Preview/9PGJGD53TN86?launch=true\&mode=mini
  3. 使用winget安装：在安装了“Windows 包管理器”中Powershell中输入命令安装
winget install Microsoft.WinDbg

符号表是WinDbg关键的“数据库”，如果没有它，无法分析出更多问题原因。

Image

如果以上配置后，仍出现问题则，File-Symbol File Path：

srv*C:\symbols*http://msdl.microsoft.com/download/symbols

设置完毕后将Dump文件拉到WinDbg中即可开始分析

如拉入Dump文件到WinDbg出现

Symbol Loading Error Summary
Module name Error
ntkrnlmp The system cannot find the file specified

ntkrnlmp 是 Windows 内核的核心模块。由于找不到它的符号文件（PDB），Windbg 就无法准确解析内核的函数和内存地址，这会导致接下来的 !analyze -v 分析结果不完整甚至出现误判

解决方式：

.sympath srv*C:\Symbols*https://msdl.microsoft.com/download/symbols
.reload /f

直到Symblos出现内容

四、Dump分析

收集Dump---\!analyze -v---查看堆栈K---确认异常模块lmvm---确认驱动版本---硬件交叉验证---最终定位根因

4.1 关键指标速查表

以下为 WinDbg 执行 \!analyze -v 后输出的核心指标，按类别整理，便于快速定位崩溃根因。

指标名称WinDbg 字段 / 命令含义说明分析价值
System Uptime
（开机时间）		System Uptime系统从上次启动到崩溃时的运行时长运行时间极短即崩溃 → 多为驱动加载/启动项问题；运行数天后崩溃 → 可能是内存泄漏、资源耗尽或硬件劣化
BugCheck Code
（错误检查代码）		BugCheck / e.g. 0x000000D1蓝屏停止代码，标识崩溃类型直接决定分析方向：0xA/0xD1 多为驱动内存访问违规；0x50 为页面故障；0x124 为硬件机器检查异常
BugCheck Description
（错误检查描述）		Bugcheck description停止代码对应的文字描述快速理解崩溃性质，辅助确认代码含义
MODULE\_NAME
（触发崩溃的模块）		MODULE\_NAMEWinDbg 推断的导致崩溃的驱动或模块名最关键的定位线索之一；结合 lmvm 可查模块版本与厂商信息
IMAGE\_NAME
（崩溃镜像名）		IMAGE\_NAME实际触发异常的可执行镜像文件名与 MODULE\_NAME 交叉验证；有时 IMAGE\_NAME 更精确（如具体.sys文件）
PROCESS\_NAME
（崩溃进程名）		PROCESS\_NAME崩溃发生时当前活动的进程若为 System 进程 → 内核/驱动问题；若为特定应用 → 可能是应用与驱动交互触发
FAILURE\_BUCKET\_ID
（故障桶ID）		FAILURE\_BUCKET\_ID微软对崩溃类型的分类哈希标识相同 BUCKET\_ID 意味着相同故障模式；可用于搜索已知问题和解决方案
DEFAULT\_BUCKET\_ID
（默认桶ID）		DEFAULT\_BUCKET\_ID默认故障分类，通常为 WIN8\_DRIVER\_FAULT 等判断崩溃是否被精确分类；若为 VISTA\_DRIVER\_FAULT 说明符号可能不完整
STACK\_TEXT
（调用堆栈）		STACK\_TEXT / k / kv崩溃时的线程调用栈序列核心分析依据；从栈底到栈顶追溯调用链，定位最后执行的驱动函数
IRP
（I/O请求包）		IRP / \!irp关联的 I/O 请求包地址（部分崩溃类型才有）0xD1/0x0A 等崩溃中，IRP 可揭示是哪个设备的 I/O 操作触发了异常
EXCEPTION\_CODE
（异常代码）		ExceptionCode / .exr具体异常码，如 0xC0000005（访问违规）区分异常类型：访问违规、断点、非法指令等，辅助判断是读/写/执行违规
OS\_VERSION
（系统版本）		OS\_VERSIONWindows 操作系统版本号确认系统版本，判断是否存在已知版本缺陷，驱动是否匹配该版本
BUILD\_VERSION\_STR
（构建版本字符串）		BuildVersionString完整的系统构建版本，如 10.0.19041.xxx精确定位到具体补丁级别，可查询该版本是否有已知蓝屏问题
PRODUCT\_TYPE
（产品类型）		ProductType1=Workstation，3=Server区分桌面端与服务器环境，驱动兼容性分析维度不同
PLATFORM\_TYPE
（平台类型）		PlatformType处理器平台，如 x64 (AMD64)确认架构，避免加载错误符号；32位与64位驱动不可混用
OSBUILDTYPE
（构建类型）		OSBuildTypeMultiprocessor Free / CheckedFree 为正式发布版，Checked 为调试版；Checked 版会有更多断言检查
OSBUILDLAB
（构建实验室）		OSBuildLab系统构建的实验室分支标识辅助判断系统来源分支，排查是否为预览版或特殊渠道版本
SUITE\_MASK
（套件掩码）		SuiteMask已安装的 Windows 套件位掩码识别 Terminal Server、DataCenter 等特殊组件，部分驱动在特定套件下有问题
CPU / 处理器信息ProcessorVendor / MHz / \!cpuinfoCPU 厂商、频率、核心数0x124 硬件异常时重点关注；特定 CPU 微码缺陷可能导致规律性崩溃
MEMORY\_USAGE
（内存使用）		MEMORY\_USAGE / \!vm崩溃时系统内存使用概况判断是否内存耗尽；结合分页池/非分页池排查内存泄漏型崩溃
PAGED\_POOL
（分页池）		PagedPool / \!poolused可分页内核内存池使用量分页池耗尽常导致 0x3B / 0x50 等崩溃；\!poolused 可定位泄漏的驱动标签
NONPAGED\_POOL
（非分页池）		NonPagedPool / \!poolused不可分页内核内存池使用量非分页池泄漏更危险，可能导致 0x4E (PFN\_LIST\_CORRUPT) 等严重崩溃
COMMITTED\_MEMORY
（已提交内存）		CommittedMemory系统已提交的虚拟内存总量接近提交上限时系统不稳定，可能触发资源相关崩溃
THREAD\_COUNT
（线程数）		\!process 0 0 / \!stacks系统当前线程总数线程数异常偏高可能是句柄/线程泄漏，结合进程维度排查
HANDLE\_COUNT
（句柄数）		\!handle / \!process进程或系统句柄数量句柄泄漏会逐步耗尽系统资源，长时间运行后崩溃的重要线索
FILE\_VERSION
（文件版本）		lmvm \<module\>崩溃模块的文件版本号核心排查步骤：确认驱动版本是否过旧、是否为已知有缺陷的版本
PRODUCT\_VERSION
（产品版本）		lmvm \<module\>模块所属产品的版本号关联到具体软件/驱动包版本，便于查找官方更新或已知问题列表
COMPANY\_NAME
（公司名称）		lmvm \<module\>模块的厂商名称识别第三方驱动 vs 微软官方驱动；第三方驱动是蓝屏的首要嫌疑对象
FILE\_DESCRIPTION
（文件描述）		lmvm \<module\>模块的功能描述文字快速理解该驱动负责什么硬件/功能，辅助判断与崩溃场景的关联
TIME\_STAMP
（时间戳）		lmvm / lmv模块文件的编译时间戳判断驱动新旧程度；极老的驱动（如5年以上）在新系统上兼容性风险高
CHECKSUM
（校验和）		lmvm / \!chkimg模块镜像的校验和\!chkimg 对比校验和可检测驱动文件是否被篡改或损坏（Rootkit/内存损坏）
FAILURE\_ID\_HASH
（故障ID哈希）		FailureIdHash崩溃事件的唯一哈希标识用于在微软在线崩溃分析（OCA）中匹配相同故障的统计数据

五、判断软件、硬件

5.1 软件问题特点

蓝屏总能复现，Dump总指向同一个驱动

usbxhci.sysnvlddmkm.sysrtwlane.sys

5.2 硬件问题特点

蓝屏代码不固定，Dump每次不同

0x50
0xA
0x124

优先检查

  • 内存
  • SSD
  • CPU
  • 电源

https://learn.microsoft.com/zh-cn/windows-hardware/drivers/debugger/bug-check-code-reference2

（注：部分内容可能由 AI 生成）

在 Kubernetes 集群中，为服务配置 HTTPS 是生产环境的标配。本文将介绍如何使用 Cert-Manager 结合 Traefik Ingress，通过 Let's Encrypt 自动申请并续签免费的 SSL/TLS 证书。

部署 Cert-Manager

1、首先，我们需要在集群中安装 Cert-Manager。这里我们创建一个独立的命名空间来管理它。

kubectl create namespace cert-manager

2、部署 cert-manager

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.9.1/cert-manager.yaml

3、ClusterIssuer 是 Cert-Manager 的核心资源，用于定义证书颁发机构

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    email: gua3j7@126.com   #*用于接收证书过期通知等*
    privateKeySecretRef:    #指定存储 ACME 客户端私钥的 Kubernetes Secret 的名称
      name: letsencrypt-prod
    server: https://acme-v02.api.letsencrypt.org/directory
    solvers:               #定义用于验证证书颁发请求的解析器。
      - http01:
          ingress:
            class: traefik

4、创建ingress 自动申请证书

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: work-ingress
  namespace: default
  annotations:
    kubernetes.io/ingress.class: traefik
    cert-manager.io/cluster-issuer: letsencrypt-prod  # letsencrypt-prod为ClusterIssuer名称
spec:
  ingressClassName: traefik # 指定 Ingress Class 为 traefik
  tls:
    - secretName: miiv-tls *# 证书将被存储在此 Kubernetes Secret 中*
      hosts:
        - miiv.top # *指定需要证书的域名*
  rules:
    - host: miiv.top  # 转发规则名称
      http:
        paths:
          - path: /
            pathType: ImplementationSpecific
            backend:
              service:
                name: miiv-lnp # 服务名
                port:
                  number: 80 # 服务的端口号 service port，非pod port

如访问Miiv.top出现not found，查看traefik日志发现

intSlice: failed to list *v1.EndpointSlice: endpointslices.discovery.k8s.io is forbidden: User \"system:serviceaccount:kube-system:traefik\" cannot list resource \"endpointslices\" in API group \"discovery.k8s.io\" at the cluster scope" logger="UnhandledError"
W0811 14:29:30.798885       1 reflector.go:561] k8s.io/client-go@v0.31.1/tools/cache/reflector.go:243: failed to list *v1.EndpointSlice: endpointslices.discovery.k8s.io is forbidden: User "system:serviceaccount:kube-system:traefik" cannot list resource "endpointslices" in API group "discovery.k8s.io" at the cluster scope


**原因：缺少对endpointslices、nodes访问规则**
kubectl edit clusterrole traefik-kube-system
ruls末尾增加
- apiGroups:
  - discovery.k8s.io
  resources:
  - endpointslices
  - nodes
  verbs:
  - list
  - watch