4

抱歉，我想不出一个很好的方式来表达我的真正问题。

我在 64 位机器上运行一个高流量的 ASP.NET 站点。但是，由于应用程序的一些遗留组件，我有 IIS 在 32 位模式下运行。我正在一个应用程序池中运行这个特定的 Web 应用程序，该应用程序池启用了 Web Garden 选项（在 8 核机器内运行 6 个进程）。

每周一到两次，其中一个进程将飙升至 100% 的 CPU 利用率，从而导致站点的速度大幅下降，所以我的计划是等到这种情况发生，内存转储有问题的进程，然后在 WinDbg 周围戳到零用于查看代码在哪里旋转的线程。

我之前使用 WinDbg 进行过调试，以找出导致网站死锁的原因，但那是几个月前的事了，我不记得我是如何让它工作的。（作为旁注，这是记录您所做的一切的课程。）

我在运行该站点的 Windows 2003 服务器上运行 WinDbg，以防止任何 DLL 版本问题。到目前为止，这是我的步骤，请让我知道我哪里出错了，以获取我收到的错误消息。

  1. 我首先使用 UserDump 使用以下命令对尖峰进程进行内存转储，其中 3389 是进程的 ID：

    userdump -k 3389

  2. 我将转储加载到 WinDbg 的 x86 版本中。

  3. 由于我在 64 位机器上运行 32 位，我首先加载内存转储，然后：

    .load wow64exts

    .effmach x86

  4. 我确保我的符号路径包含包含我的应用程序 PDB 文件的目录：

    .sympath+ c:\inetpub\myapp\bin

  5. 仅运行 `.load SOS' 失败，并出现“系统找不到指定的文件”错误，所以我采用以下完全合格的路线，该路线有效：

    .load c:\windows\microsoft.net\framework\v2.0.50727\sos

从这里开始，我迷路了。我尝试了任何 SOS 命令，例如!threads，只是为了得到这个错误：

Failed to load data access DLL, 0x80004005

该错误还伴随着我应该验证的项目编号列表。我已经验证我正在运行最新版本的调试器，mscordacwks.dll 实际上与 mscorwks.dll 文件位于同一目录中，并且我在与转储文件相同的架构上进行调试。

我也运行了神奇的“ .cordll -ve -u -l”命令，但这并不能解决任何问题。CLR DLL status: No load attempts当我执行那个时，我总是用“”打招呼。然后我尝试“ .reload”，它会产生一些像“ WARNING: wldap32 overlaps dnsapi”这样的警告。我希望它说类似“ CLRDLL: Loaded DLL C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscordacwks.dll”。但事实并非如此。

4

5 回答 5

3

在运行 sos 命令之前尝试执行 !sw。请参阅此博客文章。

于 2008-10-07T14:45:08.960 回答
2
于 2008-10-07T14:41:29.153 回答
2

根据我的经验，应用程序池激增可能是因为它被回收了。您是否尝试过 IIS 崩溃/挂起代理和 IIS 转储？

http://www.microsoft.com/downloads/details.aspx?FamilyID=01c4f89d-cc68-42ba-98d2-0c580437efcf&DisplayLang=en

它们还包括一个转储文件分析器，它将告诉您内存泄漏，甚至建议您的代码需要修复的区域（完整的链接到适用的 MSKB 文章！）

于 2008-10-07T15:18:20.047 回答
1

伙计 - 不确定这是否有帮助，但也许试试这个。

  1. 将 c:\windows\microsoft.net\framework\v2.0.50727\sos.dll 复制到安装 windbg 的同一目录（例如 c:\program files\Debugging Tools for Windows\ ）。为什么？轻松加载sos文件
  2. 运行windbg
  3. 加载内存转储文件。对我来说，我使用 ctrl-D 或 File -> open crash dump
  4. .load sos <-- 注意加载命令之前的句号
  5. .symfix c:\temp\debug_symbols
  6. .reload

好的..注意命令行。这告诉我转储所在的当前线程。这对于高 CPU 场景可能没用..因为我们可以在任何线程中。

所以从这里我查看正在运行的线程并检查最繁忙的线程

8 !threadpool <-- 这样我就可以看到 cpu 利用率来检查我们是否处于垃圾（忙碌）状态......例如 100% cpu 或其他什么。

9 !runaway <--列出最长的线程...例如。

0:027 !runaway
User Mode Time
Thread       Time
18:704       0 days 0:00:17.843   <-- Thread #18
19:9f4       0 days 0:00:13.328   <-- Thread #19
16:1948      0 days 0:00:10.718
26:a7c       0 days 0:00:01.375
24:114       0 days 0:00:01.093
27:d54       0 days 0:00:00.390
28:1b70      0 days 0:00:00.328
0:b7c       0 days 0:00:00.171
25:3f8       0 days 0:00:00.000
23:1968      0 days 0:00:00.000

线程 18 和 19 已经挂了一段时间了.. 嗯.... 他们卡在一个循环中了吗？

  1. ~18s <--转到线程 18。
  2. !clrstack <-- clr call stack .. 就像在windows中调试一样。

..从这里你可以通过提供地址引用和东西来转储对象和东西。

查看 !help 列出一些可以尝试使用的命令 .. 我认为 !help.sos 也可以吗？

HTH ..如果你仍然被卡住，问问什么有效，什么无效。

于 2008-10-30T12:52:32.540 回答
1

我只需要处理一个类似的问题。就我而言，事实证明 WinDbg 无法找到正确版本的 mscorwks.dll。除了框架版本之外，还有一个 DLL 的修订版，它可以在相同的框架版本之间有所不同。

理论上，Microsoft 符号服务器应该能够提供必要的 DLL，但对我来说并没有发生。为了解决这个问题，我曾经!sym noisy获取有关符号加载的更多信息。当我这样做时!dumpstack，我收到了错误消息：

SYMSRV: http://msdl.microsoft.com/download/symbols/mscorwks.dll/492B82C1590000/mscorwks.dll not found

为了解决这个问题，我在本地符号缓存中创建了适当的文件夹，并从转储所在的机器上复制了 mscorwks.dll。之后.reload，WinDbg 在本地符号缓存中找到了需要的 DLL，然后愉快地继续。

或者，您可以找到与lm v m mscorwks. 然后，您可以从此列表中找到包含您需要的版本的更新。您需要从特定更新中提取必要的 DLL 到正确的位置。

于 2009-08-05T23:01:56.810 回答