[新闻稿存档 ^] [< 第 1 卷第 1 号] [第 1 卷第 3 号 >]
Systems Internals 通讯第 1 卷，第 2 号
1999 年 5 月 15 日 - 本期内容：
SYSTEMS INTERNALS 新内容
- SDelete
- 蓝屏屏幕保护程序 Win2K 更新
- “Linux 和 Enterprise 版”
- “NT 实用工具内部”
- 我的五月 Windows NT 杂志专栏
- 旧事重提
INTERNALS 新闻
- GUI 博士可怜的床边礼仪
- WinDev '99 East
- Numega Driver Works 即将发布
- Beta 3 DDK 已发布
- Win2K 排队的旋转锁
即将推出
- Win2K 系统文件保护程序 (SFP)
赞助商：WINTERNALS SOFTWARE
Systems Internals 通讯由 Winternals Software 赞助，网址为 http://www.winternals.com. Winternals Software 是 Windows NT/2K 高级系统工具的领先开发者和提供商。 Winternals Software 产品包括适用于 Windows NT 4.0 的 FAT32、ERD Commander（Windows NT 的启动磁盘功能）以及 NTRecover。
大家好，
欢迎阅读 Systems Internals 通讯第二版。 本通讯目前有 2700 名订阅者，而且订阅量仍在强劲增长。
自上期通讯发布后，Microsoft 已正式发布 Windows 2000 Beta 3。 Beta 3 内核的内部版本号为 2031，NT 4.0 的初始版本内核的内部版本号为 1381，NT 3.51 的内部版本号为 1025。 。 我觉得奇怪（也有点烦人）的是，Microsoft 每次对操作系统进行完整构建时（每个工作日）都会增加内部版本号，然而，报告的内核内部版本号反映了其首次公开发布时的版本号。 例如，即使 NT 4.0 Service Pack 5 内核的实际内部版本号远高于 1381，内核仍将 1381 报告为内部版本号。
Windows 2000 的 Beta 3 版本旨在成为开发人员社区的警钟。 Microsoft 已宣布将在 10 月发布 Windows 2000，Beta 3 代表将要交付的功能完整版本，因此开发人员可以开始编写新产品，而不必担心它们下面的内容会发生变化。
Windows 2000 附带了大量新的 API、分层服务和内核增强功能。 设备驱动程序开发人员感知特别明显的一个变化是，蓝屏死机 (BSOD) 已更改。 在以前版本的 NT 中，BSOD 显示系统上所有驱动程序的链接时间和加载地址信息，以及崩溃时堆栈的转储。 在 Windows 2000 中，只显示停止代码和相关的地址行（地址行将一个或多个停止代码参数转换为设备驱动程序中的位置）以及详细消息。 支持消息建议检查 BIOS 和硬盘驱动器设置，并禁用碎片整理软件和病毒扫描程序，以避免再次崩溃。 Microsoft Premier Support Services (PSS) 根据他们的经验和客户反馈确定，NT 4 型 BSOD 对确定崩溃原因没有帮助。
我个人发现，加载的驱动程序列表，尤其是堆叠转储，在从用户那里获取驱动程序错误报告时非常有用，获取这些信息比让用户发送兆字节的故障转储要容易得多，速度也快得多。 我经常根据堆叠转储来隔离崩溃的原因，并根据驱动程序列表中显示的版本信息对用户加载的驱动程序版本进行验证。 我很想知道你的想法：你希望看到 NT 4 样式的 BSOD 延续到 Windows 2000，还是新的 BSOD 格式已经足够？ 如果你有意见，请向我发送电子邮件。 我将在下期通讯中报告这次非正式投票的结果。 虽然我以 BSOD 为主题，但请务必查阅永远流行的 Systems Internals 蓝屏屏幕保护的 Windows 2000 更新，本期将对此进行介绍。
谢谢！
-Mark
SYSTEMS INTERNALS 新内容
SDELETE
作为满足 C2 安全分级要求的 Windows NT 4.0 的一部分，它实现了“对象重用保护”。 这意味着，当应用程序首次访问资源时，NT 会将应用程序分配的文件和内存资源归零。 例如，这会阻止应用程序创建大型文件并检查其内容以查看以前存储在磁盘上的内容。 但是，对象重用保护并不包括保护绕过标准资源相关 API 或完全绕过操作系统的应用程序可访问的资源。 例如，可以使用磁盘编辑器（例如资源工具包的 DiskProbe）检查磁盘未分配部分的内容。 这样你可以查看以前属于已删除文件的数据。
许多环境需要“安全删除”功能。 此功能可让用户永久删除敏感数据，使绕过操作系统保护设施的工具看不到这些数据。 加密文件系统 (EFS) 的出现突显了 Windows 2000 中对安全删除工具的需求。 加密以前未加密的文件时，EFS 在释放磁盘分配时不会清除包含该文件未加密数据的磁盘分配内容。 因此，即使所加密文件的活动版本是安全的，该文件的旧版本仍存在于磁盘的未分配部分，直到它恰好被 NTFS 分配给这些部分的新文件数据覆盖。
为了填补这个漏洞，我编写了 SDelete (Secure Delete)。 它是一种命令行工具，不仅可以安全地删除标准文件，还可以安全地删除磁盘未分配部分中存在的任何以前删除的数据。 此外，它还适用于 WindowsNT/2000 压缩、加密和稀疏文件，这需要使用碎片整理 API。 SDelete 遵守国防部的清理和消毒标准 DOD 5220.22-M，因此您可以确保数据一旦删除就会永远消失。
我向 SDelete 提供了完整的源代码及其如何工作的描述，这样你可以看到它是如何利用碎片整理 API 的，并且可以验证我关于它将阻止敏感的已删除数据被恢复的声明。
有关 Windows NT/2000 碎片整理 API 的文档，请参阅 http://www.sysinternals.com/defrag.htm. 若要下载包含完整源代码的 SDelete，请访问 http://www.sysinternals.com/sdelete.htm.
蓝屏屏幕保护 WIN2K 更新
Microsoft 对 Windows 2000 中的 NT 启动屏幕和蓝屏死机 (BSOD) 布局所做的更改使得 Systems Internals 蓝屏屏幕保护需要重大更新。 为继续给你提供最大的 BSOD 真实感，我发布了 2.0 版的屏幕保护。 它不仅反映了对 BSOD 格式的更改，还精确模拟了 Windows 2000 启动屏幕，包括旋转进度条带和进度栏更新。 此版屏幕保护如此真实，有时甚至会戏弄到 Windows 2000 的专家用户和开发人员。 当然，在 NT 4.0 蓝屏屏幕保护下，仍会显示 NT 4.0 BSOD 和启动屏幕。
如何完美地重新创建 Windows 2000 启动屏幕，同时又不违反版权法？ 我未将 Windows 2000 启动位图图形与屏幕保护包含在一起。 而是使用 DirectX 将图形模式切换为 Windows 2000 在启动序列期间使用的模式，然后引用 Windows 200 内核文件 ntoskrnl.exe 的位图资源。 这些资源（可通过在 Visual Studio 中打开 ntoskrnl.exe 的资源来查看）是内核显示的资源，这与 Windows 9x 执行启动图形（实际上是单独文件）的方式不同。 计算机 OEM 似乎没有机会自定义 Windows 2000 中的启动体验...
你可以从 http://www.sysinternals.com/bluescreen.htm. 下载蓝屏屏幕保护 如果你有关于用屏幕保护戏弄别人的幽默故事，请把它传下去。
可以在 1997 年 12 月 Windows NT 杂志 NT Internals 栏目“蓝屏内部”中找到有关 BSOD 的原理和原因的详细信息。 “Systems Internals 发布”页面 http://www.sysinternals.com/publ.htm 上的链接会将你带到该栏目的在线版本。 该页面还包含指向我创作的文章和栏目的其他在线演示文稿的链接。
“LINUX 和 ENTERPRISE 版”
我在《Windows NT 杂志》4 月刊上发表的关于 Linux 内核可扩展性不足的文章在 Linux 社区产生了巨大的反响，这促使该杂志提前发布了这篇文章的在线版本。 可以在 http://www.sysinternals.com/publ.htm. 上的“文章”部分找到文章“Linux 和 Enterprise 版”的链接 该文章介绍 Linux 内核当前版本 (2.2x) 的一些限制，包括缺少有效的事件等待机制、大量系统调用序列化、无异步 I/O，以及 sendfile（NT 中称为 TransmitFile）套接字 API 实现不佳。 这些限制的组合可防止 Linux 在性能方面与 NT 及其他 UNIX 在企业级应用程序（如 Web 服务器、数据库服务器和电子邮件服务器）上进行正面竞争。
“NT 实用工具内部”
如果你使用过 Filemon、Regmon 或 HandleEx，并且想要详细了解它们及其实现方式，那么你将会对我 2 月份的 Windows NT 杂志栏目“NT 实用工具内部”感兴趣。此栏目介绍这些工具的内部机制，对于 Regmon 和 Filemon，将介绍它们在捕获注册表或文件系统活动时记录的错误代码和请求类型。 指向本文的在线版本链接（刚变为可用）位于 http://www.sysinternals.com/publ.htm.
我的五月 WINDOWS NT 杂志专栏
你是否曾想过 Windows NT/2000 如何在内存中或磁盘上组织注册表的内容？ 本期（五月刊）的 Windows NT 杂志包括我的专栏“注册表内部”，其中会讲述这一点及其他内容。 例如，了解 Configuration Manager 内核模式子系统（负责管理注册表的子系统）如何查找键、存储值数据、优化搜索和保护磁盘上注册表文件的完整性。 Windows NT 杂志 http://www.winntmag.com 可在 Borders 以及 Barnes 和 Nobles 上获取。
旧事重提
在 Windows 2000 Beta 2 发布后不久，我采用了内核映像文件 (ntoskrnl.exe) 的 Checked（调试）版本，对内核进行了字符串搜索，并提出了用于生成内核的源文件的名称列表。 NT/2000 内核的 Checked 版本包含许多 Assert 语句（一致性检查），其中包括 Assert 所在文件的文件名。 假设内核源中几乎每个重要的文件都至少有一个 Assert，那么这个列表就相当全面了。 将列表转储到 Java 脚本中，我可以很好地看到类似于资源管理器的Windows2000 源代码树的目录结构树视图。 请在 http://www.sysinternals.com/nt5src.htm. 查看它
INTERNALS 新闻
GUI 博士可怜的床边礼仪
在《Microsoft 开发人员网络新闻》的 3 月/4 月版中，GUI 博士回答了一位读者询问驱动程序如何关联（强制使用特定CPU）其线程的问题。 GUI 博士回复说，无法从驱动程序确定系统上的处理器数，并且驱动程序线程无法判断它正在哪个处理器上运行。 但 GUI 搞砸了这个诊断（也许 GUI 博士应该坚持使用 GUI）。
NT 内核 (ntoskrnl.exe) 将 NTDDK.H 中定义的名为 KeNumberProcessors 的变量导出为：
extern PCCHAR KeNumberProcessors;
可以直接在驱动程序中引用它，如下所示：
CHAR i;
for( i = 0; i < *KeNumberProcessors; i++ ) {
// do processor specific stuff
}
要确定驱动程序线程在哪个处理器上运行，请使用 KeGetCurrentProcessorNumber()，这是另一个内核导出，不仅在 NTDDK.H 中定义，而且在 DDK 中实际记载了！
GUI 博士为这种病开错了药，于是我礼貌地通过一封礼貌的电子邮件告诉了博士。 令人惊讶的是，GUI 博士甚至从未确认过这封电子邮件。 我们将在下一期看看这位好博士是否承认错误...
WINDEV '99 EAST
面向 Windows 开发人员的 1999 East Coast 高级会议即将召开。 WinDev '99 East 将于 6 月 14-18 日在 Boston Cambridge Marriot 举行。 许多 Windows 开发领域的大腕都将发言，包括 Jeff Richter、Jeff Prosise 和 Don Box。 我将与 Jamie Hanrahan 和 Brian Catlin 一起参加设备驱动程序专题会议。我的演示文稿包括一个为期一天的关于 NT 内部的教程，以及一个关于编写 Windows NT/2K 文件系统驱动程序的教程和一个关于高级设备驱动程序开发问题的教程。 欢迎大家前来参加！
NUMEGA DRIVER WORKS 即将发布
Compuware NuMega Labs 即将发布功能强大的新 Windows 9x/NT/2K 设备驱动程序开发工具包 DriverStudio。 DriverStudio 结合了 NuMega 的所有现有设备驱动程序工具，包括 DriverAgent、DriverWorks、SoftICE 和 VtoolsD，并新增了用于驱动程序的 BoundsChecker 和 FieldAgent（仅限 Windows NT/2K）。
BoundsChecker 的设备驱动程序版本可全面监控驱动程序使用的每个内核 API，你可以使用它监控驱动程序与系统上任何其他设备驱动程序的交互。 FieldAgent 可让你将 BoundsChecker 的驱动程序版本部署到客户端系统，以便客户端收集可分析的跟踪。 即将为 DriverStudio 客户免费更新的是驱动程序的 TrueTime 和驱动程序的 True coverage，这些工具可让您轻松地对设备驱动程序进行性能调整和覆盖测试。
此程序包是终极驱动程序开发工具包，我衷心推荐它（我在使用试用版程序）。 更多信息请参阅 http://www.numega.com.
BETA 3 DDK 已发布
随着 Windows 2000 Beta 3 的发布，Microsoft 提供了可免费下载的 Windows 2000 Beta 3 DDK（设备驱动程序工具包）。 你可以从 http://www.microsoft.com/ddk/ddk2kb3.htm. 获取 DDK 我希望 SDK 能尽快推出，因为 Beta 3 中有许多 Win32 API 在 4 月版 MSDN 中没有记录。
WIN2K 排队的旋转锁
Windows 2000 对其全局锁使用一种称为“排队的旋转锁”的新型旋转锁。 Windows 2000 中的全局锁与 Windows NT 4.0 的相同，包括：
KiDispatcherLock：计划程序数据库锁KiContext-SwapLock：线程交换锁MmPfnLock：物理页帧数据库锁MmSystemSpaceLock：内核模式地址空间锁CcMasterSpinLock：Cache Manager 的全局旋转锁CcVacbSpinLock：Cache Manager 的映射数组锁
在单处理器上，排队的旋转锁的工作方式与正常的旋转锁完全相同。 但在 NT 的多处理器版本中，排队的旋转锁明显不同。 与标准旋转锁一样，排队的旋转锁在 HAL 中实现。 内核将调用 HAL 函数 KeAcquireQueuedSpinlock 来获取已排队的旋转锁，并调用 KeReleaseQueuedSpinlock 来释放已排队的旋转锁。 KeAcquireSpinlock 和 KeReleaseSpinlock，内核用于获取和释放标准旋转锁的 HAL 函数，需要指定旋转锁的地址作为参数。 相比之下，排队的旋转锁函数采用全局旋转锁的索引号。 内核初始化数组中的全局旋转锁，其中每个旋转锁都有一个预定义的索引号，供内核用以向 HAL 标识它们。 因此，设备驱动程序无法定义和使用排队的旋转锁，因为无法扩充全局排队的旋转锁数组。
在 Windows 2000 中，SMP 中的每个处理器控制区域 (PCR)（每个处理器都有一个 PCR）都有一个数组，数组中的条目数与排队的自旋锁数一样多。 每个数组条目包含两个字段：指向它对应的排队旋转锁的指针（“spinlock”字段）以及“queue”字段。 在以下说明中，当我引用旋转锁和队列字段时，我谈论的是与获取或释放的旋转锁的数组条目关联的字段。
KeAcquireQueuedSpinlock 的工作原理如下：函数尝试使用互锁交换 CPU 指令获取旋转锁，以将当前处理器的 PCR 的地址置于旋转锁中。 如果保持旋转锁，则作为交换操作的一部分，函数将获得另一个处理器的 PCR 的地址。 然后，函数通过在自己的 PCR 中切换旋转锁字段的低位将自己标识为“等待”。 接下来，它将自己的 PCR 地址放入从旋转锁检索到的 PCR 的队列字段中。 最后，它在繁忙循环中等待，直到其旋转锁字段中的低位被关闭。当位关闭时，当前处理器已被授予自旋锁，因此它返回到获取函数的调用方。
在处理器获取排队的旋转锁并完成它想要在保持锁定时执行的操作后，它会调用 KeReleaseQueuedSpinlock。 KeReleaseQueuedSpinlock 查看当前处理器的 PCR 中指定旋转锁的队列字段。 如果队列字段不为零，则表示另一个处理器已将其 PCR“排队”。 KeReleaseQueuedSpinlock 清除等待 PCR 的旋转锁字段的低位，然后清除其自己的队列字段并返回 。 通过清除等待 PCR 的旋转锁字段中的低位，正好向下一个 CPU 发出信号，指示它可以拥有锁定。 如果队列字段为零，则表示没有其他处理器在等待锁定，KeReleaseQueuedSpinlock 只需执行互锁交换操作即可清除全局旋转锁。
排队的旋转锁的操作是处理器“排队”等待保持的旋转锁。 每个处理器告知队列前面正在等待的处理器并将自己排入队列。 这为排队的旋转锁处理器获取旋转锁的获取提供了确定性顺序，按照其请求的顺序获取旋转锁。 对于标准旋转锁，没有此类排序。 排队的旋转锁具有另一个更重要的优势。 当处理器旋转等待其旋转锁字段清除低位时，它在自己处理器专用的内存上旋转。 当处理器忙于等待标准旋转锁时，它会在由所有处理器共享的全局旋转锁上自行旋转。 因此，排队的旋转锁具有更好的多处理器总线特征，因为在繁忙的等待期间没有共享的缓存行访问。 此外，由于排队的旋转锁的排队性质，当锁与多个处理器争用时，总线锁操作通常比标准旋转锁操作少。
排队的旋转锁是 Microsoft 对 Windows 2000 多处理可扩展性进行的几项增强之一。
即将推出
Windows 2000 包括许多功能，使其对操作员错误和错误行为的应用程序更有弹性。 其中之一是， %systemroot%\system32 和 %systemroot%\system32\drivers 目录下的许多 DLL 和驱动程序都受到名为系统文件保护器 (SFP) 的监视器的保护。 可以转到该 system32 目录并重命名 ntoskrnl.exe 来验证它是否存在。 在检测到篡改受保护的系统文件，监视器将唤醒并通知你，并进行修复。 如果再次检查目录，你会发现 ntoskrnl.exe 已被神奇地替换。 下次再告诉你这是如何运作的。
感谢阅读 Systems Internals 通讯。
发布时间：1999 年 5 月 15 日，星期六晚上 7:15，发布者：ottoh