Windows系统与网络管理指南

Windows系统与网络

管理指南

Windows系统与网络管理指南

在Windows环境中，系统与网络管理从来不是一个新鲜的话题，却又一直保持着它的热度并且倍受关注。有哪些工具是必不可少的？哪些工具帮助我们事半功倍？哪些技巧能简化管理程序？针对这些问题，本专题汇集了增强Windows系统和网络性能的最热门工具和技巧，除此之外，这里还有来自专家们的意见，他们对于微软的SCCM、SCOM等系统中心产品有丰富的经验。

实用工具——赶走烦恼的小帮手

各种工具在所有的管理中都是必不可少的，当然，在Windows系统与网络管理中，也有那么一些工具起到至关重要的作用。在本小节中，我们将向广大用户推荐一些系统与网络管理中所需的工具，花些时间来了解一下这些工具，你在系统与网络管理上的进展将不只一点点。

API Monitor：可显示应用程序性能的Windows工具

不可错过三款免费Windows性能监测工具

解决Windows应用程序崩溃或者终止的免费工具

提速并支持Windows服务器的免费PHP插件

问题解决方案汇总

Widows系统与网络管理的过程中，总会不断涌现出这样或那样的问题，那么这些恼人的问题我们该如何从容面对呢？本小节总结了一些常见的问题，结合Windows专家的意见，提供了专业且有针对性的解决方案。

解决在Active Directory环境里Windows登录性能问题

使用ProcDump工具解决Windows应用程序崩溃或者终止

免费Windows工具让蓝屏机起死回生

如何用Icacls创建自动权限管理解决方案？

管理技巧集锦

你是否正为搜集各种Window系统与网络管理技巧而愁眉不展？你是否正为手中整理的管理技巧已经不再适用于现在的环境而苦恼？在这个专题中，我们收集整理了Windows系统与网络管理领域最新最实用的技巧，集锦成册，专供大家下载浏览。

用SCVMM管理VMWare虚拟机的绝妙之处（上）

用SCVMM管理VMWare虚拟机绝妙之处（下）

使用Sysinternals Autoruns工具辅助软件调试

身份和访问管理名副其实吗？

认识Windows PowerShell函数的参数

API Monitor：可显示应用程序性能的Windows工具

我最喜欢的Windows工具是那些不仅能让你看到后台运行情况（可以这样说），还能让你了解引擎内部的工具。比如说Process Explorer，它一直是这种应用程序的王者。但是随着时间推移，我又发现了几个其它程序，它们可以弥补Process Explorer功能上的不足。其中最新的程序是Rohitab Batra创作的API Monitor。

根据API Monitor这个名字，我们不难猜测它的功能。它可以跟踪程序调用的应用程序接口（API），并让你通过几种方式来分析结果。该软件并不适用于初学者，因为它需要你对Windows API有一定的了解---否则，它返回的结果对你没什么用处。

API Monitor与你想要监视的程序同时运行。当你运行该程序时，你可以在窗口的左上角看到API列表，你可以在其中选择想要监视的API。窗口的左下角部分显示正在运行的进程。在其中一个进程上右击，点击Hook 选项，API Monitor就会将先前选中的所有该进程使用的API转储出来。

每个挂载（hooked）进程在Hooked Process窗口中就是一个副条目。展开该程序条目，你将会看到该进程用到的线程列表。请注意，被终止的线程是灰色的。选择一个线程，你将看到这个线程中的API调用列表。点击一个调用，你就会在另外一个子窗口中看到它的参数。

然而API Monitor的功能不仅局限于转储本地Windows API。它还可以使用第三方工具（如Mozilla）来预先定义API。如果你自己想为动态链接库（DLL）添加一个定义，那么你可以用简单的XML格式手动创建一个定义文件，并把它添加到该程序API的词典中。这些词典可以让你为API注册网络链接，也就是说如果你点击一个API名称，你就会在一个浏览器中看到这个名称的描述（比如说来自MSDN）。

还有很多教程，它们可以协助你完成某些常用的API Monitor任务，比如说从Internet Explorer上截获SSL加密的网络流量。看到这个请不必惊慌，请记住，这只是在本地计算机上截获流量，如果有人能够访问你机器的控制台，那么在安全方面就完蛋了。

API Monitor有两种版本---一种用于监视32位应用程序，另一种则用来监视64位应用程序。64位版本的Process Explorer能够分析32位的应用程序，但是API Monitor不一样，你只能用64位版本的API Monitor来分析64位的应用程序，反之亦然（你只能用32位版本的API Monitor来分析32位的应用程序）。此外，请注意有些程序在挂载或者非挂载时可能会崩溃，所以如果正在运行的程序使用的数据你没有备份过，请不要挂载该程序。

更老的版本---API 1.5版（只能监视32位应用程序），也是可用的，但是笔者更鼓励使用新版本，原因有二：新版本具有扩展的功能套件；新版本有助于揭示bug。

API Monitor

(作者：Serdar Yegulalp译者：Dan 来源：TechTarget中国) 原文标题：API Monitor：可显示应用程序性能的Windows工具

原文链接：https://www.sodocs.net/doc/941475161.html,/showcontent_39662.htm

不可错过三款免费Windows性能监测工具

大多数服务器管理员都熟悉免费的Windows性能监测工具（performance monitoring tools），如Perfmon，但Windows Server的最新版本还包含了全新的免费工具，其功能更全面，足以媲美昂贵的第三方产品。

在上周举行的BriForum 2010论坛上，来自密歇根州Ann Arbor 市Thomson-Reuters公司的高级网络服务管理员Ian Parker主持了一次会谈，详细讨论了Windows Server 2008自带的三款性能监视工具：Windows系统资源管理器（WSRM）、数据收集器（Data Collector Sets）和Xperf。

WSRM

WSRM可用于向应用程序、用户、远程桌面服务（RDS）会话和因特网信息服务(IIS)应用程序池（application pools）分配处理器和内存资源。如果资源不能得到有效管理，它们可能会逐渐消耗计算资源。

WSRM只有在处理器负载利用率超过70%时才会获取相关的信息，此时的管理员可以创建自定义的资源政策、程序和工作优先级。Parker举了一个例子，在美国“疯狂三月”（March Madness）期间，由于此时那些篮球迷终端用户会观看大量的flash视频，所以管理员可以将IE浏览器设置为低优先级。

你可以通过文件名、用户组、已注册服务、进程或程序名来自定义资源策略。WSRM还能让IT管理员在管理时终止进程，同时为某些特定事件（如硬件或簇变动）制定自动响应的日历规则和方针。

此外，WSRM允许管理员整合多个服务器的数据资源，然后将其集中在本地、或储存在一个自定义的SQL Server数据库中。管理员还可以为启动了远程桌面服务（RDS）的主机创建工作组并对其进行管理。

最初在Windows Server 2003企业版和数据中心版中可以用到这个工具，如今的Windows Server 2008 R2也包含了它。

数据收集器

数据收集器(DCS)，即下一代服务器性能顾问（Server Performance Advisor, SPA），是一个基于XML的性能检测/诊断工具集。它是Windows Server 2008和Windows Server 2008 R2的组成部分，由局域网检测工具、系统诊断工具和性能

监视工具等组成。

用户可以自定义DCS的功能，还可以导出它的配置数据，然后再将其导入其他服务器。这有助于用户为整个公司的服务器制定统一的使用标准。Parker表示，DCS还提供了诸如注册表状态、用户账户控制、防火墙状态、内存大小以及CPU性能等方面的信息，这些信息都可以收集并记录到系统检测的文件中。他说，“如果要对服务器的基本状态做一个快速诊断，你只需花几分钟运行数据收集器即可。”

DCS最大的好处之一就是，它可以在不必安装任何额外软件的情况下，让管理员检测出活动目录（AD）的性能问题。而在数据收集器集成于操作系统之前，如果管理员想进行同样的操作，就必须安装像SPA这样的工具。

“诊断CPU或硬盘相对容易，但找出活动目录的问题则完全是另外一回事，”Parker说。“这有点类似于黑盒测试。”

在DCS中，活动目录的性能测试结果会显示在诊断（Diagnostics）节点下的服务器管理（Server Manager）单元中。根据微软的报告，如果你已经安装了活动目录域服务任务（Active Directory Domain Services Role），那么系统将会自动创建活动目录诊断数据收集器（Active Directory Diagnostics Data

Collector Set）。

Xperf

如果说DCS是一款用于检测一般系统性能的好工具，那么Xperf则是解决系统使用率、磁盘I/O占用太高等问题的最佳选择。

Xperf是Windows Server 2008中的性能调节工具，它使用的是Windows事件跟踪架构（Event Tracing for Windows，ETW）。Xperf能提供整个系统在长时间内运行的完整性能数据，这对检测某些特定的性能问题很有帮助。按照微软的说法，它还是唯一一个能够处理、分类内核所有事件的工具，并且这些分类信息将有助于IT专业人员解决系统出现的问题。

“如果我有一个进程或程序运行异常，特别是在同一服务器上的其它进程都运行良好的情况下，就可以求助于Xperf，”Parker说。“一般来说，Xperf提供的信息更为详细，其功能也更强大，尽管有时候它也会有点小题大做。”

Xperf所提供的进程深度分析信息非常实用，特别是当这些信息被用作重叠图（overlay graphs）的时候。例如，管理员可以将数据进行重叠，从而找出内存消耗与硬盘分页调度峰值之间的联系，或者观测出哪个进程与CPU核心使用率最为相关。

微软声称，尽管Xperf可以收集大量的数据，但它的系统开销却非常小，每次信息记录仅需耗费大约1500至2000个时钟周期。该工具还可以通过Xcopy命令进行快速安装。

因为Xperf是一个开发者工具，所以它没有图形界面，只能在命令行下运行。作为微软官方支持的Windows性能工具包（Windows Performance Toolkit）的一

部分，用户只能通过Windows SDK来调用它。

(作者：Bridget Botelho 译者：Dan 来源：TechTarget中国) 原文标题：不可错过三款免费Windows性能监测工具

原文链接：https://www.sodocs.net/doc/941475161.html,/showcontent_37719.htm

解决Windows应用程序崩溃或者终止的免费工具

对于windows管理员来说，进行问题诊断的最大挑战之一，是一个用户应用程序发生异常终止或者崩溃。因为崩溃或者终止的不连续性，想要捕捉到应用程序的误操作是非常困难的。其留下的寻找问题原因的线索也是非常少的。

不用害怕！有一些简单的工具可以帮助你将问题区分为特定的程序、DLL、错误或者某个条件，能引导您找到有文件记录的解决办法或补丁。这篇文章会综述各种免费的工具，包括Mark Russinovich最新的ProcDump工具，这个工具可以辅助你诊断应用程序的崩溃或终止，并可以让您智能地搜索万维网以获取解决方案。

免费工具

每个人都喜欢免费工具，但有时，在互联网上，仍然需要为它们付出代价。免费工具常常需要您在下载前提供一个Email地址，以便能在之后的几年向您兜售产品。它们也可以打开闸门，导致间谍软件或者其它木马程序，去危害您的服务器。因为这些原因，我很少下载微软以外的工具。

值得庆幸的是，微软提供了许多可以用于诊断应用程序终止和中断的免费工具。多年以来，一个叫做Dr.Watson的工具已经作为了Windows操作系统的一部分。通过合理地配置，Dr.Watson可以检测到应用程序的崩溃，并提供一个日志文件和用户转储文件，以便进行问题诊断。对这些数据的分析，常常会归结为一个错误代码或者一个有文件记录的解决办法或补丁。有关Dr.Watson使用的更详细的信息，您可以参考微软的知识库文章246084以及278689，或者通过Drwtsn32.exe 的在线帮助。您也可以查阅我以前的文章installing and using the Windows debugger，也叫做Windbg。

可能ADPlus是比Dr.Watson更有用一点的工具，您可以从Debugging Tools for Windows那里下载到这一工具。ADPlus是一个VB脚本文件，可以用于监控应用程序是否发生异常情况。并在发生时，俘获用户转储文件。这个工具也可以用于对一个挂起的用户应用程序强制进行崩溃转储，以便您可以使用Windows debugger去分析转储。扩展的资料可以参考微软知识库文章286350里面有关ADPlus使用的介绍，或者我在troubleshooting Windows print spooler outages 里面的一些提示。

如果让您感到棘手的应用程序中包含微软互联网信息服务（Internet Information Services IIS)，那么您可以选择的工具是微软的DebugDiag。这是

一个综合性的工具，并可以用于识别一系列的问题，包括Web服务器挂起、变慢的性能、崩溃以及内存泄漏。这个工具也可以用于那些不包括IIS的简单Win32应用程序。您可以从微软那里下载 DebugDiag，而且有关这一工具有大量的文献资料，包括微软的知识库文章931370以及Tim Fenner在文章using Debug Diagnostics on troubleshoot IIS issues中的介绍。

最后，还有一个微软新推出的工具ProcDump。这个工具结合了上述所介绍工

具的很多特征，而且还包含一个非常方便的功能，可以当CPU的活动峰值在指定时间内达到一个预定的水平时，进行进程的转储。本文的其余部分将仔细研究ProcDump，并使用Windbg去分析转储的内容。

(作者：Bruce Mackenzie-Low译者：刘波来源：TechTarget中国) 原文标题：解决Windows应用程序崩溃或者终止的免费工具

原文链接：https://www.sodocs.net/doc/941475161.html,/showcontent_30437.htm

提速并支持Windows服务器的免费PHP插件

在过去的几年中，微软已经做了很多工作来优化Windows服务器上的PHP性能，这也使每个人都得到受益。

例如，PHP背后的人们现在有来自世界上最大应用平台之一的支持，用PHP编写的程序员享受Windows服务器上应用程序的增强性能。上述应用程序的用户在等待页面打开时只需要花更少的时间，微软也把这视为是另一件Windows服务器值得骄傲的事情。

在Windows服务器可以进一步加速PHP的方式之一就是运用PHP的Windows缓存扩展，它是一个能使PHP在互联网信息服务（Internet Information

Services ，IIS）之下运行的附件，它是免费的、BSD授权的开放源代码工具，因此它的代码可以在极小的限制下实现移植、重用和重新分配，并以完整文档的形式直接放在了https://www.sodocs.net/doc/941475161.html,上。

已有的PHP Windows缓存扩展版本是1.01，而现在又新出了一个1.1测试版可供公众下载和评估。但请注意，不推荐大家在实际工作环境中使用该测试版。

类似于微软的动态服务器网页（ASP）缓存和加速过程，Windows缓存扩展的工作原理是字节代码（bytecode）缓存（PHP脚本编译后的形式）。大多数使用PHP的网站倾向于运行相同的脚本，这样在自动缓存后可以使得性能大幅度提升。

这个工具还可以缓存许多其它的东西，包括：

?使用PHP脚本的文件（包括脚本本身和调用这些脚本的文件）；

?解析相对路径得到的绝对文件路径；

?被对象和变量所占有、可在用户会话之间共享的内存；

?会话处理器（session handler）数据；

备注：最后两个只在当前的1.1测试版本中才可以缓存。

在安装PHP的Windows缓存扩展前，请确保你有适当的系统配置（一般要求PHP 5.2.0或更高版本，IIS 网服务器的最新版本），和FastCGI扩展。

PHP安装过程需要做一些比较繁琐的手工操作（好在这些操作并不是太古怪）。例如，程序的运行时间设置可以通过一个ini文件来手动编辑。需要做些改变的是各种缓存的大小，以及哪些文件（如果有的话）因故而不能缓存。请注意，一些缓存大小互相依赖，因此需要阅读设置文档来了解相互之间如何影响，这一点非常重要。

现在，只有X86版本的缓存扩展可用。虽然没有x64版本，但32位版本在64位的Windows服务器上应该也能正常工作。除此之外，你还可以使用VC9非线程安全版本的PHP（这是大部分互联网信息服务推荐的）。

最后，如果你对分析应用程序的缓存性能感到好奇，可以看看该安装包中包含的另一个脚本，它可以让你在进行PHP缓存统计时，导出Windows缓存扩展的基本情况。

(作者：Serdar Yegulalp 译者：Dan 来源：TechTarget中国)

原文标题：提速并支持Windows服务器的免费PHP插件

原文链接：https://www.sodocs.net/doc/941475161.html,/showcontent_38319.htm

解决在Active Directory环境里Windows登录性能问题

与性能相关的问题通常是最难解决的，主要由于要考虑许多变数。在本文中，TechTarget中国的特约专家Gary Olsen介绍当用户登录到域账户时，如何诊断和解决登录性能缓慢的难题。

在解决任何性能问题时，你必须首先定义能接受的延迟范围。我见过一些环境，用户经历5到10分钟的登录时间也不抱怨，因为他们习惯了。我也见过其他情形，就算一分钟的延迟也是不可接受的。这就是为什么先要定义可接受范围的原因，以便你知道如何解决问题。

Windows登录性能因素

当查找登录性能问题的原因时，考虑大量因素很重要。一些因素包括：

?域控制器太接近用户

?网络连接与可用的带宽

?数据中心上的硬件资源（x64 vs.x86、内存等）

?应用于用户和计算机的组策略（GPO，会直接影响带宽）数量

?用户和计算机所在安全组的数量（也直接影响带宽）

?需要额外处理时间的GPO包含设置，如：环回处理、WMI过滤器和ACL过滤

?繁重的载入域控制器由以下因素造成：需要认证的应用、来自用户脚本或应用的无效LDAP查询、宿主其他应用，如Exchange、IIS、SQL Server等的数据中心

?客户端配置：内存、磁盘、处理器等、网络接口（10个、100或1000个）、到站点的合适子网映射和DNS配置

定义范围

为了定义问题的实际范围，我通常花时间询问简单的问题。这需要一些精力，因为这些问题通常由抱怨问题的用户定义。下面是需要询问的重要问题：

?这些问题定义为单个站点、安全组、OU、部门、客户端的类型（笔记本还是桌面）还是操作系统？

?问题在每天某个时刻发生吗？

?当你在办公室或者跨VPN连接就发生问题吗？

?描述症状：延迟每次发生在某个点吗？（例如发生在登录屏幕的“Network Settings”上）、在登录页面之前还是之后发生？

?什么时候开始发生的？

工具和数据收集

我使用一些基本的工具收集数据。对于性能问题，我喜欢广撒网，收集所有能收集的信息。如下面例子：

在客户端和他们的验证数据中心运行微软产品支持报道（MPSreports）。这是个常用的工具，收集所有事件日志、MSINFO32、NetDiag、PConfig、驱动与hotfixes等的数据。Hewlett-Packard自身也有叫做HPS Reports的版本，在我看来，它比微软的工具更高级，如果运行在数据中心上，可以收集具体的Active Directory数据。它也收集与硬件相关的多余信息，甚至不是HP的硬件也可以收集。

在客户端，使用Microsoft KB article 221833为Winlogon系统进程设置冗长的登录。这将在%Systemroot%\Debug\UserMode\Userenv.log文件里提供精确的细节。注意，这个日志不包括数据日期，因此你必须：

1.从客户端删除现有的userenv.log

2.启动verbose登录为每KB 221833

3.注销、登录并保存userenv.log到新地点，以在登录期间限制数据收集

注意，userenv.log在下面的GPO和配置文件进程很精确，并且通常你能明显看见哪里发生了登陆延迟。

启用Net Logon登录。Netlogon日志位于%systemroot%\debug，如果没有启用登录就是空的。例如，它会显示子网里的哪个客户端没有映射到站点。这会导致客户端在数据中心之外验证，需要的登录时间比预想的长。

运行来自Sysinternals的Process Monitor。在启用启动日志上的Help部分查看细节。你能在缓慢启动期间捕获进程信息查看哪个处理器在影响性能。

解决客户端登录缓慢的其他技巧

你还能查看下面的一些事情，看是否由已知的问题导致登录性能。

首先，在客户端上检查GPResult.exe和LOGONSERVER环境变量，MPSreports 和HPS Reports将为已登录的用户收集GPResult，它们不收集指向验证数据中心的LOGONSERVER变量。这很重要，因为每次用户登录，都会下载GPO到客户端。SYSVOL（包含GPO）是DFS根，不服从客户端站点警告。相反，它以随机命令收集数据中心（宿主SYVOL DFS根），然后可以从列表里的第一个数据中心下载GPO。

我遇到过这样的情况，在主服务站点的客户端将跨过缓慢的WAN连接到数据中心外，以获得GPO，导致了非常缓慢的登录时间。由于这可能在每个登录上发生，所以这个问题是间歇性的。

为下载GPO的数据中心检查GPResult，并查看GPO是否来自数据中心外面。

同样，比较LOGONSERVER变量，查看客户端是否在数据中心外验证。使用已知的缓慢或繁忙连接，登录延迟能解释为“通常”行为。

另一个好测试是使用网络启动安全模式，查看是否发生延迟。如果没有，那么进行Net Start并列出所有启动的服务。然后以正常模式启动并运行Net Start，再次列出所有服务。这个不同就能证明是哪个服务有嫌疑，一次消除一个能帮助你识别问题。你也能尝试禁止启动时开始的应用，查看该应用是否是原因所在。

最后一种技术是使用Netmon、Wireshark或其他网络捕获工具进行网络追踪。由于你尝试捕获登录进程，将dumb hub连接到网络线缆，然后从hub连接线缆到有问题的PC，然后连接另一个线缆到安装了Netmon或WireShark的另一个PC或

笔记本。在混合模式里运行捕获工具并复制登录。这样的设置将确保捕获工具收集客户端内外的流量，并消除网络噪声。

上面所述的是你要掌握的基础。只需要记住没有任何偷懒的情况——需要花费时间和精力找到问题。在下一篇文章里，我将介绍解决问题的一些方法。

(作者：Gary Olsen 译者：唐琼瑶来源：TechTarget中国)

原文标题：解决在Active Directory环境里Windows登录性能问题

原文链接：https://www.sodocs.net/doc/941475161.html,/showcontent_29247.htm

使用ProcDump工具解决Windows应用程序崩溃或者终止

ProcDump是一个可以用于诊断多种问题点的命令行工具。和Dr.Watson、ADPlus 以及DebugDiag一样，ProcDump可以在不期望的情况或者异常发生时，用于俘获一个进程的内存转储。而且也同ADPlus以及DebugDiag一样，它可以对一个挂起的应用程序强制进行进程转储。但和之前的任何工具不同的是，ProcDump可以在CPU的活动峰值达到一个指定的级别时，对一个进程进行转储。这对于那些间歇性的性能问题是特别有用的，对于这种问题，其发生是很难预测的。

ProcDump包括一个单独的可执行文件(procdump.exe)，而这个文件可以接受多种不同的参数。当不带任何参数时，ProcDump工具会在保持应用程序执行的情况下，强制进行一个内存转储。例如，如下的命令会强制对微软Outlook应用程序进行转储，获取其内存的内容，并放到outlook.dmp文件中。

C:\> procdump outlook.exe

默认情况下，对进程内存的转储只会获取线程和句柄信息。而当使用参数-ma 时，会执行一个完整的进程内存转储。这样就可以让调试器识别到应用程序的更多信息，包括线程环境(!teb)、进程环境(!peb)以及锁信息(！locks –v)，就像下图中，winword.exe的调试器输出那样。

图1

通过使用-h参数，ProcDump会检测一个挂起的Windows应用程序，并强制进行内存转储。这与ADPlus和DebugDiag中的功能很相似。使用-e参数可以使得ProcDump去检测应用程序的一个未处理的异常，并获取进程转储。通过接下来对进程转储的分析，您可以弄清哪些程序、DLL以及错误情况在中断时发生了。这可以让您通过在网上进行智能的搜索，找到相似的场景，以便确定是否发生了一个已知的问题点，或者您是否需要和卖方进行联系。

让ProcDump和之前的工具与众不同的是，它可以检测CPU峰值，并在达到时，收集进程转储。对于别人无法干预的间歇性问题，这是非常有用的。有三个参数可以实现这一功能：

-c 在产生一个进程转储前，指定CPU达到的阈值。

-s 指定达到该阈值的持续时间秒数

-u 指定CPU为单核

为了说明其使用方法，让我们来看一个简单的例子。下面的第一个命令会开启一个独立的窗口，并在该窗口执行一个遍历系统磁盘的目录命令。然后，您可以使用tlist命令去快速地找到PID（进程ID）。最后，使用ProcDump命令去指定在PID 1432上(在这个例子中)CPU阈值为10%,持续时间为至少2秒时会产生一个进程转储。

C:\> start "dir window" dir /s c:\

C:\> tlist

[…]

1432 cmd.exe dir window - dir /s c:\

C:\> procdump -c 10 -s 2 1432

ProcDump v1.4 - Writes process dump files

Copyright (C) 2009 Mark Russinovich

Sysinternals - https://www.sodocs.net/doc/941475161.html,

Process: cmd.exe (1432)

CPU threshold: 10% of system

Duration threshold: 2s

Number of dumps: 1

Hung window check: Disabled

Exception monitor: Disabled

Dump file: D:\Kits\ProcDump\v1.4\cmd.dmp

Time CPU Duration

[12:09.18] 15% 1s

[12:09.19] 10% 2s

Process has hit spike threshold.

Writing dump file D:\Kits\ProcDump\v1.4\cmd_091709_120919PM.dmp... Dump written.

当然，这是有关其使用的一个不切实际的例子。因为实际上，应该指定一个更长时间，以及一个更高的CPU阈值，以便防止间歇性的CPU峰值。但这是一个简单的示例，以展示这些参数是怎样一起被使用的，比便触发一个进程转储。

一旦进程转储已经被写入，您就可以使用Windbg去分析其内容。可以从下图中看到，调试器标注，一个进程占用了超过10%的CPU时间，并持续了2秒，并显示了其线程ID(0xc2c)。线程ID是很重要的，因为一个进程可能有多个线程。所以你应该集中到造成CPU峰值的线程的堆栈模式。

图2

最后，通过对调试器发出~*kv命令，会显示所有线程的堆栈模式，并同时提供被执行的函数的名字。在下面的例子中，您可以看到，目录命令是怎样去执行多种功能，像cmd!FileIsConsole、 cmd!WriteEol、cmd!NewDisplayFile 以及

cmd!WalkTree。尽管这些功能名对我们来说没有什么意义，但我们可以用它们作为关键词，在网络上去搜索针对我们失控进程的可能解决方案。

图3

就像您所看到的，有很多免费的工具可以被用作对应用程序崩溃和挂起的诊断。我们介绍了Dr. Watson、ADPlus、 DebugDiag 以及 ProcDump都是怎么去获取进程转储。然后，通过使用Windbg，您可以对转储进行分析，并查看崩溃场景中的当前线程，或者被ProcDump所识别的失控线程的堆栈模式。

(作者：Bruce Mackenzie-Low 译者：刘波来源：TechTarget中国)

原文标题：使用ProcDump工具解决Windows应用程序崩溃或者终止

原文链接：https://www.sodocs.net/doc/941475161.html,/showcontent_30440.htm

免费Windows工具让蓝屏机起死回生

本人无比讨厌蓝屏，我讨厌看到它，讨厌蓝屏后的清理工作，最讨厌的就是发生严重错误蓝屏之后还不得不想办法找到原来的数据。然而，当真的发生严重错误的时候，蓝屏时候的状态却是你少数可以依赖的用来查清楚到底发生了什么问题的依据之一。

通常，任何在蓝屏之后能相对高效地给管理员们提供帮助的工具都会大受欢迎。所以我要在本文中用一些笔墨来称赞Nir Sofer和它的免费工具BlueScreenView。

BlueScreenView反复通过发生蓝屏时产生的转储文件，然后生成包含在这些文件中的在系统崩溃时的综述信息。通常，深入分析这些文件并从它们得出有用的结果是一件非常繁琐的事情。BlueScreenView帮你解决了许多这方面的麻烦，并且帮你从每次的系统崩溃中得出最需要的信息。

当蓝屏发生的时候，你必须用管理员帐号运行它，它将显示两个面板的视图。顶部包含一列转储文件的清单，底部则显示以下三种由你选择的内容之一：

?你所选择的一个蓝屏事件中所找到的所有驱动的清单

?在系统崩溃的时候仍然在进程中的驱动清单（典型的用法是显示出什么组件导致了崩溃）

?重现蓝屏事件本身

如果你首先选择所有驱动视图，你也可以使用功能Options | Mark Drivers Found In Crash Stack来高亮显示出故障的驱动来快速参考。

选择一个或者多个转储文件，你可以将结果导出到一个HTML文件中，它会用系统默认浏览器自动打开。一点小烦恼：当你用选择的转储文件生成报告的时候，它仅导出在顶部面板中显示的报告，而不能包含故障当时的驱动报告。你不得不用这个办法重复导出两次，如果你想要这两种报告。一般来说你会同时需要它们两种，因为堆栈驱动可以很容易用来定位错误原因。

请注意，BlueScreenView是一个32位的程序，它也可以稳定运行在64位的服务器和工作站上。

最后，请允许我提供一些个人案例。最近我的一台机器在短时间内连续发生多次错误，BlueScreenView帮助我在当时保持头脑清醒。通常蓝屏都是发生在有硬件错误的时候（KERNEL_STACK_INPAGE_ERROR and MEMORY_MANAGEMENT)。但是这次在我自己遇到的例子中，蓝屏并不是因为硬件错误，而是因为硬件上的灰尘过多造成的。当我把它打开的时候，发现这机器真的应该好好清理一下并且重新插拔内存条了。