DBGHELP.DLL中有一些文档化的WinDBG扩展命令，例如!sym and !dh，分别设置符号加载诊断和转储模块PE头。看到itoldyouso是小写的，我不禁怀疑它是否是一个未经文档化的WinDBG扩展命令。启动WinDBG并输入!itoldyouso，产生了以下结果：

0:000> !itoldyouso!IToldYouSo <module>[symbol]!IToldYouSo tests the validity of a module against a symbol file.

The module can be specified by either its name or base address.

If a symbolfile is not specified, thenthe loaded symbol is tested.

Otherwise,if a pdb or dbg symbol filepath is specified, it is tested

against the loaded module.

我经常在windbg中调试.netframeworkv2.0/v 4.0代码。在v 2.0中，主clr dll称为“mscorwks.dll”，在v 4.0中称为“clr.dll”。很多人都知道，要在v 2.0中加载sos，我们必须输入“.loadby sos mscorwks”，在v 4.0中输入“.loadby sos clr”。这对我来说是一种痛苦。提出了一个基于clr版本自动加载sos的脚本

!for_each_module .if(($sicmp( “@#ModuleName” , “mscorwks”) = 0) ) {.loadby sos mscorwks} .elsif ($sicmp( “@#ModuleName” , “clr”) = 0) {.loadby sos clr}

简介

ProcDump是一个命令行实用程序，其主要目的是监视应用程序的CPU峰值，并在峰值期间生成崩溃转储，管理员或开发人员可以使用该转储来确定峰值的原因。ProcDump还包括挂起窗口监视（使用与Windows和任务管理器使用的相同的窗口挂起定义）、未处理的异常监视，并且可以基于系统性能计数器的值生成转储。它还可以作为一个通用的进程转储实用程序，可以嵌入到其他脚本中。

使用ProcDump

procdump [-a] [[-c|-cl CPU usage]
[-u] [-s seconds]] [-n exceeds] [-e [1 [-b]] [-f <filter,...>]
[-g] [-h] [-l] [-m|-ml commit usage] [-ma | -mp] [-o] [-p|-pl
counter threshold] [-r] [-t] [-d <callback DLL>] [-64] <[-w] <process name or service name or PID>
[dump file] | -i <dump file> | -u | -x <dump file> <image file> [arguments] >] [-? [ -e]

默认情况下，在Wireshark中记录跟踪时，在其中找不到进程id。有时这些信息对于调查你所面临的问题是必要的。我这周碰到了这样的一个问题。我需要在虚拟机（本地地址10.0.2.5）上找到一个进程，该虚拟机仍在使用TLSv1连接到我们的负载平衡器。起初，我只在Wireshark中记录了跟踪并对其进行了过滤（ssl.record.version==”TLS 1.0“）：

显然，他们的要求是有的。由于整个通信量（握手除外）是加密的，因此无法猜测是谁发送了这些数据包。幸运的是，TLS在底层使用TCP，每个TCP包都有一个端口号，该端口号在给定时间唯一地标识一个进程。因此，如果我们在记录Wireshark跟踪时收集这些信息，我们将能够完成分析。我首选的方法是使用过程监视器。由于进程监视器跟踪可能会快速增长，因此最好删除除TCP/IP类别之外的所有事件(Filter -> Drop Filtered Events):

运行procmon后，我们可以在Wireshark中重新记录网络流量。完成后，我们需要将Wireshark中的默认时间格式（View->time Display format->time of Day或只需按Ctrl+Alt+2）更改为Process Monitor中使用的格式。现在，是时候找出其中一个可疑事件并节省时间和源端口：

利用这些信息，我们可以在procmon跟踪中找到相应的事件，并通过检查其属性，了解创建给定网络数据包的过程。事件的时间略有不同（Wireshark使用WinPcap/npcap驱动程序，而Process Monitor依赖ETW TCP/IP事件），但通常情况下，这不应该是个问题。如果您查看上面的procmon屏幕截图，您将看到我正在查找的进程是ImageVerifier.exe。
如果需要远程执行此类诊断，并且只能访问远程计算机上的命令行，则可以考虑使用TShark和wtrace（带参数：–filter TCPIP–nosummary）代替Wireshark和Process Monitor。

今天我很高兴向您介绍我的第一个WinDbg扩展lld，目前它只包含一个命令：！inject DLL，它允许您将DLL注入正在调试的进程。sdbgext扩展中有一个类似的命令，但它只适用于32位进程。用法非常简单——只要记住以正确的位加载扩展（32位进程的32位版本）。示例会话可能如下所示：

0:000>.load lld0:000> !injectdll c:\temp\Test.exe

ModLoad:00000001`3f820000 00000001`3f924000   c:\temp\Test.exe

ModLoad: 000007fe`fd960000 000007fe`fd98e000   C:\Windows\system32\IMM32.DLL

ModLoad: 000007fe`ff410000 000007fe`ff519000   C:\Windows\system32\MSCTF.dll

(bac.5a0): Break instruction exception- code 80000003(first chance)

ntdll!LdrpDoDebuggerBreak+0x30:00000000`778c7800 cc              int     3