[新闻稿存档 ^] [< 第 1 卷第 2 号] [第 1 卷第 4 号 >]
Systems Internals 新闻稿第 1 卷第 3 号
http://www.sysinternals.com
版权所有 (C) 1999 Mark Russinovich
1999 年 6 月 19 日 - 本期内容:
SYSTEMS INTERNALS 新内容
- SDelete v1.1
- Strings v2.0
- LoggedOn
- Filemon v4.13
- DebugView/EE v3.1
- “NT 网络洞察”
- 6 月的“NT Internals”
- NTFrob 更新状态
- 旧事重提
INTERNALS 新闻
- Numega DriverStudio 已发布
- 6 月 Platform SDK 现已提供
- Win2K 系统文件保护程序 (SFP)
- 关闭从网络打开的文件
即将推出
- “杰出的”Win2K API
赞助商:WINTERNALS SOFTWARE
Systems Internals 通讯由 Winternals Software 赞助,网址为 http://www.winternals.com. Winternals Software 是 Windows NT/2K 高级系统工具的领先开发者和提供商。 Winternals Software 产品包括 FAT32 for Windows NT 4.0、ERD Commander(适用于 Windows NT 的启动磁盘功能)和 NTRecover。
Winternals Software 宣布发布 Regmon 和 Filemon 企业版。 这些实用工具提供 Filemon 和 Regmon 免费版中的全部功能,并增添了下列强大的功能:
- 查看远程 Win9x/NT 系统上发生的注册表和文件系统活动
- 将日志输出实时记录到文件
- 将输出行复制到剪贴板
- 突出显示与筛选器匹配的行
- 同时查看不同计算机的输出
- 将输出直接打印到打印机
- 轻松撤销最近 5 个筛选器选择
有关订购和定价信息,请访问 http://www.winternals.com.
大家好,
欢迎阅读 Systems Internals 新闻稿第三版。 该新闻稿目前有 4400 名订阅者。
在上一篇新闻稿中,我指出了 Microsoft 是如何消除蓝屏死机的,我们知道它正在转到 Windows 2000 (Win2K)。 新的 Win2K 蓝屏没有已加载的驱动程序和堆栈转储信息,而更低版本的 Windows NT 的蓝屏上显示了这些信息。 我问过你,你是否觉得 Microsoft 删除的信息很有用,而你希望他们不要插手。 回答几乎是一致的,除了一名受访者,其他所有受访者都想知道为什么 Microsoft 会选择最低标准。 下面是 Tony Lavinio 给出的一种典型看法:
换句话说,下面是 Microsoft 做决定所依据的客户回复:
“我不懂,所以肯定是错的;让它消失吧。”
他们为什么不干脆将整个屏幕都删了,显示一条消息,说“拔掉插,重新插上插头,重启”? 我们只有这一点线索来了解为什么出现了问题,但他们为什么将这点线索都拿走了呢?
至少在以前,如果是病毒扫描程序、碎片整理程序或有 bug 的驱动程序,我们知道该从哪里开始搜索。
在 NT 部署广泛的基础上,如果这款工具只帮到了我们 10,000 个人中的一人,那么这就值得。 特别是因为我们这 0.01% 的人支持其余 99.99% 中的很大一部分人。
只有谁在反对? Microsoft 中有人处理蓝屏崩溃报告,这并不奇怪。 下面是他们对这一变化的看法,这正式了 Tony 对更改原因的猜测:
我是 MS PSS 的 NT 安装小组的一员(该小组负责进行蓝屏故障排除)。 我可以向你保证,与我交谈过的大多数人都不知道如何处理 4.0 蓝屏上的信息。 我相信,如果你看到 stop 0xA 显示堆栈上到处都是 NAIFILTR.SYS,你就知道要更新防病毒软件,但大多数人不会建立这种连接,他们真的没有意识到停止代码和参数对他们是有用的。 知道如何解释蓝屏数据的人可能会感到恼火,但不幸的是,他们占少数。
正如我在上一篇新闻稿中指出的,我认为 Microsoft 应该继续推进 NT 4.0 蓝屏,保留已加载的驱动程序列表和堆栈转储。 我还觉得他们可以提供更多信息,还不是减少信息,来改进蓝屏。 例如,在崩溃时为什么不显示当前正在执行的程序的名称呢? 或者,让更多的 BugCheck 调用传递造成故障的内容的地址,而不仅仅是出现故障的内容地址? PSS 遇到这么多对蓝屏一无所知的客户的主要原因是,Microsoft 从未编写文章来解释如何阅读蓝屏上的信息。 所以,关于用户无知,至少有一部分的责任在于 Microsoft。
如果你想要更多地了解蓝屏是如何发生的,以及 (NT 4.) 蓝屏上有哪些信息,请查看我 1997 年 12 月在 Windows NT Magazine 杂志上发布的“蓝屏洞察”文章(可在 http://www.sysinternals.com/publ.htm). 上获得在线版本)。
像往常一样,请将这篇新闻稿传递给你认为可能对该内容感兴趣的朋友。
谢谢!
-Mark
SYSTEMS INTERNALS 新内容
SDELETE V1.1
在上一篇新闻稿中,我介绍了 SDelete,它是一种安全删除实用工具,可用于不可撤销地销毁文件数据,还可清理磁盘中以前被删除的数据空出来的空间。 第一个版本的 SDelete 无法安全地覆盖使用它删除的文件的名称。 文件名通常会泄露敏感信息,而使用 SDelete 删除具有会泄露信息的名称的文件可能会该使该信息暴露。 为了解决这个漏洞,我更新了 SDelete,它现在不仅可安全地覆盖文件数据,还能安全地覆盖文件名。 SDelete 会将文件重命名 26 次,将文件名中的每个字母替换为字母表中的连续字母(从“A”到“Z”),从而安全地删除文件名。
若要下载包含完整源代码的 SDelete v1.1,请访问 http://www.sysinternals.com/sdelete.htm.
STRINGS V2.0
可执行文件和 DLL 中经常嵌入字符串,这些字符串可以显示未记录的注册表值和在出现未记录的功能时提示的错误消息。 遗憾的是,大多数 Windows NT/2K 系统 DLL 和 EXE 都是编写来使用 Unicode 字符串的,而 Grep 等传统字符串搜索工具只提取 ASCII 字符串。 几年前,我编写了第一个版本的 Strings 实用工具,用于扫描二进制文件中的 ASCII 或 Unicode 字符串。 我在对 NT Internals 的研究中,我多次使用了它来帮助弄清楚 Microsoft 没有记录的信息。
但是,Strings 总是有一个重大缺陷,那就是它无法将通配符表达式视为文件说明符,这样你就可以一次扫描多个文件。 我需要这项功能,这样的话,例如,如果给定了注册表值的名称,我就能确定哪些系统 DLL 会引用它。
最后,我更新了 Strings,让它接受完整的通配符文件名,以及递归操作目录。 如果你指定了一个通配符表达式,Strings 会自动在输出行前面添加找到字符串的文件的名称,以便你可以执行如下所示的操作:
strings *.dll | grep SafeBoot
如果查看此表达式的输出(Windows NT Resource Kit Posix 实用工具中提供某个版本的 Grep),你就知道哪些系统 DLL 会在 Windows 2000 上检查 SafeBoot 注册表项。 若要查看 Win2K 系统 DLL、驱动程序和可执行文件使用了哪些新的注册表值,Strings 也非常有用。 例如,我使用 Strings 将 NT 4.0 SP4 TCP/IP 堆栈 (tcpip.sys) 中引用的注册表值与 Windows 2000 TCPIP 堆栈引用的注册表值进行了比较。 下面显示了 Win2K's TCPIP 堆栈不知道的值,大约了显示了一半(我假设所有这些值位于 HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
):
ReservedPorts
DefaultGatewayMetric
InterfaceMetric
TempLeaseExpirationTime
TempIpAddress
TempMask
DhcpDefaultGateway
TcpWindowSize
TcpInitialRTT
TcpDelAckTicks
EnableTrafficControl
EnableTOSetting
MaxNormLookupMemory
MaxSendSegments
MaxFreeConnections
MaxFreeTWTcbs
FFPFastForwardingCacheSize
我不会屏息等待 Microsoft 将堆栈的所有新配置参数记录下来。
若要下载 Strings v2.0,可访问 http://www.sysinternals.com/misc.htm.
LOGGEDON
你是否曾经想知道谁登录过远程 NT 系统? 如果是,你需要下载 LoggedOn。 LoggedOn 是一款简单的实用工具,它将显示哪些用户正在以交互方式登录到本地计算机或远程计算机,以及哪些用户通过资源连接(例如文件或打印机共享)来登录。 下面是 LoggedOn 输出示例:
C:\>loggedon main
LoggedOn v1.0 - Logon Session Displayer
Copyright (C) 1999 Mark Russinovich
Systems Internals - http://www.sysinternals.com
Users logged on locally:
MAIN\Administrator
Users logged on via resource shares:
MAINDOM\MARK
Windows NT 和 Win2K 没有提供应用程序可用于确定谁登录到计算机的 API,而 LoggedOn 通过查看登录到系统 HKEY\USERS
注册表树的注册表项来确定此信息。 以交互方式登录的任何用户的个人资料都加载到此注册表项中,个人资料中有可标识个人资料的关联用户帐户的 SID(安全 ID)。 例如,如果你打开 Regedit,在 HKEY_USERS
下查看,你将看到如下所示的内容:
HKEY_USERS\.DEFAULT\S-1-5-21-734676951-386466661-1233803906-500
在这里,只有一个用户以交互方式登录。 你可能分辨出它是本地管理员还是域管理员,因为 RID(相对 ID)是 500,这是保留用于管理员帐户的 RID NT。
通过使用允许一个系统查看另一个系统的注册表的 API,LoggedOn 读取远程计算机的 HKEY_USERS 键,并将它找到的 SID 转换为帐户名。 为了确定谁通过资源共享登录,LoggedOn 使用了 SDK 中记录的 NET API。 Net 命令行工具广泛使用 NET API。 LoggedOn 访问远程系统的注册表的一个副作用是,运行 LoggedOn 的帐户将始终在 LoggedOn 输出中显示为通过资源共享登录到远程系统。
若要下载包含完整源代码的 LoggedOn,可访问 http://www.sysinternals.com/misc.htm.
FILEMON V4.13
Filemon v4.13 刚刚发布,这个更新反映了对 Windows NT 文件程序驱动程序的更改,并更正了我无意中引入到 4.12 驱动程序中的 bug。 4.13 筛选器驱动程序进行了以下更改:
- 它使用 Resource 同步类型来保护他的某些内部数据结构
- 它处理新的 Win2K IRP、IRP_MJ_PNP_POWER
Windows NT 4.0 和 Win2K 设备驱动程序开发工具包 (DDK) 中事实上都没有记录 Resource 同步类型。 设计指南甚至没有提到 Resource,而参考资料中的“执行支持例程”部分记录了它们的功能。 Resource 是一种有用的机制,用于保护可由不同线程同时读取,但需要在更新期间由线程进行独占访问的数据结构。 因此,它们是读取器/写入器锁,读取器进行共享访问以及写入器进行独占访问时,需要用到这些锁。 文件系统驱动程序大量使用 Resource,因此我认为为了在适当的位置使用它们,更新 Filemon 是恰当的。
Filemon v4.13 还会处理新的 IRP_MJ_PNP_POWER IRP,以便在 Win2K 下运行时,他是方便通电和即插即用的筛选器驱动程序。 在处理这种类型的 IRP 时,文件系统筛选器驱动程序的唯一要求是,将 IRP 传递到筛选器所附加到的文件系统设备。
若要下载包含完整源代码的 Filemon v4.13,可访问 http://www.sysinternals.com/filemon.htm.
DEBUGVIEW/EE V3.1
DebugView/EE 是一种通用的调试输出监视器,可用于捕获 Win32 程序或 Win95、Win98、WinNT 和 Win2K 下的内核模式设备驱动程序生成的本地或远程调试输出。 但是,在用户使用设备驱动程序而遇到崩溃的环境中,其用途有限 - DebugView 在崩溃之前捕获的所有调试输出都会丢失。 最新版本的 DebugView/EE 解决了 Windows NT/2K 上的这个问题。 如果用户正在捕获设备驱动程序生成的内核模式输出,并且用户已将 NT 配置为保存故障转储,那么 DebugView/EE 可以在系统重启时从转储文件中提取调试输出。 使用 DebugView/EE 的“编辑”|“处理故障转储”菜单选项,让它扫描内存转储以获取调试输出。 这个功能使用户能够向你发送回一个文本文件,其中包含驱动程序在崩溃前刚刚生成的调试输出。
若要下载 DebugView/EE v3.1,请访问 http://www.sysinternals.com/debugview.htm.
“NT 网络洞察”
我 1999 年 3 月在 Windows NT Magazine 上发布的“NT Internals”专栏现已上线。 全面充分地了解 NT 的网络体系结构,包括它实现哪些 API、协议堆栈如何与 API 交互,以及硬件供应商如何编写网络驱动程序来使用协议驱动程序。 此外,请了解 Win2K 网络的一些新特性,包括反序列化的 NDIS 和 ATM 支持。
若要在线阅读“NT 网络洞察”和过去其他的 NT Internals 专栏,请访问 http://www.sysinternals.com/publ.htm.
6 月的“NT INTERNALS”
我的 Windows NT Magazine 专栏 6 月期内容是“EFS 洞察,第一部分”。 这篇文章描述了 Microsoft 加密文件系统 (EFS) 的体系结构,还详细讲解了 EFS 加密文件时采用的步骤。 EFS 为 Win2K NTFS 驱动器提供了一款透明加密工具,它是 Microsoft 专门开发的,用于解决 NTFSDOS 工具在不考虑 NTFS 文件的安全性的情况下读取这些文件的能力。 这个专栏将在三个月内在线提供。
在过去的两篇新闻稿中,我谈论了对备份和还原加密文件所需的 EFS API 没被记录的情况。 遗憾的是,当前版本的 MSDN 中仍然没有记录这些 API。 不过,我已经收到通知,知道 Microsoft 正在将标记为“Microsoft 机密”的文档发送给它的合作伙伴和备份软件供应商。 此外,在近期在达拉斯举行的 Microsoft TechEd 大会上,Microsoft 文件系统项目经理 David Golds 发表了关于 Win2K 文件系统增强功能的演讲。 在演示中,你可在线查看的幻灯片位于 http://www.teched99.com/slides/1-337.ppt,他提到了没有记录备份 API,但是你可以告诉他你想要这些内容被记录下来。 遗憾的是,幻灯片上没有列出他的电子邮件地址。
有关 Windows NT Magazine 订阅信息,请访问 http://www.winntmag.com。
NTFrob 更新状态
NTFrob 是我几年前发布的一款实用工具,可用于在 NT 4.0 上精确配置前台和后台进程的量子长度。 NTFrob 修改了 NT 内核内部的数据结构,因此它高度特定于 Service Pack。 自从 NT 4.0 Service Pack 5 发布以来,我收到了大量问询,被问到我何时将发布 NTFrob v1.5(SP 5 更新)。 我的回答是即将提供更新 - 我正在等待 Microsoft 向 MSDN 订阅者提供 SP5(包括调试信息)。 我需要调试信息来更新新版 Service Pack 的 NTFrob。
若要下载 NTFrob for NT 4 SP0-4,请访问 http://www.sysinternals.com/ntfrob.htm.
旧事重提
几个月前,我在 Systems Internals 上发布了一个 Win9x/NT/2K 串行和并行端口监视器。 使用 Portmon,你可以准确查看应用程序与串行和并行端口的交互方式,包括它们发送和接收的具体数据。 你可以使用它来跟踪拨号会话、laplink 串行连接或打印机活动。 Portmon 已经取得了巨大的成功,Ziff-Davis 的软件库最近将它评为了 5 星,这是最高评级。 其他获得 5 星的 Systems Internals 工具包括 Regmon、NTFSDOS 和 BlueSave。
若要下载 Portmon,请访问 http://www.sysinternals.com/portmon.htm.
INTERNALS 新闻
DRIVERSTUDIO 已发布
CompuWare NuMega Labs 发布了 DriverStudio,这是一个面向 Windows 9x/NT/2K 设备驱动程序开发人员的综合工具包。 它包括 oftICE 4.0、BoundsChecker for Drivers、VtoolsD、DriverAgent、DriverWorks 和 FieldAgent for Drivers,未来将添加 TrueTime for Drivers 和 TrueCoverage for Drivers。 就像我在上一篇新闻稿中所说的,这是一个必备的开发人员工具包。 NuMega 还推出了一个名为“Driver Central”的网站,它也面向设备驱动程序开发人员,网址为 http://www.numega.com/drivercentral/default.asp.
6 月 PLATFORM SDK 现已提供
你现在可以下载 6 月版的 Microsoft Platform SDK,网址为 http://www.msdn.microsoft.com/developer/sdk/platform.asp.
WIN2K 系统文件保护程序 (SFP)
NT 系统管理员和用户最大的抱怨之一是 NT 的“DLL Hell”。 DLL hell 是许多应用程序使用它们捆绑的版本更新关键系统 DLL 所导致的。 应用程序通常这样做的目的是保证它们能够正常工作,但是,当它们替换 DLL 时,它们会安装不兼容的版本,多次中断其他应用程序,它们甚至会将 DLL“更新”到更低的版本。
Microsoft 通过引入系统文件保护程序 (SFP) 解决了 Win2K 中的 DLL 版本控制问题。 实际上,它的名称不久将更改为 Windows 文件保护程序 (WFP),但截至 Beta 3(版本 2031),它仍然叫做 SFP。 SFP 是在一个名为 sfc.dll 的 DLL 中实现的,在系统启动时,Winlogon 进程 (winlogon.exe) 会加载这个 DLL。 SFP 包含一个内置列表,其中列出了大约 3000 个标准 Win2K 系统 DLL、可执行文件 (.exe)、安装文件 (.inf)、驱动程序文件 (.sys) 和字体文件 (.fon),它们安装在 30-40 个不同目录中。 当 SFP 初始化时,它会对包含它保护的文件的每个目录执行一个“更改通知目录”操作。 当它检测到文件被篡改时,它会弹出一个对话框来通知当前用户,在事件日志中写入一个偶数,并将修改后的文件替换为存储在 %systemroot%\system32\dllcache 中的备份。 如果 SFP 在 dllcache 中查找的备份文件缺失,或者也遭到篡改,SFP 会从 Win2K 安装介质中检索新的副本。
要查看 SFP 保护的文件,可以使用本新闻稿中其他地方提到的 Strings 实用工具转储 %systemroot%\system32\sfc.dll 中嵌入的 Unicode 字符串名称。
只有 hotfix.exe、Service Pack (update.exe)、升级安装和 Win2K 更新服务这几种实用工具可以更新系统文件。 这些工具如何绕过 SFP? 它们通过调用导出的 sfc.dll 函数 SfcTerminateWatcherThread 来暂时禁用 SFP,并且确保在 dllcache 子目录中反映了更新。 应该注意的是,Win2K 要求所有系统文件都由 Microsoft 进行数字签名,因此通常不可能使用你自己的任意版本更新系统文件。
Win32 程序可以使用 FindFirstChangeNotification API 和 FindNextChangeNotification Win32 API 跟踪目录中的更改。 然而,这些 API 只是通知应用程序某些内容发生了更改,它们不会确切地告诉应用程序究竟发生了什么更改。 因此,应用程序需要扫描整个目录,来确定哪些文件或子目录可能已经更改。 SFP 使用 NT 本机 API 来执行更改通知请求,其中 NT 会告知它受监视目录中的哪些文件或子目录发生了更改。 SFP 使用的函数名为 NtNotifyChangeDirectoryFile,与 90% 的 NT 本机 API 一样,它没有被记录下来。 在不久的将来,Systems Internals 中将提供一个小程序,它会演示如何使用 NtNotifyChangeDirectoryFile。
我在 9 月的“NT Internals”专栏“Win2K 可靠性增强洞察,第二部分”中更详细地描述了 SFP。
关闭从网络打开的文件
Systems Internals 访问者向我反映的最常见问题之一是,“如何关闭用户从网络打开的文件?”。如果有用户远程打开了某个文件或目录,那么你无法在本地删除、重命名或更新这个文件或目录。 类似的问题是,“我如何看到用户从网络打开了哪些文件?”。这两个问题都可以通过 Windows NT/2K 附带的 Net 命令行实用工具来回答。 若要查看打开了哪些文件,只需键入“net file”。
你将获得一个列表,上面列出了已打开的文件的名称、相应的文件名标识符,以及打开文件的用户的名称。 若要关闭你看到已经打开的某个文件,请键入 net file <id> /close
。 若要查看在本地打开的文件,可以使用 NTHandle 或 HandleEx 工具。
Net 命令的文件查看和关闭功能所基于的 API 记录在了 Platform SDK 和 MSDN 库中。 可以使用 NetFileEnum API 枚举已打开的文件,使用 NetFileClose API 关闭已打开的文件。 实际上,使用这些 API 可以枚举在远程服务器上打开的文件,而这是 Net 命令做不到的。
如需 NTHandle,请访问 http://www.sysinternals.com/nthandle.htm. 如需 HandleEx,请访问 http://www.sysinternals.com/handleex.htm.
即将推出
“杰出的”WIN2K API
Win2K 引入了一个名为 AWE(地址窗口扩展)的新 API,内存密集型应用程序可以使用它来直接访问和管理大量物理 RAM - 甚至是超过 3 GB 的 RAM,3 GB 是 Windows NT 应用程序在其虚拟地址空间中可以寻址的 RAM 上限。 事实上,如果 x86 系统具有 PSE(页面大小扩展)和超过 4 GB 的 RAM,那么应用程序可以使用 AWE 来利用计算机的所有内存。 因此,这个 API 非常适合内存不足的应用程序,例如 Web 服务器和数据库服务器。 下次我将告诉你如何使用 API,无论是从 Win32 应用程序还是从设备驱动程序。
虽然我说的是内存不足的应用程序,但对于编写会缓存文件的应用程序(例如 Web 服务器)的任何人来说,这都是一个提示。 Windows NT 缓存管理器将它的缓存内存划分为 256 KB 的槽,称为“视图”。 如果缓存了小于 256 KB 的文件,缓存管理器仍然必须为该文件分配整个的 256 KB 的槽,这意味着缓存的部分虚拟内存会被浪费掉。 因此,在你自己的应用程序的虚拟内存中缓存小于 256 KB 的文件,并且依赖文件系统来缓存大于 256 KB 的文件,这样的话,性能通常更加高效。 IIS 5.0 就采用这一技巧。
感谢阅读 Systems Internals 新闻稿。
发布时间:1999 年 7 月 19 日星期六晚上 7:14,发布者:ottoh