Windbg四大核心命令实战解析：从蓝屏分析到崩溃定位

1. 这不是“命令列表”，而是你第一次用 Windbg 时真正需要的四把钥匙

Windbg 是 Windows 平台上最硬核、也最容易让人在前五分钟就关掉的调试工具。我带过十几批刚从学校出来的实习生，也帮过上百位做驱动开发、蓝屏分析、崩溃排查的工程师朋友搭环境，发现一个惊人的一致性现象：90% 的人卡在“打开 Windbg 后不知道点哪里”，剩下 10% 卡在“输入了 .help 却看不懂返回结果”。这不是他们笨，而是 Windbg 从设计之初就没打算讨好新手——它是个手术刀，不是瑞士军刀。你不会指望用手术刀削苹果，同样也不该指望用 Windbg 的.reload命令去查一个 Python 脚本为啥报错。所以这篇内容不叫“Windbg 入门命令大全”，它叫“Windbg 入门四步法”：用四个真实场景下必须敲、必须懂、必须立刻见效的命令，带你绕过所有文档陷阱，直接进入“我能看懂这个崩溃到底出在哪”的状态。

核心关键词 windbg、命令、调试、Windows、入门，全部落在实操动作上：不是背命令，是理解每个命令在什么时刻、解决什么问题、背后调用了什么系统机制。比如!analyze -v看起来只是输出一堆文字，但它实际触发的是 Windows 内核符号解析引擎 + 堆栈回溯算法 + 异常分类规则库三重联动；而lm（list modules）表面是列个 DLL 名单，实则暴露了当前进程的内存布局完整性——如果某个模块显示为deferred或no symbols，那后面所有分析都可能跑偏。你不需要第一天就搞懂 PDB 符号服务器怎么搭建，但必须知道：当你看到ntdll!NtWaitForSingleObject+0x14这行堆栈时，lm m ntdll是你验证符号是否加载成功的第一个动作。这篇文章就是为你省下那 3 小时无效搜索、2 次重装 SDK、1 次误判蓝屏原因的时间。适合两类人：一类是刚接手客户 dmp 文件、被催着要结论的售后工程师；另一类是写 C++/驱动、遇到诡异内存踩踏却只会加 printf 的开发者。别怕命令长得像乱码，我们一个一个拆，连kb和kpn 20的区别都给你算清楚字节数。

2. 四个命令的底层逻辑与不可替代性解析

2.1!analyze -v：不是“分析命令”，而是 Windbg 的“诊断中枢”

很多教程把!analyze -v当成万能钥匙，一上来就教人敲。但没人告诉你：它根本不是独立命令，而是一个封装了至少 7 个子分析模块的诊断流水线。当你输入!analyze -v并回车，Windbg 实际上在后台依次执行：

1. 异常类型识别：检查ExceptionRecord.ExceptionCode，比对 Windows 官方异常代码表（如0x80000003是断点，0xC0000005是访问违例），并关联到具体触发场景（用户态空指针？内核态页表损坏？）；
2. 堆栈可信度校验：调用StackWalk64API 对当前线程堆栈逐帧扫描，检测是否存在栈帧断裂（frame gap）、返回地址非法（如指向不可执行内存）、寄存器值矛盾（如RSP不在合法栈范围内）；
3. 模块符号匹配：遍历所有已加载模块，对每个函数地址查询 PDB 符号文件，若符号缺失，则启用地址偏移模糊匹配（例如myapp!CrashFunction+0x2a中的+0x2a就是靠此机制定位）；
4. 上下文寄存器快照比对：将崩溃时刻的CONTEXT结构体与前 3 次正常执行时的寄存器快照做差异分析（需提前开启.logopen日志），识别异常寄存器突变（如RAX从有效地址突变为0x0000000000000000）；
5. 堆内存状态扫描：若崩溃涉及堆操作（如HeapFree失败），自动调用!heap -p -a <address>扫描对应堆块头，检查HEAP_ENTRY标志位（如BUSY、FREE、EXTRA）是否被篡改；
6. 驱动签名验证：在内核模式下，强制校验引发崩溃的驱动模块是否通过 WHQL 认证，若签名无效则在报告中高亮*** ERROR: Module load completed but symbols could not be loaded for xxx.sys；
7. 历史案例匹配：连接微软公有符号服务器（需配置.symfix+），将当前崩溃特征哈希（包括模块版本号、堆栈哈希、异常代码组合）与 KB 文章数据库比对，返回最接近的已知解决方案编号（如KB4567890）。

提示：!analyze -v的-v参数绝非“verbose”那么简单。它强制启用第 4 步（寄存器快照比对）和第 7 步（KB 匹配），而默认!analyze会跳过这两项以加速输出。实测对比：分析同一个0xC0000005dmp，在 32G 内存机器上，!analyze平均耗时 1.2 秒，!analyze -v耗时 4.7 秒——多出的 3.5 秒，就是你能否准确定位到第三方驱动兼容性问题的关键。

为什么它不可替代？因为所有其他命令都是“零件”，而!analyze -v是唯一能告诉你“这台发动机为什么炸了”的整机诊断仪。你用kb看到 20 层堆栈，但!analyze -v会告诉你：“第 7 层MyDriver!IoCompleteRequest+0x1c是伪帧，因IRP结构体已被覆盖，真实崩溃点在第 12 层ntoskrnl!KiDispatchException+0x2a8”。

2.2lm（list modules）：内存世界的“户籍管理系统”

lm命令常被误解为“列 DLL 清单”，实际上它是 Windbg 中最底层的内存视图命令，直接读取PEB.Ldr（进程环境块的加载器链表）和KPCR.PcrbData（内核处理器控制区）数据结构。它的输出格式start end module name表示的是虚拟内存地址空间的连续映射段，而非文件路径。例如：

00007ff8`2a1e0000 00007ff8`2a20d000 KERNELBASE (deferred)

这里00007ff82a1e0000是该模块在当前进程地址空间的起始 VA（虚拟地址），KERNELBASE是模块名，(deferred)表示符号未加载。注意：这个地址与磁盘上C:\Windows\System32\KernelBase.dll` 的物理位置毫无关系，它只代表“此刻这个进程把 KernelBase 映射到了这段内存”。

lm的不可替代性在于其三个衍生能力：

• lm m <module>：精确过滤单模块，用于验证符号加载状态。例如lm m ntdll返回00007ff82a7f0000 00007ff82a9a7000 ntdll (pdb symbols) c:\symbols\ntdll.pdb\...\ntdll.pdb，说明符号已正确加载；若显示(deferred)，则后续所有u ntdll!NtCreateFile反汇编都将失败。
• lm v：显示模块详细信息，包括时间戳（Timestamp）、校验和（CheckSum）、映像大小（ImageSize）。这是判断模块是否被热补丁修改的关键——微软每月安全更新会改变Timestamp，若你分析的 dmp 中ntoskrnl时间戳是2023-05-09，但客户声称打的是2023-08补丁，则说明补丁未生效或被回滚。
• lm sm：按符号加载状态分组，快速识别“符号黑洞”。输出中deferred组包含所有未加载符号的模块，exported组是仅含导出表的模块（如api-ms-win-crt-runtime-l1-1-0.dll），pdb symbols组才是可深度分析的模块。一个健康的蓝屏分析环境，pdb symbols组应占总数 70% 以上。

注意：lm不依赖网络，所有数据来自 dmp 文件或实时进程内存。这意味着即使你在无网环境分析离线 dmp，lm依然能准确列出所有加载模块——这是!sym noisy或.sympath配置错误时，你确认“基础环境是否正常”的第一道防线。

2.3kb（kernel backtrace）与kpn 20：堆栈的“双模显微镜”

初学者常混淆kb和k（即k默认等价于kpn 12），以为只是显示层数不同。实则二者底层机制完全不同：

• kb：全称kernel backtrace，但实际适用于用户态和内核态。它调用StackWalk64API，严格遵循 Windows x64 调用约定（caller-cleanup, shadow space），对每个栈帧执行：

  • 读取RBP（基址指针）定位当前帧；
  • 解析RETADDR（返回地址）获取调用来源；
  • 从UNWIND_INFO结构中提取寄存器保存规则（如哪些寄存器被 callee 保存），还原调用前状态；
  • 若遇到nop或int 3指令，则标记为“无法回溯”并终止。

• kpn 20：kp是stack with parameters，n表示number of frames。它不依赖UNWIND_INFO，而是暴力扫描栈内存，寻找符合“地址在已加载模块代码段内”的指针值。例如在栈上找到00007ff82a7f1234，检查该地址是否落在ntdll模块范围00007ff82a7f0000-00007ff82a9a7000` 内，若是则视为有效调用地址。

二者不可替代的场景：

场景	推荐命令	原因
分析蓝屏 dmp（内核态崩溃）	kb	UNWIND_INFO在内核模块中完整保留，kb能精准还原中断处理链（如KiDispatchException → KiBugCheckEx → HalpHaltSystem）
分析用户态崩溃（如堆破坏后栈被覆盖）	kpn 20	UNWIND_INFO可能失效，但栈内存中残留的返回地址仍可被暴力扫描到，kpn 20能捕获到MyApp!OnButtonClick+0x45这类关键帧
驱动开发调试（自定义异常处理）	kb+!irp	kb提供 IRP 请求的完整调用链，配合!irp可定位到具体设备对象和完成例程

实测数据：分析一个典型的0xC0000005用户态崩溃 dmp，kb显示 8 层有效帧，kpn 20显示 17 层（含 9 层疑似帧）。此时应以kb为主干，用kpn 20的额外帧交叉验证——若kpn 20中第 12 层是MyDriver!HookFunction+0x8a，而kb中该位置为空，则高度怀疑MyDriver使用了 inline hook 篡改了栈帧。

2.4dt（display type）：符号世界的“解剖刀”

dt命令常被忽略，但它才是让 Windbg 从“地址查看器”升级为“结构分析平台”的核心。dt不是简单打印结构体，而是动态解析 PDB 符号文件中的类型定义（Type Information），支持嵌套、联合、位域等复杂语法。例如：

dt _EPROCESS 86543210

这行命令实际执行流程：

1. 在 PDB 符号中查找_EPROCESS类型定义（位于ntoskrnl.pdb）；
2. 解析其字段偏移：UniqueProcessId偏移0x2e8字节，ActiveThreads偏移0x300字节；
3. 从内存地址0x86543210开始，按偏移读取对应字段值；
4. 对指针字段（如ActiveThreads）自动解引用，显示目标地址内容；
5. 对枚举字段（如State）自动映射为字符串（State: 2 (Waiting））。

dt的不可替代性体现在三个高阶用法：

• dt -r3 <type> <address>：递归展开 3 层嵌套。例如dt -r3 _ETHREAD 86543210会显示线程对象、其关联的Tcb（线程控制块）、Teb（线程环境块）及Teb中的EnvironmentPointer，形成完整的线程上下文视图。
• dt <module>!<type>：跨模块类型解析。当分析第三方驱动时，若其 PDB 未提供，可用dt mydriver!_MY_DEVICE_CONTEXT 86543210直接解析其私有结构体（需提前用dumpbin /headers获取结构体定义）。
• dt -b <type>：显示位域（bit field）解析。例如dt _KTHREAD -b会将KernelApcDisable字段的 16 位标志位逐一分解为0x0001: KernelApcDisable,0x0002: SpecialApcDisable，避免手动位运算错误。

没有dt，你看到的永远是0x0000000000000001这样的数字；有了dt，你看到的是State: 2 (Waiting), Priority: 13 (HIGH_PRIORITY), BasePriority: 8 (NORMAL_PRIORITY)——这才是调试的本质：把二进制翻译成人话。

3. 四步实操：从零开始分析一个真实蓝屏 dmp

3.1 环境准备：三分钟建立可信赖的分析基线

不要跳过这一步。我见过太多人花 2 小时分析 dmp，最后发现是符号路径错了。以下是经过 200+ 次实战验证的最小可行配置：

1. 安装 Windbg Preview（推荐）或 Win10 SDK 中的 Windbg
   下载地址：Microsoft Store 搜索 “WinDbg Preview”，或从 Windows SDK 下载页 获取。避免使用旧版cdb.exe，因其不支持现代符号服务器协议。

2. 配置符号路径（关键！）
   在 Windbg 中执行：

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

   解释：.symfix+自动添加微软公有符号服务器，C:\Symbols是本地缓存目录；.sympath+追加自定义路径（如你的驱动 PDB）；.reload强制重新加载所有模块符号。执行后观察输出：若出现SYMSRV: C:\Symbols\ntdll.pdb\...\ntdll.pdb not found，说明网络不通，需检查代理设置；若显示*** ERROR: Symbol file could not be found，则路径配置错误。

3. 验证环境健康度
   加载任意 dmp 后，立即执行：

   lm m ntdll !analyze -v

   • 若lm m ntdll显示(pdb symbols)，说明符号加载成功；
   • 若!analyze -v输出中包含MODULE_NAME: ntdll和IMAGE_VERSION: 10.0.22621.2506（当前 Win11 版本），说明符号版本匹配；
   • 若出现*** WARNING: Unable to verify timestamp for ntdll.dll，则时间戳不匹配，需用.symopt+ 0x40忽略时间戳检查（临时方案）。

实操心得：我习惯在C:\Symbols下建MyDrivers子目录，把所有自研驱动 PDB 放进去，并在.sympath中追加srv*C:\Symbols\MyDrivers*。这样lm会优先从本地加载，速度比网络快 10 倍。另外，.symopt+ 0x10（启用符号服务器缓存）和.symopt+ 0x40000（忽略缺失 PDB 报错）是两个必开选项，它们能让分析过程更“宽容”。

3.2 第一步：用!analyze -v锁定崩溃根因（30 秒决策）

打开一个客户提供的MEMORY.DMP，执行!analyze -v。重点看输出前三部分：

• BUGCHECK_CODE：蓝屏代码，如0x0000003b（SYSTEM_SERVICE_EXCEPTION）；
• BUGCHECK_DESCRIPTION：官方描述，“An exception happened while executing a system service routine.”；
• DEFAULT_BUCKET_ID：微软内部分类 ID，如NULL_CLASS_PTR_DEREFERENCE，直指空指针解引用。

接着看PROCESS_NAME和STACK_TEXT。假设输出为：

PROCESS_NAME: MyApp.exe STACK_TEXT: ... 00 nt!KiSystemServiceCopyEnd+0x25 01 ntdll!NtCreateFile+0x14 02 MyApp!OpenConfigFile+0x8a 03 MyApp!main+0x2c

此时决策树启动：

• 若PROCESS_NAME是第三方应用（如MyApp.exe），且STACK_TEXT中MyApp模块在栈顶，则 90% 是应用层 bug，无需深入内核；
• 若PROCESS_NAME为空或svchost.exe，且栈中出现dxgkrnl、nvlddmkm等显卡驱动，则转向驱动兼容性排查；
• 若DEFAULT_BUCKET_ID是AVRF（Application Verifier），则客户已开启应用验证器，需用!avrf命令进一步分析。

注意：!analyze -v最后一行Followup: MachineOwner是微软的甩锅话术，实际应关注FAILURE_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE_myapp!OpenConfigFile—— 这个 ID 是微软 KB 数据库的检索键，复制它到 Bing 搜索，常能直接找到补丁方案。

3.3 第二步：用lm确认符号完整性（10 秒避坑）

在!analyze -v输出后，立即执行lm m MyApp（替换为你的进程名）。典型输出：

00007ff6`1a2b0000 00007ff6`1a3c5000 MyApp (deferred)

(deferred)是红色警报！意味着MyApp.pdb未加载，所有u MyApp!OpenConfigFile反汇编都将失败。此时必须：

1. 确认MyApp.pdb文件存在且与MyApp.exe时间戳一致（用dir MyApp.*查看）；
2. 执行.sympath+ C:\Path\To\MyApp\PDB添加路径；
3. 再次.reload /f MyApp强制重载。

若仍显示(deferred)，用!lmi MyApp查看模块详细信息，检查Symbol Type是否为deferred，ImageSize是否与MyApp.exe文件大小一致。不一致说明 exe 被加壳或修改，需先脱壳。

实操心得：我创建了一个批处理loadpdb.bat，内容为：

@echo off echo .sympath+ %1 > load.txt echo .reload /f %2 >> load.txt windbg -c "$$><load.txt;q" -z %3

运行loadpdb.bat C:\MyApp\PDB MyApp.exe MEMORY.DMP即可一键加载符号。这招帮我节省了每年约 120 小时的重复操作。

3.4 第三步：用kb和kpn 20构建可信堆栈（2 分钟精确定位）

假设lm m MyApp已显示(pdb symbols)，现在执行kb：

# RetAddr : Args to Child : Call Site 00 00007ff6`1a2b1234 : 00000000`00000000 00000000`00000000 00000000`00000000 : MyApp!OpenConfigFile+0x8a 01 00007ff6`1a2b1345 : 00000000`00000000 00000000`00000000 00000000`00000000 : MyApp!main+0x2c ...

kb显示MyApp!OpenConfigFile+0x8a是崩溃点。但这是真的吗？执行kpn 20交叉验证：

00 MyApp!OpenConfigFile+0x8a 01 MyApp!main+0x2c 02 MyApp!__scrt_common_main_seh+0x106 03 kernel32!BaseThreadInitThunk+0x14 04 ntdll!RtlUserThreadStart+0x21

两组结果一致，可信度提升。此时用u MyApp!OpenConfigFile+0x8a L10反汇编崩溃点附近 10 条指令：

MyApp!OpenConfigFile+0x8a: 00007ff6`1a2b1234 488b01 mov rax,qword ptr [rcx] ds:00000000`00000000=????????

mov rax,qword ptr [rcx]——rcx是空指针（0x0000000000000000），解引用导致0xC0000005。问题定位完成：OpenConfigFile函数中，rcx寄存器未初始化即被解引用。

提示：L10表示“Length 10”，即反汇编 10 条指令。若想看源码级对应，确保 PDB 包含源码路径，并执行uf MyApp!OpenConfigFile（uf= unassemble function），它会显示每条汇编对应的 C++ 行号（如MyApp.cpp:45）。

3.5 第四步：用dt解剖崩溃上下文（1 分钟根因溯源）

既然rcx是空指针，它从哪来？用r命令查看寄存器：

rcx=0000000000000000

rcx是OpenConfigFile的第一个参数（Windows x64 调用约定）。执行dt -r2 MyApp!CONFIG_STRUCT 0000000000000000（假设结构体名为CONFIG_STRUCT），但地址为 0，dt会报错。此时需回溯上一帧：kb中第 1 帧是MyApp!main+0x2c，执行dd @rsp L20查看栈内存：

00000000`0012f8a0 00000000`00000000 00000000`00000000 00000000`0012f8b0 00000000`00000000 00000000`00000000 ...

栈上全是 0，说明调用者未传参。再看main函数反汇编：call MyApp!OpenConfigFile前是否有mov rcx, rax？执行uf MyApp!main，找到调用前指令：

MyApp!main+0x28: 488bca mov rcx,rdx MyApp!main+0x2b: e800000000 call MyApp!OpenConfigFile

rdx被传给rcx。rdx是什么？执行r rdx，得到rdx=0000000000000000。继续向上追溯，rdx来自main的参数，即argv[1]。最终结论：客户启动MyApp.exe时未带配置文件路径参数，程序未做空检查直接使用。

实操心得：dt配合r和dd是定位“谁污染了寄存器”的黄金组合。我习惯在崩溃点执行r; dd @rsp L10; dt _RTL_USER_PROCESS_PARAMETERS @rcx（若rcx是进程参数结构体），三步锁定污染源。记住：dt不是万能的，它依赖 PDB 中的类型定义；若没有 PDB，就用db（dump bytes）和du（dump unicode）手动解析内存。

4. 常见问题与独家排查技巧实录

4.1 符号加载失败的七种死法与解法

符号问题占 Windbg 新手问题的 73%。以下是我在客户现场记录的真实案例：

现象	根本原因	解决方案	实操命令
lm m ntdll显示(deferred)，但.sympath正确	微软符号服务器证书过期（常见于企业内网）	下载最新根证书，或改用srv*C:\Symbols*http://msdl.microsoft.com/download/symbols（HTTP 无证书校验）	.symfix+ C:\Symbols; .sympath srv*C:\Symbols*http://msdl.microsoft.com/download/symbols; .reload
!analyze -v报ERROR: Module load completed but symbols could not be loaded for MyApp.exe	MyApp.exe被 UPX 压缩，PDB 时间戳与压缩后文件不匹配	用upx -d MyApp.exe脱壳，重新生成 PDB；或用.symopt+ 0x40忽略时间戳	.symopt+ 0x40; .reload /f MyApp
dt _EPROCESS报Error: type not found	当前 dmp 是用户态崩溃，_EPROCESS是内核结构体，未加载ntoskrnl.pdb	切换到内核模式：.process /r /p 0，再执行dt	.process /r /p 0; dt _EPROCESS 86543210
kb显示00000000帧，堆栈断裂	应用使用了SetThreadStackGuarantee修改栈大小，破坏UNWIND_INFO	改用kpn 50暴力扫描，或用!teb查看线程环境块中的StackBase/StackLimit	!teb; kpn 50
!analyze -v卡住超过 2 分钟	符号服务器 DNS 解析失败（如msdl.microsoft.com被劫持）	在hosts文件中添加13.107.4.50 msdl.microsoft.com（微软 CDN IP）	echo 13.107.4.50 msdl.microsoft.com >> %windir%\System32\drivers\etc\hosts
lm列出模块，但u ntdll!NtCreateFile报Address is zero	ntdll模块被注入 DLL 替换（如杀毒软件 Hook），NtCreateFile地址被重定向	用lm v ntdll查看ImageBase，对比dumpbin /headers ntdll.dll的image base，若不一致则被劫持	lm v ntdll; dumpbin /headers C:\Windows\System32\ntdll.dll | findstr "image base"
dt显示字段值，但du查看同一地址是乱码	字符串字段是 ANSI 编码，du默认 Unicode；或指针未解引用	用da（dump ascii）查看 ANSI 字符串；或dt -y强制解引用指针	da 00007ff61a2b1234; dt -y MyApp!CONFIG_STRUCT 00007ff61a2b1234

独家技巧：创建symbolcheck.wds脚本，内容为：

.echo "=== Symbol Health Check ===" lm m ntdll lm m KERNELBASE !sym noisy .echo "=== Stack Trace Test ===" kb .echo "=== Done ==="

加载 dmp 后执行$><symbolcheck.wds，30 秒内完成环境体检。

4.2 堆栈分析的三大幻觉与破除方法

新手常陷入的思维陷阱：

• 幻觉一：“kb 显示的顶层就是崩溃点”
  破除：kb顶层是ret指令地址，真正的崩溃指令在ret前。执行ub . L5（ub= unwind backward）反汇编崩溃点前 5 条指令，找mov、call、jmp等可能出错的指令。

• 幻觉二：“kpn 显示的地址都在模块内，所以都可信”
  破除：kpn会把栈上任何“像地址”的值都当调用地址。验证方法：对每个地址执行ln <addr>（ln= list nearest symbol），若返回Exact matches:则可信；若返回No symbol found，则是垃圾数据。

• 幻觉三：“dt 显示的结构体字段值就是最终值”
  破除：dt显示的是内存快照，但某些字段是运行时计算的（如LIST_ENTRY.Flink在空链表时指向自身）。需结合!list命令验证链表完整性：!list -t _EPROCESS.ActiveProcessLinks.Flink -x "dt _EPROCESS @#Entry"。

4.3 蓝屏 dmp 分析的五个致命误区

1. 误区：只看!analyze -v的FAILURE_BUCKET_ID，不验证STACK_TEXT
   真实案例：FAILURE_BUCKET_ID: INVALID_POINTER_READ_myapp!OpenConfigFile，但STACK_TEXT显示nvlddmkm（NVIDIA 驱动）在栈中。结论：是显卡驱动 Bug，非应用问题。FAILURE_BUCKET_ID是启发式匹配，STACK_TEXT才是铁证。

2. 误区：用!process 0 0查所有进程，却忽略!thread的线程状态
   !process只显示进程基本信息，!thread才揭示线程为何挂起：Wait: WrMutex表示等待互斥体，Wait: WrLpcReply表示等待 RPC 回复。一个WrMutex状态的线程，其Stack中的ntdll!NtWaitForMultipleObjects就是死锁源头。

3. 误区：认为0xC0000005一定是空指针，不检查Access Violation Address
!analyze -v输出中ACCESS_VIOLATION_ADDRESS: 0000000000000000是空指针，但000000007ffe0000是 KUSER_SHARED_DATA 页面（只读），00000000ffffffff是无效地址。不同地址指向不同根因。

4. 误区：在用户态 dmp 中执行!irp，期待看到 IRP 请求
   !irp只在