WinDbg调试时KERNEL32/KERNELBASE模块未加载的原因排查

核心原因 #

KERNEL32和KERNELBASE属于用户态模块，内核调试器默认仅加载内核态模块符号。只有当目标系统存在运行中的用户态进程，且调试器切换到该进程上下文时，这些模块才会被加载显示。

排查与解决步骤 #

• 切换到用户态进程上下文：
  内核调试器默认处于内核空间（nt模块上下文），lm只会列出内核态模块。需手动切换到目标进程：

  1. 执行!process 0 0列出所有进程，找到驱动存根对应的进程，记下其EPROCESS地址（如fffff807xxxxxxxxx格式的十六进制值）；
  2. 执行.process /i <EPROCESS地址>切换上下文，再执行g让系统运行，待调试器再次中断后，执行.reload，此时lm即可显示该进程加载的用户态模块。

• 检查符号路径配置：
  确保符号路径同时包含内核态和用户态符号，示例格式：

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

  用.sympath查看当前路径，若缺失用户态符号源，补充后执行.reload /f强制重新加载。

• 调整调试中断时机：
  若中断时机过早（如系统刚启动、目标进程未完成模块加载），即使切换上下文也看不到模块。可以：

  • 在驱动的用户态入口点设置断点，待进程初始化完成后再操作；
  • 让系统运行到用户态进程启动完成的阶段（如登录系统后），再中断调试器执行.reload。

• 复盘之前正常显示的场景：
  之前能看到模块，大概率是当时调试器处于某个用户态进程上下文，或符号路径完整且目标进程已完成加载。可回忆是否切换过进程上下文、是否在系统登录后才中断调试。

直接设置断点的替代方案 #

若暂时无法加载模块符号，可通过以下方式设置KERNEL32!CreateFileA断点：

1. 执行!peb查看当前进程PEB信息，找到KERNEL32的内存基地址；
2. 用x KERNEL32!CreateFileA查找函数地址（若符号已部分加载）；
3. 直接执行bp <函数地址>或bp KERNEL32!CreateFileA（调试器能解析符号时）设置断点。

内容的提问来源于stack exchange，提问作者Tracy McDowell