欢迎光临 Enjoy IT (ITECN.NET) 登录 | 注册 | 帮助
2012年5月15日 21:15

五月微软安全公告引发的两则 Windows 更新问题

微软于上个星期二（2012 年 5 月 8 日）准时发布了五月安全公告与相应安全更新。在本月发布的
更新程序中，有两个更新可能会引起安装问题，需要提请各位用户注意。


★ MS12－035 中关于 .net Framework 1.1 的更新 KB 编号有误。

本月发布的 MS12－035 是一则关于 .net Framework 的安全公告，
影响几乎 .net Framework 的所有版本：

http://technet.microsoft.com/zh-cn/security/bulletin/ms12-035

在公告中针对 .net Framework 1.1 版的部分里，MS12－035 最开始提供的更新编号为 KB2604044，
并且在公告中宣称：“MS11－100 中的 KB2656353 由 MS12－035 中的 KB2604044 替代”。但是，
当笔者试图在多台已经安装有 .net Framework 1.1 与 KB2656353 的计算机中安装 KB2604044 时，
安装程序却报错：

“信息 9005。没有必要安装 .net Framework 1.1 Hotfix KB2604044，因为 .net Framework 1.1 Security
Update KB2656353 已被安装，它包含更新版本的文件。”

这个结果与安全公告显示的“KB2656353 由 KB2604044 替代”完全相反。

笔者认为，出现这种自相矛盾的乌龙问题，要么是 KB2604044 对已安装的 .net Framework 1.1 程序
文件版本检测有问题，要么是 MS12－035 提供了错误的信息。于是笔者仔细查看了 KB2656353 与
KB2604044 的更新发布说明：
 

发现这两个更新升级的 .net Framework 1.1 程序文件的版本完全相同，而且，这两个更新的安装程序
文件大小也完全相同。除了 KB 编号不同，KB2656353 与 KB2604044 没有任何区别。因此，笔者
认为有可能是微软一时粗心大意，忘记了在 2011 年 12 月已经发布过 KB2656353，本月错误地把
KB2656353 改名为 KB2604044，重新发布了一遍，因此闹了这个乌龙。

今天，当笔者再次打开 MS12－035 安全公告时，发现公告的内容已经于 5 月 11 日做了更正。.net
Framework 1.1 的更新编号已经由 KB2604044 改回了 KB2656353，“MS11－100 中的 KB2656353
由 MS12－035 中的 KB2604044 替代”的说明也被改为“MS11－078 中的 KB2572067 由 KB2656353
替代”了。而且，http://support.microsoft.com/kb/2604044 中的下载链接会自动重定向至 KB2656353
下载，微软网站的下载中心也不再提供 KB2604044 了。这些都可以说明，微软在 MS12－035 中
关于 .net Framework 1.1 的更新 KB 编号有误，但微软在发布三天后已经及时发现并更正了错误。
做为普通用户而言，我们只要当作微软本月从来没有发布过 KB2604044，KB2656353 依然是 .net
Framework 1.1 的最新安全更新即可。如果 Windows Update 依然提示需要安装 KB2604044，可以
忽略此提示。
 
 
★ KB2686509 可能会因为缺少特殊的键盘输入法布局文件而安装失败。

本月发布的 MS12－034 中有一个影响 Windows XP/Server 2003 的安全更新 KB2686509：
 
 
据微软中文论坛的很多用户反映，他们在安装此更新时会遇到如下错误：
 
“由于一个或多个要求安装 KB2686509 的先决条件未能满足，安装程序无法继续（0x8007F0F4）”
 
经查这个问题与计算机缺少特殊的键盘输入法布局文件有关。KB2686509 安装程序会枚举计算机中
注册的所有键盘输入法布局文件，然后验证这些文件是否存在于 Windows\system32。如果安装程序
发现 Windows\system32 缺少部分预期的文件，就会引起 KB2686509 安装失败。
 
如果我们遇到了这个问题，首先可以打开注册表编辑器检查一下如下注册表项：
 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layouts
 
通过与其它 Windows XP/Server 2003 计算机的注册表对比，检查一下我们的键盘输入法布局有哪些
特殊的设置。
 
其次我们可以检查一下 Windows 文件夹中的 FaultyKeyboard.LOG 日志文件，这个日志文件记录了
Windows\system32 中缺少的文件列表。我们可以按照这个列表从 Windows XP/Server 2003 安装程序
i386 文件夹提取相应的文件，复制至 Windows\system32，列表显示缺少什么文件就补充什么文件。
这样再次运行 KB2686509 安装程序，即可顺利完成安装。 
发表于 作者 alx-zj | 0 评论
2012年5月5日 20:50

在 Intel H61 芯片组主板的 Windows XP 中配置 AHCI 与 Rapid Storage 驱动

H61 芯片组是 Intel 面向中低端配置计算机的主打芯片组。H61 支持 Sandy Bridge 核心 Intel CPU，
并支持 CPU 整合显示核心技术提供集成显示解决方案。在 4 月 23 日 Intel 发布 Ivy Bridge 之前，
H61 一直是廉价集成显卡商务办公机型的首选芯片组，相应的主板型号有华硕 P8H61 系列、微星
H61M 系列等。
 
虽然笔者一向认为 Windows 系统版本的选择应该与计算机硬件配置挂钩，无论新计算机非要降级为
Windows XP、还是旧计算机非要升级为 Windows 7，都是很容易惹麻烦的不明智行为，但对于很多
企业级应用来说，由于某些特殊应用程序与硬件设备只能在 Windows XP 中运行并找到驱动程序，
所以我们很多时候依然必须为新计算机安装配置 Windows XP 不可。笔者最近就经历了两则为 H61
芯片组主板安装 Windows XP、并为其配置 AHCI 与 Rapid Storage 驱动的实例，特将一些注意事项
总结如下供参考。
 
众所周知，原版的 Windows XP 没有内置 AHCI 控制器驱动。如需在配置有 SATA 硬盘的计算机中
运行 Windows XP，必须通过 Windows XP 安装程序的 F6 菜单提前加载 AHCI 驱动，或者在主板
BIOS 设置中将硬盘模式由 AHCI 模式修改为 IDE 兼容模式，待安装好 Windows XP 后再单独配置
AHCI 驱动，然后通过 BIOS 设置切换回 AHCI 模式。
 
很多 H61 芯片组主板在驱动盘中提供了 Intel Rapid Storage Technology Driver，它是一个针对 Intel
芯片组南桥存储设备的优化驱动包，可以对所有支持的 AHCI、RAID 存储设备进行优化加速。对于
内置有 AHCI 驱动的 Windows 7/Vista 而言，我们可以在安装好 Windows 后直接安装此驱动，没有
任何问题；但对于没有内置 AHCI 驱动的 Windows XP 而言，这个 Intel Rapid Storage Technology
Driver 并不等同于 Windows XP 所需的 AHCI 驱动。如果我们尝试安装此驱动，安装程序将会提示
“此系统不符合安装软件的最低要求”，这个最低要求就是指此驱动无法在 Windows XP 以 IDE 兼容
模式状态运行时安装。此时我们不要试图为了安装此驱动而将 BIOS 设置切换回 AHCI 模式，因为
重新启动后 Windows XP 必然会出现 0x0000007B 蓝屏无法启动。
 
要想顺利令 Windows XP 工作在 AHCI 模式并正确安装 Intel Rapid Storage Technology Driver，我们
依然需要手动为 H61 芯片组单独配置 AHCI 驱动。微星 H61 主板在驱动中提供了一项 Intel Rapid
Storage Technology Floppy Driver（F6），这个 Floppy Driver（F6）才是 Windows XP 所需的 AHCI
驱动。其它品牌的主板可以使用本文结尾附件提供的驱动，将附件的 .ZIP 压缩包中的文件解压缩，
然后在设备管理器中展开 IDE ATA/ATAPI 控制器，选中 Intel (R) 6 Series/C200 Series Chipset Family
4 Port Serial ATA Storage Controller 并手动更新其驱动，选择“不要搜索，在列表中指定”，接下来，
定位到驱动压缩包中的 AHCI\x32\iaAHCI.INF 文件，这时设备管理器将自动读取此 .INF 文件并列出
一长串候选驱动名称，我们选择其中的 Intel(R) Desktop/Workstation/Server Express Chipset SATA
AHCI Controller。在这里千万注意不能选错，否则重新启动计算机后 Windows XP 将肯定无法启动
且无法挽回。接下来，待设备管理器完成 Intel(R) Desktop/Workstation/Server Express Chipset SATA
AHCI Controller 的配置后，我们就可以重新启动计算机，并且在 BIOS 设置中切换回 AHCI 模式了。
当 Windows XP 再次启动后，设备管理器将会检测到新硬件并完成最后的安装步骤，我们也可以在
设备管理器中看到 IDE ATA/ATAPI 控制器已经被刷新为 Intel(R) Desktop/Workstation/Server Express
Chipset SATA AHCI Controller。

现在，我们就可以安装 Intel Rapid Storage Technology Driver 了，此驱动将提供一个完整的 Intel 快速
存储技术（Rapid Storage Technology）控制台，并可显著提升硬盘在 HD Tune、PC Mark Vantage 等
测试工具中的磁盘性能表现。当然，对于运行在 H61 芯片组主板的 Windows XP 而言，这一切必须
建立在首先单独配置 AHCI 驱动的基础之上。
 
发表于 作者 alx-zj | 4 评论
Attachment(s): H61 芯片组主板 AHCI 驱动程序 for Windows XP.ZIP
2012年4月25日 19:50

在 Windows 系统间转移本地组策略设置的基本与进阶方法

所有 NT 核心的非家庭版 Windows 均为我们提供了组策略编辑器（GPEDIT.MSC），方便我们通过组策略
部署系统设置。除了在域环境中可以统一部署域组策略设置之外，如需在非域环境的单机之间将一台计算机
已配置的组策略设置转移至另一台计算机，我们可以通过复制 Windows\system32\GroupPolicy 文件夹的
方式实现。
 
Windows\system32\GroupPolicy 是一个隐含的系统文件夹，在它其中含有 ADM、Machine、User 三个
子文件夹（分别用于保存组策略模板、计算机配置、用户配置）以及 GPT.INI 文件（用于保存组策略设置的
相关配置信息）。根据组策略设置对象类型的差别，不同类型的组策略分别以不同形式保存在 GroupPolicy
文件夹的不同位置。例如，以修改特定注册表项的方式实现功能的组策略，其设置会被记录在 Machine 或
User 中的 Registry.POL 文件里面；以配置脚本的方式实现功能的组策略，其设置会被记录在 Machine 或
User 中的 Scripts 里面，等等。
 
因此，在不同 Windows 系统中转移已配置的组策略设置，可以直接将 Windows\system32\GroupPolicy
包含的配置内容复制转移，覆盖目标计算机中的同名文件夹。但有几点需要注意：
 
1. 版本不同的操作系统支持的组策略设置并不完全相同。较新版的操作系统可能会增加一些新的组策略设置
（通常是伴随着新的系统功能而设），也可能会取消一些不再适用的旧版组策略设置（通常是随着一些系统
组件的取消，例如故障恢复控制台）。因此，当我们在版本不同的操作系统间转移组策略设置时，如果发现
部分设置没有转移，请根据相应策略的说明确认其支持的操作系统版本，每一项设置在组策略编辑器中都会
写明其适用的操作系统版本为“至少 Windows XX Service Pack X”。
 
2. GPT.INI 文件中有一行名为 version 的版本号定义字符串。在转移组策略设置后，我们需要确认转移后的
version 值不小于转移前的 version 值。
 
3. 有些组策略设置在以覆盖 Windows\system32\GroupPolicy 文件夹的方式转移之后可能无法立即生效，
或无法在组策略编辑器中以“已启用”、“未配置”的状态直观表现出来。这时我们需要以管理员权限执行
GPUPDATE /FORCE 命令刷新组策略设置。
 
 
除了以直接复制 Windows\system32\GroupPolicy 文件夹的方式转移组策略设置外，我们还可以下载安装
Microsoft Security Compliance Manager：
 
 
此工具不仅可以通过其工具栏中的“Import GPO”菜单直接导入 Group Policy Management Console 
建立的组策略备份对象，而且还提供有一个可用于转移组策略设置的命令行工具 LocalGPO。LocalGPO 的
安装程序 LocalGPO.MSI 可以在 Security Compliance Manager 的安装目录 Program Files\Microsoft
Security Compliance Manager\LGPO 中找到。用鼠标双击运行 LocalGPO.MSI 执行安装，之后我们即可
以管理员权限打开命令提示符，在命令提示符中使用 LocalGPO 工具。
 
以 LocalGPO 导出组策略设置的命令实例为：
 
LocalGPO.WSF /EXPORT /PATH:C:\Backup\LocalGPO
 
 
其中 C:\Backup\LocalGPO 为我们自行设置的组策略设置导出文件夹路径。执行导出时 LocalGPO 会根据
不同计算机的 SID 生成不同的 SID 后缀。
 
以 LocalGPO 导入组策略设置的命令实例与之相反，只需取消 /EXPORT 参数、依然通过 /PATH 参数指定
需要导入的组策略设置路径，然后写上导出时生成的 SID 后缀即可。LocalGPO 将自动将之前导出的组策略
设置导入计算机，最后我们只需以执行 GPUPDATE /FORCE 命令并重新启动计算机的方式令导入的组策略
设置更新生效即可。
发表于 作者 alx-zj | 0 评论
2012年4月6日 21:45

浅析 Windows 7/Vista 资源管理器为何无法将超过 2GB 大小的文件刻录至光盘

尽管不知道会有多少人使用，Windows 系统从 Windows XP 开始一直为资源管理器整合有光盘刻录功能，
并且在 Windows 7/Vista 中持续进行着功能改进。Windows 7 资源管理器不仅支持常规文件、媒体文件的
鼠标拖拽刻录，也支持 .ISO 光盘镜像的直接刻录。在没有安装任何第三方光盘刻录工具的时候，Windows
资源管理器整合的光盘刻录功能基本可以满足不复杂的光盘刻录任务。

很多人使用 Windows 资源管理器刻录光盘时发现刻录向导无法将大小超过 2GB 的单个文件刻录至光盘，
向导会反复提示必须移除任何超过 2GB 的单个文件才能继续刻录。有人误以为这是 Windows 资源管理器
刻录功能过于简单的局限性所致，其实这道限制来自光盘使用的文件系统，即便使用第三方光盘刻录工具
也存在这一问题。只不过由于 Windows 资源管理器的光盘刻录向导没有向用户明确提及光盘文件系统的
概念，而且 Windows 使用的光盘文件系统名称是微软专用的术语，所以容易造成用户的误解。

光盘使用的文件系统主要有两个。其一是 ISO 9660，也就是 Windows 资源管理器显示的 CDFS，它是由
International Organization for Standardization（ISO）组织专门为光存储设备制定的文件系统，其优点
是兼容性好，可以被 Windows、MS-DOS、Linux、Unix、Mac OS 等多种操作系统，以及影碟机、音响、
随身听等各种光盘播放器支持。但是由于该文件系统的文件长度以 32 位值保存，所以此种文件系统允许的
最大长度为 4GB，这造成文件系统无法访问超过 2GB 的文件。换言之，在 ISO 9660 文件系统的光盘上
任何单个文件大小不能超过 2GB。如果我们插入一张文件系统显示为 CDFS 的 DVD 影碟光盘，可以看到
VIDEO_TS 文件夹中的 .VOB 视频文件都是被拆分为若干个 2GB 文件的，就是因为这个原因。

另一个文件系统是 UDF（Universal Disk Format），它是由 Optical Storage Technology Association
（OSTA）组织制定、用以取代 ISO 9660 的光盘文件系统，其优点是采用标准的封装写入技术，允许用户
像使用硬盘一样对刻录光盘进行修改。该文件系统在进行光盘刻录时会首先打包数据，并在内存中建立临时
文件目录表，接管系统对光盘的访问。UDF 文件系统不存在 2GB 单个文件的限制，广泛应用于 DVD 以及
蓝光光盘。Windows 7/Vista 安装光盘均采用 UDF 文件系统，以储存超过 2GB 的 Sources\Install.WIM
安装镜像文件。UDF 文件系统也具有较好的兼容性，Windows 2000 以上版本的操作系统均可支持。
 
由此可见，为了成功地将大小超过 2GB 的单个文件刻录至光盘，我们应该选择 UDF 文件系统。在 Nero、
UltroISO 等光盘工具中刻录光盘或者建立 .ISO 光盘镜像时，我们需要首先在这些工具中选择 UDF 模式，
才可以顺利写入大小超过 2GB 的单个文件。
 
下面我们回到 Windows 资源管理器的光盘刻录向导。Windows 7/Vista 并没有在向导中明确提及 UDF 与
ISO 9660，而是使用了一套微软专用术语 Live File System 与 Mastered Format。如果我们在 Windows
Vista 资源管理器中打开光盘刻录向导，在“准备光盘”向导对话框中即可看到两种光盘文件系统的选项。
为了刻录大小超过 2GB 的单个文件，我们应该选择 Live File System，也就是 UDF。Windows Vista 在
默认的系统设置中也是以 Live File System 做为默认光盘文件系统的。
 
 
Windows 7 的“准备光盘”向导对话框则使用了更通俗易懂的选项术语“类似于 USB 闪存驱动器”与
“带有 CD/DVD 播放器”，实际依然是指 UDF 与 ISO 9660，换汤不换药。为了刻录大小超过 2GB 的
单个文件，我们应该选择前者。

发表于 作者 alx-zj | 0 评论
2012年3月28日 16:00

安装手机驱动引起的 Kernel Mode Driver 错误可能导致添加删除程序 DEP 失败

笔者上周在微软中文技术论坛里先后见到四位用户遇到了在安装手机驱动程序及 Android 手机软件
《豌豆荚》后引起 Windows 控制面板的“添加删除程序”组件无法启动的问题。具体故障表现为运行
“添加删除程序”后出现 RunDLL32（Run a DLL as an App）遇到问题、需要关闭，或者 RunDLL32
（Run a DLL as an APP）被数据执行保护（DEP）强制关闭的提示，无法看到预期的程序列表。

按照常规的故障排除思路，“添加删除程序”组件无法启动可能是相关的 Windows 系统文件丢失损坏
或缺少注册，或者是 DEP 数据执行保护错误地将 RunDLL32 添加进了排除列表所致。但是在论坛
四位用户的问题中，他们可以通过 SFC /SCANNOW 检测确认 Windows 系统文件没有丢失或损坏、
可以通过执行 REGSVR32 确认相关系统文件正确注册、可以通过修改 DEP 列表或在硬件层面关闭
DEP 的方式确认 DEP 数据执行保护没有问题。在排除了这些因素后，故障原因被缩小至安装手机
驱动时配置的 Kernel Mode Driver 上面。

部分手机驱动程序及 Android 手机软件《豌豆荚》在安装过程中会自动更新一个名为 WDF01005 的
Kernel Mode Driver，它的全称是 Microsoft Kernel-Mode Driver Framework Feature Pack 1.5，安装之后
将在 Windows\system32\driver 中生成驱动文件 WDF01005.SYS。然而，也许是存在驱动版本冲突的
问题，部分手机驱动程序或《豌豆荚》捆绑的 WDF01005 安装程序文件 SFXCAB.EXE 会在注册表项
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\WDF01005 中写入
不正确的信息，该注册表项会引起“添加删除程序”读取程序列表时运行出错，或被 DEP 强制关闭。

因此，如果我们在安装手机驱动程序或《豌豆荚》后遇到“添加删除程序”无法启动的问题，可以检查
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\WDF01005 的内容
与常规 Windows 系统是否有出入。在默认的系统设置中，这个注册表项只需保存一个 DWORD 值
SystemComponent =1 即可。经过实际测试，很多遇到此类问题的人在清理 WDF01005 中不正确的
注册表项后，“添加删除程序”无法启动的问题均可解决。虽然导致此问题的具体原因还不是很清楚，
但可以先使用这个方法解决问题。如果哪位朋友对这个问题有进一步的研究，还望不吝指教。
发表于 作者 alx-zj | 2 评论
2012年2月20日 4:00

自定义 .MSC 模板令事件查看器始终应用特定的筛选

笔者上周在微软中文论坛见到这样一则问题：当我们在“管理工具”中打开“事件查看器”后，事件查看器
默认会显示日志中所有可供显示的事件。如果我们只需要查看其中符合某种指定条件的特定事件，可以通过
事件查看器菜单栏中的“查看”－“筛选”设置条件。问题是，我们设置的筛选仅对当前事件查看器有效。
若我们关闭事件查看器再重新启动，事件查看器依然会默认显示所有事件。假如我们需要长期对一特定事件
跟踪观察，能不能令事件查看器每次启动时均自动应用指定的筛选呢？
 
事件查看器之所以每次启动都默认显示所有事件，是因为我们每次都是通过“管理工具”的“事件查看器”
模板（Windows\system32\EVENTVWR.MSC）启动事件查看器的。Windows 提供的此默认模板不包含
任何筛选。如果我们建立一个自定义的事件查看器 MSC 模板，令其包含筛选，那么只需每次通过自定义的
MSC 模板启动事件查看器，即可令其自动应用筛选。不止事件查看器，任何通过 MMC 控制台加载的组件
（例如设备管理器）均可以通过自定义 MSC 模板自动应用特定的设置。
 
下面笔者举一个具体的实例：假设计算机遇到了未知硬件故障，在系统日志中经常出现 ID：12 的硬件设备
异常消失事件，需要在设备管理器中选择“显示隐藏的设备”配合进行排查。为了避免每次启动事件查看器
都要自定义 ID：12 的筛选、以及每次启动设备管理器都要重新选择“显示隐藏的设备”，我们可以把它们
做成一个自定义的 MSC 模板。
 
1. 运行 Windows\system32\MMC.EXE 启动控制台程序；
 
2. 选择“文件”－“添加/删除管理单元”，在“控制台根节点”处点击“添加”，选择“事件查看器”，
设置管理对象为“本地计算机”；
 
3. 此时事件查看器将被加载于 MMC 控制台，选择具体事件类别后，通过菜单栏中的“查看”－“筛选”
设置筛选条件，将事件 ID 设置为 12；
 
4. 选择“文件”－“添加/删除管理单元”，在“控制台根节点”处点击“添加”，选择“设备管理器”，
设置管理对象为“本地计算机”；
 
5. 此时设备管理器也将被加载于 MMC 控制台，通过菜单栏中的“查看”选择“显示隐藏的设备”；
 
6. 关闭 MMC 控制台，这时控制台会询问是否将当前控制台设置保存，选择“是”，然后为自定义的
MSC 模板设置文件名及路径，在此假设将其保存为“管理工具\控制台1.MSC”。
 
这样，我们将在“管理工具”中看到一个自定义的“控制台1.MSC”模板。今后只需运行“控制台1.MSC”
即可同时启动应用了 ID：12 筛选的事件查看器以及选择了“显示隐藏的设备”的设备管理器。这样一来，
跟踪事件 ID：12 的事件并排查硬件设备异常消失的故障就方便多了。 
发表于 作者 alx-zj | 2 评论
2012年2月10日 17:10

浅析 Windows 7 在何种情况始终以分离的 Explorer.EXE 进程显示多个窗口

Windows 从早期版本开始就在文件夹选项的“查看”选项卡中提供了“在单独的进程中打开文件夹窗口”
复选框。如果我们勾选此复选框，当我们同时打开多个文件夹窗口时，将在任务管理器的“进程”选项卡
看到若干个不同的 Explorer.EXE 进程同时运行；如果我们不勾选此复选框，则无论我们同时打开多少个
文件夹窗口，任务管理器的“进程”选项卡都始终显示一个 Explorer.EXE 进程。
 
Windows 7 文件夹选项中的“在单独的进程中打开文件夹窗口”继承了早期版本 Windows 的这一特性。
但是，如果我们在打开文件夹窗口时指定了目标起始位置，那么即使“在单独的进程中打开文件夹窗口”
复选框没有被勾选，任务管理器也将始终显示多个不同的 Explorer.EXE 进程。示例步骤如下：
 
1. 在文件夹选项的“查看”选项卡取消“在单独的进程中打开文件夹窗口”复选框；
2. 在命令提示符中执行 Explorer.EXE C: 命令；
3. 打开新的 C: 窗口后，我们可以在任务管理器中看到两个不同的 Explorer.EXE 进程同时运行。
 
 
其中一个 Explorer.EXE 进程是 Windows Shell。而另一个 Explorer.EXE 进程，如果我们在任务管理器的
“显示列”设置中勾选“命令行”，可以看到其“命令行”显示为：
 
C:\Windows\Explorer.EXE /Factory,{75dff2b7-6936-4c06-a8bb-676a7b00b24b} -Embedding
 
{75dff2b7-6936-4c06-a8bb-676a7b00b24b} 含义为 CLSID_SeparateMultipleProcessExplorerHost，
即分离 Explorer.EXE 进程。换言之，当我们以 Explorer.EXE C: 命令行方式指定了文件夹窗口的目标起始
位置时，Windows 7 将始终以分离的 Explorer.EXE 进程显示 C: 窗口，即使在没有勾选“在单独的进程中
打开文件夹窗口”复选框时也不例外。这是 Windows 7 设计使然。
 
除了通过命令行方式运行 Explorer.EXE C: 指定文件夹窗口的目标起始位置以外，如果我们将资源管理器的
快捷方式锁定于 Windows 7 任务栏，然后右键单击快捷方式的属性，将“起始位置”设置为 C:，在点击
这个快捷方式启动文件夹窗口时，也相当于用命令行方式运行了 Explorer.EXE C:，此时 Windows 7 也将
始终以分离的 Explorer.EXE 进程打开 C: 窗口。
 
当然，上述现象并不意味着 Windows 7 的“在单独的进程中打开文件夹窗口”复选框形同虚设。只要我们
在启动资源管理器时不通过命令行或快捷方式指定文件夹窗口的目标起始位置，那么 Windows 7 就不会在
“在单独的进程中打开文件夹窗口”复选框未选中时以分离的 Explorer.EXE 进程打开文件夹窗口。例如，
假设我们是通过点击开始菜单中的“计算机”图标打开资源管理器的，那么只有在选中“在单独的进程中
打开文件夹窗口”复选框的时候才会有多个不同的 Explorer.EXE 进程同时运行；若不选中此复选框则始终
只有一个 Explorer.EXE 进程运行。这与早期版本的 Windows 并无区别。
发表于 作者 alx-zj | 6 评论
2012年1月20日 3:00

从 Windows Driver Kit 中获取适用于 Windows 7 的 DEVCON

DEVCON 是一款非图形化用户界面的硬件设备与驱动程序管理工具。它可以通过命令行的形式实现
Windows 设备管理器的功能，适用于以编写脚本的方式、及以 Server Core 方式安装的 Windows
Server 2008（R2）系统管理硬件设备。
 
微软官方网站提供的 DEVCON 工具介绍及下载地址为：
 
 
这个地址发布的日期比较早，其提供的 DEVCON.EXE 文件版本号为 5.2.3718.0，支持的系统类型仅包括
Windows 2000/XP/Server 2003。虽然这个早期版本的 DEVCON 经测试也可以在 Windows 7 中运行，
但难保不会出现兼容性问题（虽然笔者截至目前在使用中还未发现）。因此，我们可以从 2010 年发布的
Windows Driver Kit v7.10 中获取更新版本的 DEVCON，在 Windows 7 中使用。
 
1. 从微软官方网站下载 Windows Driver Kit v7.10，这是一个 .ISO 镜像文件：
 
 
2. 使用任意 ISO 光盘镜像工具打开下载的 .ISO 文件，或者使用任意虚拟光驱工具将其映射为光盘驱动器。
 
3. 在 \WDK 文件夹中，我们可以找到下列文件：
 
SETUPTOOLS_IA64FRE.MSI 以及 SETUPTOOLS_IA64FRE_CAB001.CAB，适用于 ia64 安腾系统；
SETUPTOOLS_X64FRE.MSI 以及 SETUPTOOLS_X64FRE_CAB001.CAB，适用于 64 位系统；
SETUPTOOLS_X86FRE.MSI 以及 SETUPTOOLS_X86FRE_CAB001.CAB，适用于 32 位系统。
 
4. 我们可以根据自己的系统类型，提取相应版本的安装文件，运行 .MSI 文件执行安装（注意配套的 .CAB
文件不可少，为安装所需）。安装过程很简单，甚至没有任何确认提示。安装后我们可以找到文件夹：
 
C:\WinDDK\7600.16385.win7_wdk.100208-1538\tools\devcon
 
在此存在三个子文件夹 ia64、amd64、x86，分别包含适用于三种系统的 DEVCON.EXE 文件，版本号为
6.1.7600.16385。这就是适用于 Windows 7 的新版 DEVCON 工具。
发表于 作者 alx-zj | 0 评论
2012年1月10日 5:40

Windows 7/Vista 桌面上为何有两个隐含的 Desktop.INI

笔者今天在微软中文论坛看到有人又问起一个不算新问题的问题：当我们通过 Windows 7/Vista 的文件夹
选项设置允许显示隐含的文件后，会在 Windows 7/Vista 桌面上看到两个同名的 Desktop.INI 隐含文件；
而在 Windows XP 中允许显示隐含的文件却没有此问题。这是为什么呢？

虽然 Windows 不允许在一个文件夹中同时存在两个同名的文件，但我们知道“桌面”不是普通的文件夹。
在默认的 Windows 系统设置中，桌面上显示的图标不仅来自于当前用户帐户专有的“桌面”配置文件夹，
也来自于所有用户帐户共有的“公共桌面”配置文件夹。前者提供的图标仅在当前用户帐户的桌面上显示；
后者提供的图标在所有用户帐户的桌面上显示。由于这两个“桌面”配置文件夹都有自己的 Desktop.INI，
所以当我们允许显示隐含的文件时，两个 Desktop.INI 都将出现在桌面上。

具体地说，桌面上的第一个 Desktop.INI 来自于当前用户帐户专有的“桌面”配置文件夹，
具体路径是 Users\%用户帐户名%\Desktop。文件内容为：

[.ShellClassInfo]
LocalizedResourceName=@%SystemRoot%\system32\shell32.dll,-21769
IconResource=%SystemRoot%\system32\imageres.dll,-183

第二个 Desktop.INI 来自于所有用户帐户共有的“公共桌面”配置文件夹，
具体路径是 Users\Public\Desktop。文件内容为：

[.ShellClassInfo]
LocalizedResourceName=@%SystemRoot%\system32\shell32.dll,-21799
 
两者的差别仅在于前者多了一行指定文件夹图标的语句。
 
 
Windows XP 不存在桌面上显示两个 Desktop.INI 隐含文件的问题是因为 Windows XP 的“桌面”配置
文件夹默认没有设置 Desktop.INI。但 Windows XP 桌面也是由“桌面”、“公共桌面”两部分组成的。
如果我们分别手动复制两个 Desktop.INI 隐含文件到 Documents & Settings\%用户帐户名%\Desktop
与 Documents & Settings\All Users\Desktop，然后设置允许显示隐含的文件，也能在 Windows XP 中
重现 Windows 7/Vista 桌面上显示两个 Desktop.INI 的问题。
 
总之，Windows 7/Vista 在设置允许显示隐含的文件后，在桌面上出现两个同名的 Desktop.INI 隐含文件
是正常现象，两个 Desktop.INI 并非是恶意程序仿冒或磁盘错误等原因引起。
发表于 作者 alx-zj | 3 评论
2011年12月24日 23:45

在非 Windows 7 中使用任务栏右下角的显示桌面及 Aero Peek 功能

众所周知，Windows 7 将早期版本 Windows 快速启动工具栏中的“显示桌面”位置进行了较大的调整，
在 Windows 7 超级任务栏的右下角有一个专门的“显示桌面”按钮。用鼠标点击这个按钮可以将所有的
应用程序窗口最小化、将鼠标箭头悬停于这个按钮可以使用 Aero Peek 透视功能预览应用程序窗口。

笔者最近发现一个第三方开发的绿色小程序，可以近乎完美地将任务栏右下角的“显示桌面”按钮及 Aero
Peek 功能移植到 Windows XP/Vista 中使用。这个小程序只有一个 .EXE 可执行文件，可以从本文结尾的
附件处下载。运行这个 .EXE 文件使其进程常驻于内存，即可在 Windows XP/Vista 任务栏右下角看到一个
类似于 Windows 7 的显示桌面按钮，并可以通过鼠标箭头悬停的方式使用 Aero Peek，示意图如下。


这个小程序提供的任务栏按钮的默认宽度为 15 个像素，这是根据 Windows 7 超级任务栏的尺寸而设置的
默认宽度。但我们知道 Windows XP/Vista 任务栏的尺寸只有 Windows 7 超级任务栏的 3/4，默认宽度
15 像素的按钮显然太大了，它会部分遮挡任务栏通知区域的时钟，因此按钮宽度需要缩短一些。我们可以
将鼠标箭头悬停于按钮，当 Aero Peek 出现并且按钮上方显示“Show Desktop”字样时右键单击，然后
在右键菜单中选择“Settings”打开程序选项，将“Width（宽度）”减小一些。在上面的示意图中，笔者
设置的按钮宽度是 8 像素，个人认为这是比较适合 Windows XP/Vista 任务栏的按钮宽度。

另外在“Settings”选项中，我们还可以设置为任务栏按钮以及 Aero Peek 透视的应用程序预览窗口设置
“Opacity（不透明度）”；可以设置“Exclusion（例外）”令指定的应用程序不受最小化影响；还可以
设置“Show SplashScreen（显示启动画面）”。如果我们取消“Show SplashScreen”选项令其不显示
启动画面，并且再手动将这个小程序添加至注册表项 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\
Windows\CurrentVersion\Run 令其自动运行，就可以在每次启动 Windows XP/Vista 后直接使用它了，
甚至感觉不到这是一款第三方程序。

经笔者试用，这款小程序模仿 Windows 7 的仿真度极高，资源占用很小。而且它还支持在 Windows 经典
主题中显示按钮，不像 Windows 7 自带的功能在切换至经典主题时右下角显示不出按钮，只有一个“显示
桌面”图标。笔者已经把自己在虚拟机中安装的所有 Windows XP/Server 2003/Vista/Server 2008 系统
都添加了这个小程序，强烈推荐。
发表于 作者 alx-zj | 3 评论
Attachment(s): ShowDesktop & Aero Peek 绿色小程序.ZIP
2011年12月15日 18:40

设置 IE for Windows Server 不再 ESC

IE ESC 是 Internet Explorer Enhanced Security Configuration 的英文缩写。它是 Windows Server
操作系统为降低服务器遭到 Web 页脚本及活动程序的攻击而设置的 IE 增强型安全配置。在 Windows
Server 2003（R2）/Server 2008（R2）系统中，IE ESC 默认处于开启状态。当我们试图像 Windows
Client 客户端系统那样用 IE 访问 Web 页时，每次均会遇到 Web 页内容被 IE ESC 屏蔽的提示，俗称
“IE 逃跑（Escape）了”。
 
IE ESC 虽然不是什么新功能，但微软中文论坛中还是有很多用户不了解如何设置 IE ESC，以便可以在
Windows Server 中正常浏览 Web 页。特别是 Windows Server 2008（R2）的 IE ESC 设置方法与
Windows Server 2003（R2）相比有了较大的改变。笔者在此做一小结。
 
 
IE ESC 的基本原理是将 Internet 安全级别中的“Internet”、“受限站点”默认设置为最高。在 Windows
Client 客户端系统中，“Internet”的级别默认不是最高的，“受限站点”的级别也是可以自定义的；而在
开启了 IE ESC 的 Windows Server 系统中，这两个安全级别始终是最高且无法随意降低。因此，如果我们
确实需要在 Windows Server 中访问 Web 页或 Intranet 站点，必须根据 IE ESC 的提示将它们手动添加
至“可信任站点”或“本地 Intranet”级别。所有来自 Internet 的 Web 页及网站全隶属于“Internet”，
要想正常访问必须将它们手动添加至“可信任站点”；所有 Intranet 站点默认也全都隶属于“Internet”，
而不是我们想当然的“本地 Intranet”，要想正常访问也必须将它们手动添加至“本地 Intranet”。
 
此外，IE ESC 除了默认将“Internet”、“受限站点”的安全级别设置为最高，还将 Internet 选项“高级”
选项卡中的部分设置调整为与 Windows Client 的默认设置相左的状态。在开启 IE ESC 时，默认处于禁用
状态的设置有：1.启用第三方浏览器扩展、2.在网页中播放声音、3.在网页中播放动画、4.启用内存保护以
帮助减少联机攻击；默认处于启用状态的设置有：1.关闭浏览器时清空 Internet 临时文件夹、2.不将加密的
页存盘、3.检查服务器证书吊销、4.在安全与非安全模式之间转换时发出警告。这些与 Windows Client 的
默认设置相左的选项均可能会影响正常的 Web 页浏览。
 
总之，在 Windows Server 开启 IE ESC 的时候，如果我们可以将需要访问的 Web 页、网站或 Intranet
站点添加至“可信任站点”、“本地 Intranet”级别，将 Internet 选项“高级”选项卡中的设置调整为与
Windows Client 相同，忽略来自 IE ESC 的所有提示，便可以像在 Windows Client 中一样正常使用 IE。
反之，假如在 Windows Client 中将上述设置参照 IE ESC 进行调整，也可以实现类似的屏蔽效果。
 
假如我们的 Windows Server 操作系统并非用于服务器，那么可以彻底关闭 IE ESC：
 
Windows Server 2003（R2）可以在控制面板中打开“添加/删除程序”，选择“添加/删除 Windows
组件”，在 Windows 的组件列表中选择“Internet Explorer 增强的安全配置”并点击“详细信息”，
然后取消面向“管理员组”或“所有其它用户组”的 IE ESC 选项即可。
 
Windows Server 2008（R2）则不是通过控制面板中的“打开或关闭 Windows 功能”设置 IE ESC，
而是将 IE ESC 的选项调整到了管理工具中“服务器管理器”里，在这个页面中展开“安全信息”并
点击“配置 IE ESC”，然后针对“管理员”或“用户”设置 IE ESC 为“禁用”即可。
发表于 作者 alx-zj | 0 评论
2011年11月30日 6:50

使用 Program Install & Uninstall Fixit 工具清理受损的 Windows\Installer

很多人都曾在手动清理 Windows 系统分区时经历过误删除 Windows\Installer 文件夹的梦魇。Windows\
Installer 保存着所有基于 Windows Installer 安装的应用程序的组件信息。如果 Windows\Installer 中的
数据被误删除，所有基于 Windows Installer 安装的应用程序都会全盘大乱，具体表现为应用程序无法正常
显示图标、无法正常启动、运行时出现找不到组件的错误、无法通过控制面板以常规方式完成卸载，等等。

由于这个问题与 Windows 自身关系不大，所以我们无法通过修复 Windows 安装或执行 SFC /SCANNOW
恢复 Windows\Installer 中被误删除的数据。解决这个问题通常只能手动清理所有残留在系统中的应用程序
文件及注册信息，然后再重新安装受到影响的应用程序。以 Office 为例，当我们误删除 Windows\Installer
里面的数据后，开始菜单 Microsoft Office 文件夹中的快捷方式将丢失图标、部分 Office 组件将无法启动
（在启动时可能会自动运行安装程序修复配置、但无法完成）、部分 Office 组件在运行时将出错、无论通过
控制面板还是直接运行 Office 安装程序试图对 Office 进行修复或卸载，安装配置过程都将以失败而告终。
此时我们只能手动删除 Office 安装文件夹、然后在注册表中将诸如 HKEY_LOCAL_MACHINE\SOFTWARE\
Microsoft\Office 之类的所有与 Office 相关的注册表项删除，直到 Windows 认为 Office 已彻底不存在，
才能重新安装 Office。

这样的修复方法不仅繁琐工作量大，而且我们很难准确地确定应该手动清理哪些残留的文件及注册表项才能
令 Windows 认为相应应用程序已不存在。当计算机中安装有很多基于 Windows Installer 的应用程序时，
误删除 Windows\Installer 中的数据造成的应用程序混乱足以令人抓狂。为了有效地解决这样的问题，微软
为我们提供了一款叫做 Program Install & Uninstall 的 Fixit 工具：

http://support.microsoft.com/mats/Program_Install_and_Uninstall

此工具可以点击上述链接中的“立即运行”按钮运行、也可以展开“要在其它或断开的计算机上运行的高级
下载功能”，然后点击“下载”按钮，将完整的 Fixit 便携版工具下载至本地或可移动存储器保存。

Fixit 便携版工具可以无需安装直接运行，它提供了一系列免费的 Fixit 工具集用来处理各种常见的 Windows
系统故障，是一款非常有用的便携式工具。我们可以在 Fixit 便携版工具的主界面中选择“所有问题范围”，
然后在其提供的全部二十个工具中找到倒数第二个“自动诊断和修复程序安装和卸载问题”，点击它旁边的
“立即运行”按钮，启动 Program Install & Uninstall Fixit 工具，此工具将自动检测清理因为 Windows\
Installer 中的数据被误删除引起的已经失效的、残留的应用程序信息。经过此工具处理后，我们就可以重新
安装那些受到影响的基于 Windows Installer 的应用程序了。
发表于 作者 alx-zj | 2 评论
2011年11月1日 0:50

介绍一下新西兰的微软 MVP

上周在微软奥克兰的 Office 有一次新西兰地区 MVP Gathering。笔者也跑去凑了个热闹，与参会的近十位
新西兰 MVP、ANZ MVP Lead 以及部分奥克兰微软 Office Staff 进行了面对面交流，互相分享了各自对于
MVP 项目及 Windows 8、Windows Phone 等热门微软产品技术的看法。
 
 
微软新西兰的 Office 位于奥克兰市 No.22 Viaduct Harbour Avenue，这附近就是橄榄球世界杯期间球迷
聚集在一起通过大屏幕看球狂欢的 Waterfront Rugby Fan Zone，笔者一周前刚在这里见证了新西兰主场
8：7 险胜法国夺得橄榄球世界杯冠军。奥克兰微软 Office 很小，与 HP 惠普的 Office 同在 No.22 一栋
写字楼里，各自占一个楼层。
 
 
照片中间这位美女名叫 Roseanne Stamell，她是澳大利亚、新西兰两国的 MVP Lead，也就是南半球整个
ANZ 地区的 Sisley。
 
据 Rose 介绍，目前澳大利亚 MVP 人数过百；新西兰一共只有不到二十位 MVP（有一位女士），其中九位
MVP 在奥克兰。另外，在 Office Staff 中也有以前曾经的 MVP、现在已经加入微软。
 
Gathering 只有短短两个小时加一个 Morning Tea。不过参会的所有人均表现了积极的热情与友善，其中
还有来自饱受多番地震袭击的基督城、在地震中没少受罪的 MVP，依然一大早就搭飞机赶到了奥克兰参加
本次 Gathering。笔者也代表中国的 MVP 向所有人表达了致意。
 
稍显遗憾的是 Viaduct Harbour 停车场最多只给停两个小时，有几位老兄担心车被拖走提前离开，合影时
只剩下九个人了。哪位 MVP 兄弟计划参加明年的 Global Summit，到时看看能不能找到这几位的身影。
 
发表于 作者 alx-zj | 2 评论
2011年10月10日 11:10

已安装 SP1 的 Office 2010 依然被 Update 提示需要下载安装 SP1 的案例分析

笔者最近在微软中文技术论坛里看到一则已安装有 SP1 的 Office 2010 依然被 Update 提示需要下载安装
SP1 的案例。笔者认为此问题具有一定代表性，故将论坛的参考解决方法总结供大家参考。如果我们也遇到
Office 2010 已经安装 SP1、但 Update 依然提示 Office 2010 需要下载安装 SP1 的问题，可以参考如下
解决方法。
 
★ 确定 Update 的提示是否属于误报。
 
由于这个问题有可能是 Update 组件自身的混乱引起的，所以我们必须首先确认 Office 2010 已安装的 SP1
是否正确，Update 的提示是否属于误报。确认的方法很简单：启动任意 Office 组件，在“关于”对话框中
检查组件的版本号是否显示“SP1 MSO”字样即可。
 
★ KB2510690 不等同于 KB2460049。
 
接下来我们需要检查 Update 提示我们下载安装的 SP1 更新编号是 KB2510690 还是 KB2460049，这两个
编号代表的更新含义是不同的。
 
根据微软官方对 KB2510690 的说明：
 
 
KB2510690 是所有 Office 2010 组件的 SP1 更新的总集。这个总集不止包含 Office 2010 常规组件（例如
Word、Excel、PowerPoint 等）的 SP1 更新，也包括 SharePoint、Project、Visio、Proofing Tools Kit
以及 Language Pack 等所有组件的 SP1 更新。换言之，KB2510690 包含整个 Office 2010 产品家族全部
组件的 SP1 更新，这个更新列表可以在 http://support.microsoft.com/kb/2510690 中查询，所有组件的
SP1 更新均有 x86、x64 两种版本。
 
KB2460049 则是针对 Office 2010 常规组件（Word、Excel、PowerPoint 等）的 SP1 更新，它不适用于
任何其它需要单独安装的 Office 2010 组件（SharePoint、Project 等）。换言之，KB2460049 可以看作
KB2510690 的一个组成部分。如果我们只安装有 Office 2010 常规组件，那么只需下载安装 KB2460049
即可完成 SP1 的升级；如果我们除 Office 2010 常规组件外还安装有任何其它需要单独安装的 Office 2010
组件，则还需要在 KB2510690 中单独查找针对这些组件的 SP1 更新一并进行升级。例如，假设我们安装有
SharePoint Designer 2010，它的 SP1 更新编号为 KB2460057；假设我们安装有 Visio 2010，它的 SP1
更新编号为 KB2460061。这些更新都要单独安装。无论是 KB2460057、KB2460061 还是 KB2460049，
它们都是 KB2510690 总集的组成部分。
 
正因 KB2510690 是所有 Office 2010 组件的 SP1 更新总集，我们必须确认 Update 提示需要下载安装的
SP1 更新编号是 KB2510690 还是 KB2460049。例如，假设我们不仅安装了 Office 2010 常规组件、而且
安装了 SharePoint、Visio 等其它组件，当 Update 提示我们需要下载安装 KB2510690 时，我们必须确认
所有这些 Office 2010 组件是否都已正确升级至 SP1，因为我们有可能只为 Office 2010 的常规组件安装了
KB2460049，但却忽略了其它 Office 2010 组件的更新，这时 Update 提示我们需要下载安装 KB2510690
就不属于误报。再举一例，假设我们只安装有 Office 2010 的常规组件，当 Update 提示我们需要下载安装
KB2510690 时，我们就只需确认是否已正确安装 KB2460049 就可以了。
 
★ 屏蔽误报的 SP1 更新。
 
通常 Update 提供的信息基本是正确可信的。除非我们可以确认已安装的所有 Office 2010 产品家族组件的
“关于”对话框均已显示“SP1 MSO”字样、但 Update 却依然提示需要下载安装 SP1，才属于 Update
误报。通常这种问题发生的概率不高。假如我们确实遇到这种 Update 误报的问题，只要在 Update 提示的
组件列表中右键单击“SP1（KB2510690）”，选择“隐藏此更新”即可，这样 Update 就不会再提示我们
下载安装了。
 
★ 修复引起误报的 Update 组件及临时文件夹。
 
Update 的误报一般是由于 Update 组件或其使用的临时文件夹有所损坏所致。如果我们确实遇到 Update
误报的问题，可以参考下列方法尝试对其修复。
 
1. 下载运行 Fixit 50202 工具修复 Update 组件：
 
 
运行 Fixit 50202 工具后，在其向导中选中“攻击性选项（Aggressive Option）”复选框，以强制修复
Update 组件，然后重新启动 Windows。
 
2. 清理 SoftwareDistribution 临时文件夹：
 
我们可以首先关闭系统服务 Automatic Updates，然后以清空或重新命名的方法手动清理一下 Windows\
SoftwareDistribution 的 DataStore 及 Download 临时文件夹，再重新启动 Automatic Updates 服务。
这样可以重置 Update 更新下载缓存。如果 Update 误报的问题是因为 SoftwareDistribution 临时文件夹
混乱引起的，重置 DataStore 及 Download 临时文件夹可以修复包括 Office 2010 SP1 更新及 Windows
更新在内的所有 Update 误报问题。
发表于 作者 alx-zj | 0 评论
2011年10月1日 19:00

Debugging Tools for Windows v6.12 安装方式的改变

笔者以前曾经撰写过博文《蓝屏死机不用愁 －借助 Debugging Tools 分析蓝屏故障原因》以及
《易宝典 KB972602 －Windows 常见蓝屏故障分析》，介绍了如何在 Windows 中设置自动保存
Crash Dump File，以便在遇到蓝屏故障时使用 Debugging Tools 分析故障原因的方法。
 
笔者上周在微软中文技术论坛见到有人问起如何下载安装最新版的 Debugging Tools。因为从 v6.12 版本
开始，Debugging Tools 已经做为一个组件被整合在 Windows Software Development Kit（Windows
SDK）的安装程序里。
 
以前我们安装 Debugging Tools v6.11 或更早的版本时，可以在如下地址直接获取 Debugging Tools 的
安装程序：
 
 
从 v6.12 开始，我们点击这个链接后会被自动重定向至：
 
 
提示我们下载包含有 Debugging Tools v6.12 的 Windows SDK v7.1 在线版安装程序：
 
 
Windows SDK 提供了一系列供开发人员使用的工具、编译器、标头、资源库、代码样本及用户帮助文档。
如果我们无需开发、只需要 Debugging Tools，可以在下载运行 Windows SDK v7.1 在线版安装程序后，
在安装组件列表中只选择 Debugging Tools，其它什么也不选。这样不仅可以节省在线安装的下载时间、
也可以避免安装不需要的开发工具占用硬盘空间。
 
我们可以在 Windows SDK v7.1 安装程序组件列表的两个分支看到 Debugging Tools 安装选项。第一个
是 Common Utilities 分支下的 Debugging Tools for Windows；第二个是 Redistributable Packages
分支下的 Debugging Tools。选择前者可以令安装程序检测 CPU 硬件类型并自动下载对应 Debugging
Tools 的 x86、x64 或 Itanium 版；选择后者则可以令安装程序下载 Debugging Tools 的 x86、x64 及
Itanium 全部三个版本。
 
安装完毕后，我们即可通过开始菜单中自动生成的 Debugging Tools v6.12 快捷方式启动 WinDBG.EXE。
假如我们之前安装过 Debugging Tools v6.11 或更早的版本，Windows SDK v7.1 安装程序也可以将其
自动升级为 Debugging Tools v6.12 版。
发表于 作者 alx-zj | 0 评论
更多内容 下一页 »