简介

这个!uniqstack扩展扩展显示的所有线程的堆栈的所有当前进程，不包括显示为具有重复项的堆栈中。

使用形式

!uniqstack [ -b | -v | -p ] [ -n ]

参数

• -b
  将导致显示以包括前三个参数传递给每个函数。

• -v
  将导致显示以包括帧指针省略 (FPO) 信息。 在基于 x86 的处理器中，还会显示的调用约定信息。

• -p
  将导致显示堆栈跟踪中包含每个函数的完整参数。 此列表将包括每个参数的数据类型、 名称和值。 这要求的完整符号信息。

• -n
  导致要显示的帧号码。

环境支持

说明

此扩展是类似于 k、 kb、 kc、 kd、 kp、 kP，kv （显示堆栈回溯） 命令，只不过它不会显示重复的堆栈。

这个！uniqstack命令枚举了所有的线程调用堆栈并消除了重复，这样您就可以一眼就知道这几百个线程在做什么。

0:021> !uniqstack
Processing 22 threads, please wait

.  0  Id: 464.ca8 Suspend: 1 Teb: 7f9dd000 Unfrozen
      Start: SillyThreadPool!ILT+120(_wmainCRTStartup) (00ed107d)
      Priority: 0  Priority class: 32  Affinity: ff
ChildEBP RetAddr 
00a6f510 76e0cfb2 ntdll!NtReadFile+0xc
00a6f578 5285d9de KERNELBASE!ReadFile+0x10e
00a6f62c 5285d19c MSVCR110D!_read_nolock+0x7be
00a6f684 527a4246 MSVCR110D!_read+0x24c
00a6f6b4 527a26b3 MSVCR110D!_filbuf+0x126
00a6f714 527a2708 MSVCR110D!getc+0x223
00a6f720 527a2718 MSVCR110D!_fgetchar+0x18
00a6f728 00ed14ca MSVCR110D!getchar+0x8
00a6f808 00ed1a49 SillyThreadPool!wmain+0x7a
00a6f858 00ed1c3d SillyThreadPool!__tmainCRTStartup+0x199
00a6f860 7755850d SillyThreadPool!wmainCRTStartup+0xd
00a6f86c 77d1bf39 KERNEL32!BaseThreadInitThunk+0xe
00a6f8b0 77d1bf0c ntdll!__RtlUserThreadStart+0x72
00a6f8c8 00000000 ntdll!_RtlUserThreadStart+0x1b

.  1  Id: 464.13d4 Suspend: 1 Teb: 7f9da000 Unfrozen
      Start: SillyThreadPool!ILT+265(?MyThreadPoolWorkerYGKPAXZ) (00ed110e)
      Priority: 0  Priority class: 32  Affinity: ff
ChildEBP RetAddr 
00d3f7b8 76e01129 ntdll!NtWaitForSingleObject+0xc
00d3f824 76e010b4 KERNELBASE!WaitForSingleObjectEx+0x8f
00d3f838 00ed141e KERNELBASE!WaitForSingleObject+0x12
00d3f914 7755850d SillyThreadPool!MyThreadPoolWorker+0x2e
00d3f920 77d1bf39 KERNEL32!BaseThreadInitThunk+0xe
00d3f964 77d1bf0c ntdll!__RtlUserThreadStart+0x72
00d3f97c 00000000 ntdll!_RtlUserThreadStart+0x1b

. 21  Id: 464.1574 Suspend: 1 Teb: 7f879000 Unfrozen
      Start: ntdll!DbgUiRemoteBreakin (77d5dbeb)
      Priority: 0  Priority class: 32  Affinity: ff
ChildEBP RetAddr 
0279faa4 77d5dc24 ntdll!DbgBreakPoint
0279fad4 7755850d ntdll!DbgUiRemoteBreakin+0x39
0279fae0 77d1bf39 KERNEL32!BaseThreadInitThunk+0xe
0279fb24 77d1bf0c ntdll!__RtlUserThreadStart+0x72
0279fb3c 00000000 ntdll!_RtlUserThreadStart+0x1b

Total threads: 22
Duplicate callstacks: 19 (windbg thread #s follow):
2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20

为了回答这个问题，我们需要讨论几个概念。
在32位系统上工作时，可以寻址4GB内存，其中2GB通常保留给操作系统，每个用户模式进程（如w3）允许有2GB内存wp.exe文件(asp.net)例如。这个内存称为虚拟内存，2GB是2GB，与系统中添加的RAM数量无关。RAM的数量只是决定了你需要做多少分页和交换，也就是说内存访问的速度。
当一个进程分配内存时，它首先保留虚拟内存，然后从这个块中提交内存（这是实际使用的内存）。提交的内存称为私有字节。虚拟地址空间用于处理过程中的许多不同项目，例如：

• Dll’s
• Native heaps (non .net heaps)
• Threads (each thread reserves 1 MB for the stack)
• .net heaps (for managed variables)
• .net loader heap (for assemblies and related structures)
• Virtual allocations made by com components

虚拟内存分配不一定（或很少）在内存中很好地排列。例如，dll具有首选的加载地址，因此它们之间留有间隙，而已取消分配的虚拟分配也将留下间隙。这意味着，即使您可以寻址2GB的虚拟内存，但您可能无法全部使用，因为当使用了足够的内存时，内存将看起来有点像瑞士奶酪，并且您的插头可能没有一个足够大的孔来容纳。
这是当您得到一个OutOfMemory异常时发生的情况。
在.net框架中，垃圾收集器（我们的内存管理器）以堆的形式保留虚拟内存。一旦创建了这些堆，并且我们创建了一个.net对象的新实例，这个对象就被存储在这些堆段中，并提交了内存。
在.NETFramework中，常规的.net堆是在64MB段中创建的。（如果您有8个以上的处理器或手动更改了设置，则会发生变化，但我暂时忽略这一点，并讨论常见情况）
这些64MB的段需要在一个大的块中分配，你不能在这里分配32 MB，在那里分配32 MB，所以当你填满了其中一个64 MB的段并且需要创建一个新的段时，你需要在2GB内存空间中找到一个64 MB或更多的空白。如果不存在这样的间隙，则会出现内存不足异常。
这些OutOfMemory异常通常不是致命的，但仍然很糟糕，因为它们使进程处于不稳定状态。但是，当垃圾回收器需要进行收集时，它需要内部结构的空间才能进行此收集，并且使用的内存和对象越多，这些结构就越大。如果垃圾回收器没有足够的空间进行收集，则会出现致命的内存不足异常，进程将停止。
保留内存（性能监视器中的虚拟字节）将比提交的字节（性能监视器中的专用字节）大得多。通常，当内存使用率很高时，差异大约在500 MB左右，而在大约1.2-1.4 GB左右的虚拟字节时，很难找到这些64MB的漏洞，这意味着一个正常的.net进程将在800 MB左右开始脱离内存异常。
同样，这个值会因应用程序、加载的dll和本机com组件的内存分配模式等而异。
现在你知道为什么即使你有很多内存，你也能摆脱内存异常，下一个任务就是找出为什么你要使用这么多内存。

下面是应用程序崩溃转储的调用堆栈。报告的崩溃是名为“HelperLibrary”的模块内的访问冲突，我们没有该模块的符号或源代码。调用堆栈看起来不太可能：

0:000> kv
ChildEBP RetAddr  Args to Child             
WARNING: Stack unwind information not available. Following frames may be wrong.
0028fcec 74ba339a 7efde000 0028fd38 77479ed2
  HelperLibrary+0x1014
0028fcf8 77479ed2 7efde000 776a5346 00000000
  kernel32!BaseThreadInitThunk+0xe (FPO: [1,0,0])
0028fd38 77479ea5 011212b2 7efde000 00000000
  ntdll!__RtlUserThreadStart+0x70 (FPO: [SEH])
0028fd50 00000000 011212b2 7efde000 00000000
  ntdll!_RtlUserThreadStart+0x1b (FPO: [2,2,0])

除了HelperLibrary+0x1014之外，这里没有其他真正的帧，但是我们非常确定堆栈上应该还有其他代码，比如应用程序的主函数
要从这个堆栈重建某些内容，您需要了解谁调用了HelperLibrary+0x1014，即使您没有准确的符号。通常，这是一个遍历EBP引用的问题，但是如果它那么简单，调试器就已经做到了！

好吧，那么EBP怎么样了？

0:000> r ebp
ebp=0034fbfc
0:000> ln ebp
0:000> u ebp
0034fbfc 08fc            or      ah,bh
0034fbfe 3400            xor     al,0
0034fc00 9a33ba7400e0fd  call    FDE0:0074BA33
0034fc07 7e48            jle     0034fc51
0034fc09 fc              cld
0034fc0a 3400            xor     al,0
0034fc0c d29e477700e0    rcr     byte ptr [
  esi-1FFF88B9h],cl
0034fc12 fd              std

如果你没有注意到，这不是实际的代码，而是一堆被解释为指令的数据。EBP完全有可能被损坏，指向完全不相关的位置，但也有另一种可能：当前代码正在使用FPO。
什么是FPO？FPO（帧指针省略）是一种优化技术，而编译器使用EBP寄存器作为暂存值来存储杂项数据，就像任何其他通用寄存器一样。如何处理局部变量和函数参数？直接通过ESP。
换言之，当使用FPO（您可以使用/Oy编译开关启用它）时，编译器可以自由地避免使用以前的EBP值创建“真实”堆栈帧。没有从当前EBP值开始的堆栈帧的链接列表。如果没有FPO信息（出现在符号文件中，而我们没有这些信息），调试器将无法执行任何操作。
这使得我们需要反汇编HelperLibrary+0x1014并尝试手动找出它返回的位置。让我们看看HelperLibrary+0x1014（粗体的违规指令）附近：

0:000> u HelperLibrary+0x1014-0x14 L8
HelperLibrary+0x1000:
66951000 56              push    esi
66951001 ff157c209566    call    dword ptr [6695207c]
66951007 50              push    eax
66951008 c60061          mov     byte ptr [eax],61h
6695100b ff1578209566    call    dword ptr [66952078]
66951011 83c408          add     esp,8
66951014 c60661          mov     byte ptr [esi],61h
66951017 c3              ret

这看起来，确实，像一个FPO的栈帧-没有EBP被看到。但是，随后的ret指令会转到某个地方，因此我们可以查看ESP并在那里找到返回地址：

0:000> dps esp L1
0034fb9c  66951040 HelperLibrary+0x1040

好的，那么HelperLibrary+0x1040是什么？

0:000> u HelperLibrary+0x1040-0x20 LC
HelperLibrary+0x1020:
66951020 56              push    esi
66951021 8bf0            mov     esi,eax
66951023 56              push    esi
66951024 ff157c209566    call    dword ptr [6695207c]
6695102a 50              push    eax
6695102b c60061          mov     byte ptr [eax],61h
6695102e ff1578209566    call    dword ptr [66952078]
66951034 03742410        add     esi,dword ptr [esp+10h]
66951038 83c408          add     esp,8
6695103b e8c0ffffff      call    HelperLibrary+0x1000
66951040 5e              pop     esi
66951041 c3              ret

有点意思。此帧也不使用EBP，因此我们可以预期返回值为ESP+4（因为返回之前的pop指令）。但在这个函数中，我们如何计算ESP的值呢？好吧，假设上一个函数返回。它已经从堆栈中删除了四个字节（返回地址）。ESP的下一个值是ESP+4，我们需要再添加4个字节来解释“pop esi”指令。

0:000> dps esp+8 L1
0034fba4  6695106b HelperLibrary!ImportantFunction+0x1b

好吧！我们正在取得一些真正的进展，我们有一个非常小的偏移量，即使没有符号，ImportantFunction可能是一个导出函数，因此我们在DLL中有它的位置：

0:000> u HelperLibrary!ImportantFunction LD
HelperLibrary!ImportantFunction:
66951050 8b442404        mov     eax,dword ptr [esp+4]
66951054 85c0            test    eax,eax
66951056 7501            jne     HelperLibrary!ImportantFunction+0x9
66951058 c3              ret
66951059 837c240c00      cmp     dword ptr [esp+0Ch],0
6695105e 7e0e            jle     HelperLibrary!ImportantFunction+0x1e
66951060 8b4c2408        mov     ecx,dword ptr [esp+8]
66951064 49              dec     ecx
66951065 51              push    ecx
66951066 e8b5ffffff      call    HelperLibrary+0x1020
6695106b 83c404          add     esp,4
6695106e b801000000      mov     eax,1
66951073 c3              ret

这是另一个没有EBP使用痕迹的函数。注意，它有参数，并且它使用来自ESP的直接偏移量来访问这些参数，ESP是FPO的信号。这个函数返回到哪里？好吧，在上一个函数返回后，ESP已经在当前值的ESP+0xC处。ImportantFunction再添加四个字节，然后返回，因此我们需要查看ESP+0x10：

0:000> dps esp+0x10 L1
0034fbac  00ed100f MainApp!wmain+0xf

对！我们离开了动态链接库，回到符号区！因此，重建的堆栈如下所示：

HelperLibrary!…somefunction…
HelperLibrary!…someotherfunction…
HelperLibrary!ImportantFunction
MainApp!wmain

这些都不是调试器提供的。作为参考，这里是相同的调用堆栈与符号（其中包含FPO信息）

0:000> kv
ChildEBP RetAddr  Args to Child             
003dfee4 668e1040 00000001 668e106b 0000000f
 HelperLibrary!AnotherHelperFunction+0x14 (FPO: [0,0,0])
003dfeec 668e106b 0000000f 010c100f 010c20f4
  HelperLibrary!HelperFunction+0x20 (FPO: [1,0,4])
003dfef4 010c100f 010c20f4 00000010 00000001
  HelperLibrary!ImportantFunction+0x1b (FPO: [3,0,0])
003dff04 010c1191 00000001 00771b78 00771c10
  MainApp!wmain+0xf (FPO: [2,0,0])
003dff48 74ba339a 7efde000 003dff94 77479ed2
  MainApp!__tmainCRTStartup+0x122 (FPO: [Non-Fpo])
003dff54 77479ed2 7efde000 777db3e9 00000000
  kernel32!BaseThreadInitThunk+0xe (FPO: [1,0,0])
003dff94 77479ea5 010c12b2 7efde000 00000000
  ntdll!__RtlUserThreadStart+0x70 (FPO: [SEH])
003dffac 00000000 010c12b2 7efde000 00000000
  ntdll!_RtlUserThreadStart+0x1b (FPO: [2,2,0])

在过去，我研究了一个支持案例，我需要找出C++应用程序中的一些消息框是否被显示，如果是肯定的，消息是什么。每次我问用户时得到的回答都不一致，所以我不知道是否出现了MessageBox或消息是什么。
这听起来像是另一个完美的场景，脚本可能会有所帮助！事实上，这对我帮助很大，我希望对你也有帮助。这个脚本映射MessageBox调用，并将消息从MessageBox记录到Windbg屏幕上，也记录到一个文本文件中。
调试应用程序后，应使用“.logclose”关闭日志。然后您可以搜索字符串“Text from MessageBox”，您将得到应用程序显示的所有MessageBox！
你可以用DBMon.exe或者DebugView.exe查看来自MessageBox窗口的消息。我从来没有在.NET应用程序上测试过它，但它应该可以工作，因为MessageBox是在一些.NET Framework调用的幕后调用。

截图如下：

 注意！在上面的命令后按两次回车键而不是一次。

 Source code for MSGBOX_TRACING.TXT:

$$

$$ =============================================================================

$$ Log MessageBox messages in a log file.

$$ The log file name starts with MessageBox string.

$$

$$ Compatibility: Win32.

$$

$$ Usage: $$>< to run the script.

$$

$$ Requirements: Public symbols.

$$

$$ Roberto Alexis Farah

$$ Blog: http://blogs.msdn.com/debuggingtoolbox/

$$

$$ All my scripts are provided "AS IS" with no warranties, and confer no rights.

$$ =============================================================================

$$

$$ This location 7EEEEEEE is difficult to be used but

$$ it could be occupied!!!

$$

.dvalloc /b 0x7EEEEEEE 0x400

r @$t0 = 0x7EEEEEEE

eb 0x7EEEEEEE 50

bp user32!MessageBoxExW "r @$t1 = @eip; r @eax = poi(@esp + 0x8); r @eip = @$t0;g"

bp @$t0 + 0x6 ".echo <-- Text from MessageBox; r @$ip = @$t1;g"

.logopen /t /u MessageBox.txt

.printf /D "\nType <b>call kernel32!OutputDebugStringW</b> then press Enter key two times then 'g' command after it.\n"

a 0x7EEEEEEF

$$

$$ ATTENTION! Use .logclose after finishing the debugging session.

$$

$$ =========================

Note: Some of my previous scripts were updated! Whenever I do that I write a small comment about it explaining the update.

从前，非托管代码开发人员必须非常努力地将代码偏移量与源文件名和行号关联起来。一种方法涉及为每个模块生成.cod文件（程序集列表），然后费力地将指令偏移量与.cod文件的内容进行比较。
例如，如果从具有客户机接收到错误BatteryMeter!TemperatureAndBatteryUpdaterThread+0xd0，可以返回BatteryMeter.exe的.cod文件，查找TemperatureAndBatteryUpdaterThread的代码列表，然后查找位于（或靠近）偏移量0xd0处的源行。
这个过程可以自动化。前几天有人问我是否还需要使用.cod文件，答案是否定的。如果你启动WinDbg，你只需“文件>打开转储文件”，输入你的.exe或.dll作为转储文件名，然后发出ln命令，如下所示：

0:000> ln BatteryMeter!TemperatureAndBatteryUpdaterThread+0xd0
d:\dev\batterymeter\batterymeterdlg.cpp(58)

如果您手头没有WinDbg又希望自动执行此操作（可能是通过脚本），可以使用DbgHelp API加载相应模块的符号，然后查找符号名称和源信息。所涉及的函数是SymLoadModule64、SymFromName和SymGetLineFromAddr64，生成的程序不超过100行代码：

DWORD displacement;
IMAGEHLP_LINE64 line;
RtlZeroMemory(&line, sizeof(line));
line.SizeOfStruct = sizeof(line);
if (!SymGetLineFromAddr64(hProcess, symbolAddress, &displacement, &line))
{
    printf("*** Error retrieving source line for %s: 0x%x\n",
        argv[1], GetLastError());
    return 1;
}
printf("%s [0x%I64x] = %s line %d (+0x%x)\n", argv[1], symbolAddress,
    line.FileName, line.LineNumber, displacement);