KZTechs.COM - Smallfrogs' Technical BLOG

Debugger Tricks and Tips

下面是一些我收集的WinDBG常用的指令，在Dump分析和调试的时候都很有帮助的， 特此公开。

具体的使用方法请见WinDBG帮助文档。

--------------------------------------------------------------

Debugger System Help Commands

.help        - Command help              
.hh        - Extended Command Help


Set Current Processor

~0   - Context (kv etc) set to first processor
~1   - Context (kv etc) set to second processor


Debugger System Commands


.attach    <PID>        - Attaches to a new target application.
.tlist            - List of app processes currently running
.reboot            - Reboot the target.
.crash            - crash the target.
.thread            - Shows implicit threas running ID.
.reload /f        - reload all system modules (/f=all symbols, /user=usermode)
.formats xxxx       - display hex,dec,oct,signed for value a memory address xxxx
.cls            - clear debug screen
.chain
.dump /f                - Write out memory dump (user and kernel space)

Debugger System Extensions (BANG commands)


!process 0 0         - Displays info about specified process, or all processes running.
!process 0 7         - Displays info about specified process, with call stack info
!process 0 17         - Displays info about user/kernel process, with call stack info
!sprocess          - Shows session processes
!address        - Displays info about memory used by target process or target computer.
!analyze -v -hang    - Automated analysis. Results displayed in the Debugger Command window.
!pte            - Shows Page Table Entries (PTEs)
!drivers        - display system driver
!dpcs                   - show DPC's
!timer                  - Show timer objects (dt nt!_KTIMER)
!memusage        - displays memory usage.
!sysinfo          - displays machine information (lots of option keywords)
!vm            - displays summary information about virtual memory use statistics
!ready            - displays information about each system thread in a READY state.
!pcr            - displays the current status of the Processor Control Region
!object            - displays information about a system object.
!handle            - displays information about handles owned by processes in the target
!heap            - displays heap usage information, controls breakpoints in the heap manager
!lmi            - display loaded module information
!devstack        - Shows device stack for a device
!poreqlist              - Shows power status.
!drvobj                 - Shows driver object like: !drvobj \FileSystem\FastFat
!locks                  - Shows outstanding locks
!acpicache              - Shows ACPI tables cached by HAL
!fadt                   - Shows extension displays a Fixed ACPI Description Table (FADT
!acpiinf                - Shows information on the configuration of the Advanced Configuration and Power Interface
!poolused 4             - Shows biggest memory consumers.
!thread -1 4            - Shows all waiting threads
!cpuid            - CPUID
!arbiter        - shows resource arbiters
!smt            - Processor Cores
!idt -a                 - Interrupt descriptor table


=== SPECIAL EXTENSIONS ======
!active                 - needs kk.dll in XP debugger XP directory Analyzes hangs

.load dxgkdx.dll - for directX kernel memory logging enable type:
!dxglog -?

.load wow64exts.dll
!sw             -switch between 32bit & 64bit


Controlled Execution Commands


g         - Go
p         - Step
t         - Trace
wt         - Trace and Watch Data
tb         - Trace to Next Branch
gh         - Go with Exception Handled
gn         - Go with Exception Not Handled.
t        - trace
wt        - trace and watch data
pa        - step to address
pc        - step to next call
r        - display registers.
k        - stack unwind.
lm        - list loaded modules.
k,kb,kd,kp     - display the stack frame of the given thread.
u esp        - unassemble (esp starts at instruction ptr)
ub         - unassemble backward
ds        - Dump UNICODE string (ds srv!SrvComputerName)

lmv m hal (or NT) - version of hal

X hal!*Set*     - Show me all the functions in hal.dll with "Set" contained in them


Breakpoint commands (j command with bx for conditional breakpoints)

bp        - Set breakpoint
bu        - Set unresolved breakpoint (saves breakpoint - use instead of bp)
ba        - Break on access
bc        - Breakpoint clear
bd        - Breakpoint disable
be        - Breakpoint enable
bl         - Breakpoint list
x nt!*          - Find Functs in nt.dll (x sdbus!* gives breakpoints in SDBUS component)


Sample BP with J

bu nt!PopSetNotificationWork "j poi(esp+4)=1 '';'x;g' "
bu nt!NtSetSystemPowerState ".echo nt!NtSetSystemPowerState exited with ;x status;g"

MS Press 《Windows Internals, Fifth Edition》 书评

说起 《Windows Internals》一书，只要对Windows 底层感兴趣的人都应该有听说过。这是一本讲述Windows底层机理的书，但是没有覆盖所有的Windows 内容，例如 Windows窗口管理、图形、COM/COM+、.NET 等。如果你愿意了解Windows 底层原理，那么这本书是很适合的，如果仅仅是学会如何使用Windows或进行简单的排错，那么这本书并不适用。

言归正传：

四年前，《Windows Internals》的第四版发布了，第四版主要涉及的是 Windows XP、2003 的技术。
两年前，《Windows Internals》的第四版的中文翻译版本出版了，译者是潘爱民。个人觉得翻译的很不错。

两个多月前，《Windows Internals》的第五版在经历很长时间的延期以后，终于出版。也是在这个时候，Microsoft MVP项目组的MS Press活动里面出现了这本书的书目，我自然毫不犹豫的参加了这个版本的书评活动。

十一前，久违的原版的《Windows Internals, Fifth Edition》出现在我的面前。在这一点上，非常感谢Microsoft MVP项目组的支持。

好厚！这是我对第五版的最直观的感觉。第五版比第四版厚了很多（从第四版的976页到第五版1264页，足足增加了288页）。在《Windows Internals, Fifth》里面，针对的对象主要是 Windows Vista、Windows Server 2008。虽然目前Windows 7已经RTM了，但是是否意味着《Windows Internals, Fifth》就过时了，是否需要等待年底或者明年的第六版呢？

我认为，相对于Windows XP –> Windows Vista 的巨大的改变，Windows Vista –> Windows 7的改变是比较小的。虽然Windows 7引入了大量的新名词，但是从实际上来看，Windows 7和Windows Vista是同源的，至少在内核层面是同源的。因此关于Windows Vista 内核机制介绍的文章，是能够适用于Windows 7的（也许在某些微小的地方有所不同）。从这个意义上看，《Windows Internals, Fifth Edition》也能够覆盖Windows 7的内核技术点的。但是如果使用第四版的内容去观察Windows 7或者Windows Vista，那么就会发现有很多的差异了。

也就是说，如果想了解Windows 7，在《Windows Internals》第六版出来以前，《Windows Internals, Fifth Edition》是最合适的。

《Windows Internals, Fifth Edition》官方地址：http://www.microsoft.com/mspress/books/12069.aspx

提醒：目前第五版的影印版已经由人民邮电出版社引进了，大家可以在各大网上商店买到。
    China-pub：http://www.china-pub.com/195975&ref=q3j
    卓越亚马逊：http://www.amazon.cn/mn/detailApp?ref=DT_SMV&uid=475-0229956-3073424&prodid=bkbk987581
    当当：http://product.dangdang.com/product.aspx?product_id=20680892

《Windows Internals, Fifth Edition》的变化

先看看两个版本的目录的差异吧：

变化一：结构的变更
    从上面的目录里面可以看到，相对于第四版的章节顺序，第五版的章节顺序更加合理一点。

• 第四版是从一个开机的过程，慢慢的深入到具体的各个子系统的内部原理介绍；而第五版是先介绍了各个子系统的原理，最后整合到启动和关机这个部分。
• 在内存管理方面，第五版把内存管理、Cache、文件系统放在了一起，这一点比第四版要好一点。因为Cache和内存和文件系统都有关系的，放在一起，更便于理解。

变化二：文章内容的变更
    Windows Vista对于微软来说，是一个划时代的革新产品。无论是否在商业领域里面获得成功，至少在技术领域里面，Windows Vista 的确有了巨大的变化。从第五版里面就可以看到，在这个版本里面，大量的文章被翻新了，另外也增加了大量的章节。

例如，从Windows Vista 开始备受关注的UAC功能就单独作为了一个章节进行说明。但是，从实际上来说，UAC仅仅是Windows内部安全机制变更所引发的一个安全功能，UAC的实现更多的是依靠了其他Windows系统组件的变化：例如进线程模型、安全令牌等，正是这些机制的变化，才诞生了UAC这个功能。在《Windows Internals, Fifth Edition》里面，这些东西都得到了较好的描述。

如果熟悉操作系统原理，那么对于内存管理在操作系统里面的地位的重要性应该是很能够了解的。在，《Windows Internals, Fifth Edition》里面，内存管理的60%以上的篇幅发生了变动，也就是说，Windows Vista在内存这一块，比Windows XP/Server 2003有了很多的改进，关于这一块的变化，书中有了比较详细的描写。

虚拟化，在当今社会里面是一个非常热门的话题。我们知道在Windows Server 2008里面，引入了Hyper-V虚拟化组件，那么关于这一块的原理，《Windows Internals, Fifth Edition》也给了一个比较系统的阐述。

我最后想说的一个建议重点关注的内容是在文件系统里面的Common Log File System（CLFS），虽然这个章节篇幅不长，只要8页，但是在Windows Vista 里面很多新增的技术（例如 TxF、TxR），或多或少都和这个东东有关系，就算没有实际上的沾边，但是一些理论是和CLFS相关的，建议大家重点关注一下这个新的文件系统。

相对于第四版，第五版新增了288页的海量巨幅，而每一行文字对于学习Windows内部机制都是非常珍贵的，一下我也没法给出一个版本的差异吧。不过我整理了一个第五版新增章节的目录列表，大家可以看看，我相信大家在看完这个列表之后，会对《Windows Internals, Fifth Edition》一书有了更深入的了解，进而产生购买的欲望，哈哈～

变化三：工具的变更
    在第五版里面，大量使用了Sysinternals 的最新工具，例如 Process Monitor 等。另外以前使用第三方工具才能实现的一些工具，如果系统里面也带有了类似的东西，也换作了系统的工具。这一点也是一个比较大的变化。对于一本技术书籍来说，紧跟时代变更是必须的，同样的事情，如果系统工具也提供了类似的功能，为啥不使用系统工具呢？

最后，说一下《Windows Internals, Fifth Edition》的定位吧。对于有着较深Windows底层知识的人来说，第五版能够很好的提高这些人的技术水平，但是，如果把这本书给了一个对Windows底层不是很了解的人来说，那么本书并不适合他们阅读。也许这就是本书的精华所在吧。Smallfrogs 希望所有对Windows底层感兴趣的人，都能够买一本《Windows Internals, Fifth Edition》，去细细的品味其中的精华吧。

Smallfrogs
http://www.KZTechs.com

附：《Windows Internals, Fifth Edition》的新增内容（相对于第四版来说）列表（见下图绿色部分）

Windows 7 研究——Windows 文件夹的秘密：Windows 目录到底占用了多少真实的硬盘空间

张康宗（Smallfrogs）
http://www.kztechs.com

原本这个话题是准备在8个月前写的，但是由于种种原因，一直推迟到现在。今晚（或者说今天凌晨），抽空把程序弄完了，因为只有程序写完以后，这个话题才有实际的价值。

这个话题就是：Windows 目录到底占用了多少真实的硬盘空间？

看到这个问题，我想99%的人都会说：用资源管理器右键点击Windows目录，看看属性不就知道了吗？何必故弄玄虚呢！

但是，我 Smallfrogs 会有那么傻的把一个大家都知道的问题重新翻出来吗？既然提出了这个话题，就有我的道理！请各位耐住性子往下看，看看我们的Microsoft同学又玩了什么样的花活，呵呵。

我们知道，查看一个目录有多大的最快捷的方法就是看看资源管理器文件夹的属性，但是我今天要说的是：如果你用这个方法去看 Windows Vista / Windows 7 系统的目录，你会被你的眼睛所欺骗，因为，Microsoft 同学在 Windows Vista/ Windows 7 里面大量使用了NTFS文件系统的特性之一的：硬连接（Hard Link）来实现WinSxS机制！

关于 WinSxS，可以看我之前写的 《WinSxS 混乱导致的应用程序不能启动》一文。

我们知道，要安装 Windows Vista / Windows 7系统，那么系统分区必须是NTFS文件系统。原因有以下一些：

• 系统文件保护所需
• 各种安全保护机制，如MIC所需
• WinSxS 所需
• ……

关于最后一点的 WinSxS 所需，我没有看到过相关的资料说明，不过可以肯定的是，这也是Windows Vista / Windows 7 系统需要NTFS文件系统的一个条件，因为只有在 NTFS 文件系统上面，才能实现硬连接机制，也才能达到优化Windows目录占用磁盘空间的目的。

关于硬连接，MSDN是这样解释的：

A hard link is the file system representation of a file by which more than one path references a single file in the same volume. To create a hard link, use the CreateHardLink function. Any changes to that file are instantly visible to applications that access it through the hard links that reference it. However, the directory entry size and attribute information is updated only for the link through which the change was made.

简单的说，就是一种针对文件的特殊快捷方式，只不过这种快捷方式的实现和一般的快捷方式不一样。

• 一般的快捷方式是创建一个LNK文件，在这个LNK文件里面描述了目标文件/目录的属性，资源管理器或者其他文件管理工具利用SHELL32.DLL里面的API函数获得这个LNK文件所指向的文件/目录，从而进行访问。
  
• 硬连接：是一种基于文件系统级别上的针对文件的快捷方式，基于文件系统级别的含义就是说，只要文件系统启动了，那么对应的快捷方式也就生效了。换句话说，这种连接是常存的，因为文件系统是必须要随机启动的。
  
  硬连接是NTFS文件系统特有的属性之一，在Linux下面，也有类似的机制。硬连接适用于在同一个卷的文件级别，硬连接是不能跨卷的。

Windows Vista / Windows 7 自带了创建硬连接的命令：mklink.exe，利用这个命令，我们可以给指定的文件创建硬连接：

下面的命令将在link.txt和source.txt之间建立硬连接关系
C:\Users\Smallfrogs\Desktop>mklink /h link.txt source.txt
为 link.txt <<===>> source.txt 创建了硬链接

注意上面的例子：link.txt本是一个不存在的文件，但是当执行完mklink命令以后，link.txt文件也就被创建了。其实，link.txt是一个虚假的文件，它是在文件系统层面上对source.txt文件的一个映射，而link.txt是不占硬盘空间的。

关于硬盘空间的占用问题，Smallfrogs 是这样测试的：
1、给硬盘划分一个新分区，空间只有2GB
2、在这个分区的test目录里面新建了一个1.9GB大小的文件，此时剩余空间是0.1GB
3、用mklink命令给这个1.9GB大小的文件建立了一个硬连接
4、检查这个分区的剩余空间，还是0.1GB，但是如果用资源管理器看test目录的属性，会发现有2个文件，总大小是3.8GB（整个分区才2GB，能够容纳3.8GB大小的文件吗？显然不可能了）

还是针对上述的例子，如果我们把原始的文件 source.txt 删除以后，link.txt文件还是会继续存在的，且内容就是source.txt的文件内容。也就是说，我们删除source.txt，实际上删除的仅仅是这种连接关系，文件本身还是没有被操作的。

关于硬连接，最后一个需要介绍的内容是：当硬连接建立以后，硬连接双方任何一个对象被修改，都会造成对应的连接对象被修改。例如上面的例子：如果修改了link.txt，那么source.txt文件也会同步被修改，反之亦然。这一点和SHELL层面的快捷方式不同，SHELL层面的快捷方式文件LNK仅仅是一个指示关系，修改LNK文件并不影响LNK文件指向的对象，修改LNK文件指向的对象也不会影响LNK文件。

好了，基本知识介绍完了，我们来实际看看Windows目录里面对于硬连接的使用情况吧。

经常看到有人抱怨，Windows\WinSxS目录占用了太多的空间，里面经常发现有同名的文件，而且这些同名的文件在 Windows\System32 目录下面也有存在，这是为啥呢？其实这就是硬连接导致的。

Microsoft 实际上在 Windows\WinSxS 目录和Windows目录之间建立了硬连接的关系，举一个最简单的例子：

对于 Windows 7 RTM 来说，你可以在2个地方找到Ntoskrnl.exe文件。第一个地方是：Windows\System32\ntoskrnl.exe，另外还有一个地方是Windows\WinSxS\x86_microsoft-windows-os-kernel_31bf3856ad364e35_6.1.7600.16385_none_6c06b7c41576a7d9\ntoskrnl.exe，这就是一个典型的硬连接例子。Microsoft 在文件系统上面对 ntoskrnl.exe 做了一个硬连接，使得 ntoskrnl.exe 能够出现在不同的目录里面，但是只占用了一份 ntoskrnl.exe 的硬盘空间。利用这种机制，有下面的一些好处：

• 同样的文件，只需要维护硬连接关系，不需要进行多重的拷贝，这样可以节省硬盘空间
• 如果涉及文件更新，只需要先在WinSxS 目录里面下载好一个新版本，然后修改 Windows\System32 下面同名文件的硬连接关系，从旧版本的硬连接指向新版本的硬连接，这样就能够快速的完成文件的更新工作，而不需要进行文件的复制，速度也会快不少
• 补丁卸载也是一样的，只需要把硬连接指向改为旧版本就可以了，没有文件替换的问题。而且建立了硬连接关系的文件之间的修改是同步的，因此只要有一方被修改了，另一方也会得到修改

说了这么多，那么如何知道 Windows 目录的真实大小呢？Smallfrogs 提供了一个工具，可以很方便的知道您系统里面有哪些文件是有硬连接关系的，以及Windows 目录下真实的文件大小。

工具可以从 http://www.kztechs.com/hardlink/realwindirsize.zip （请使用右键点击另存为...方式下载）或在本文附件下载到，下载解压缩以后，直接运行就可以开始扫描了。

扫描过程比较漫长，扫描完成以后，会看到下面的提示信息：

另外，在realwindirsize.exe所在目录下，会生成一份文件名叫做LinkedFile.TXT的文件，里面记录了Windows目录下各个硬连接的关系。

如上图所示，我们扫描到了65088个文件，其中，真实的文件有48022个，其他17066个文件都是硬连接文件。真实的文件占用了14981682 KB的硬盘空间，而如果你用资源管理器看Windows目录的话，那么会提示说Windows目录占用了 18244902 KB的硬盘空间。实际上， Windows\system32 目录下的大多数文件都和 WinSxS 目录建立了硬连接关系。

说了这么多，最后总结一下吧：

• 硬连接，一种基于文件系统的同一卷里面的文件快捷方式
• Windows 目录下面大量使用了硬连接技术
• Windows\System32 目录下的大多数文件，都和 WinSxS 目录建立了硬连接关系
• 要检查自己系统Windows目录里面的硬连接，请下载工具 http://www.kztechs.com/hardlink/realwindirsize.zip 自己扫描吧

OK，本次Windows 7 研究就此完成，请继续等待下篇吧！

Windows 7 研究——Windows 7 安装包英文版和中文版的差异揭秘

张康宗（Smallfrogs）
http://www.KZTechs.com

再次提起这个话题，总感觉有点老调重弹。不过为了让更多的“年轻人”了解相关内容，我就说一次吧，关于 Windows 7 安装包英文版和中文版的差异。

从 Windows Vista (NT 6.0)开始，Microsoft 就下大力气完成了Windows 多语言架构的改进。最突出的一点就是，所有的和语言相关的资源全部外置，完成了程序代码和语言的无关性的改变。

什么是语言资源：

所有的字符串信息、带有文字的图片、各种和语言版本相关的介绍性说明材料、帮助文档等内容均属于语言资源。

简而言之，从 Windows Vista 开始，每一个有用户界面的程序至少由2部分组成；程序代码和语言资源。这种设计在 Windows 7 里面继续得以保留。

以英文版系统的Windows 7 里面的记事本Notepad.EXE为例，Windows 目录下的Notepad.exe，要正常运行，还必须有Windows\System32\en-US\notepad.exe.mui的配合才能使用，如果删除Windows\System32\en-US\notepad.exe.mui 文件，记事本将不能启动。

那么，如果我们安装了语言包以后，又会发生什么样的情况呢？

还是以英文版的 Windows 7 系统里面的记事本程序Notepad.EXE为例，在安装中文语言包以后，在 Windows\System32 目录下面多出了一个叫做 zh-cn的子目录，在这个目录下面，也有一个叫做 notepad.exe.mui 的文件。我们可以使用 Resource Hacker 打开这个文件，可以看到各种的简体中文字符串信息，如下图；

换句话说，如果在一个英文版的Windows 7里面，安装了中文语言包，那么其实际上就是一个中文版的Windows 7。只不同这个时候的Windows 7 同时具备了显示英文界面和中文界面的能力。

那好，对于Windows 7的安装包来说，又是怎么样的呢？是不是Windows 7的安装包也是：先安装程序代码组件，再安装一个语言包呢？Smallfrogs 在这里使用了 WAIK 里面的Windows System Image Manager 工具分别把Windows 7英文版ISO里面的 sources\install.wim 和 中文版ISO里面的 sources\install.wim 打开了。利用这个工具，我们可以对 install.wim 的内部结构一览无遗：

如下图，左边的是英文版ISO文件里面的内容，右边是中文版ISO文件里面的内容。

注意下方的Package节点，在英文版ISO里面，首先出现的 Foundation内容，然后LanguagePack和LocalPack，LanguagePack 就是著名的语言包，通过描述内容我们可以看到，在英文版ISO里面出现了一个叫做 x86_Microsoft-Windows-Client-LanguagePack-Package_6.1.7600.16385_en-US 的语言包文件，对应的中文版ISO里面，也有一个叫做 x86_Microsoft-Windows-Client-LanguagePack-Package_6.1.7600.16385_zh-CN 的语言包文件。

看到这里，大家应该明白了，Windows 7的不同语言版本ISO，其实际上唯一的差异只在安装不同的语言包文件。

• 对于英文版的 Windows 7，首先安装的是 x86_Microsoft-Windows-Foundation-Package_6.1.7600.16385 基础包，然后再安装 x86_Microsoft-Windows-Client-LanguagePack-Package_6.1.7600.16385_en-US 语言包
  
• 对于中文版的 Windows 7，首先安装的也是 x86_Microsoft-Windows-Foundation-Package_6.1.7600.16385 基础包，然后再安装 x86_Microsoft-Windows-Client-LanguagePack-Package_6.1.7600.16385_zh-CN 语言包

而对于核心的程序代码文件，无论中文版的 Windows 7 还是英文版的 Windows 7，都是一样的。这就是从 Windows Vista 时代带来的 Windows 语言资源分离的重要内容和体现。

Smallfrogs 2009/08/08

Windows 7 RTM Released

Windows 7 RTM Build 7600.16385 已经正式发布

Windows 7 时代来临了～～

相对于 Windows XP 到 Windows Vista 的改变，Windows Vista 到 Windows 7 的改变是小的，但是却是重要的，Smallfrogs 推荐所有人立即升级你的 Windows XP/Vista 到 Windows 7，去享受最新技术带来的快感！

Smallfrogs 将继续把对 Windows 7的研究心得公布在本BLOG里面，和大家一起分享技术的乐趣！

Smallfrogs
http://www.kztechs.com

HOWTO：为什么Windows 安全中心“恶意软件保护”提示不兼容

张康宗（Smallfrogs）
http://www.KZTechs.com

今天发现，我的Windows Vista SP1、Windows Vista SP2、Windows 7 RC 的安全中心均出现了下面的提示信息：

病毒防护：不兼容

System Repair Engineer 正在运行，但是使用不再受支持的格式将其状态报告给 Windows 安全中心。请使用程序的自动更新功能，或与程序制造商联系以获得更新版本。

 

这是怎么回事呢？

前几天的时候，还都正常啊。我很奇怪，于是开始了一番研究，故事就从这里展开了。

• Windows 安全中心，是从Windows XP SP2 开始引入的一个系统安全状态显示终端。
• 在 Windows XP SP2 或 Windows Vista 里面，和 Windows 安全中心通讯是直接走的WMI接口，WMI名字空间是 root\securitycenter。我们可以使用系统自带的程序 wbemtest.exe 直接打开 root\securitycenter 名字空间，看到 Windows 安全中心内部的一些成员：

class AntiVirusProduct
{
    [key, Not_Null] string instanceGuid;
    [Not_Null] string displayName;
    [Not_Null] boolean productUptoDate;
    boolean onAccessScanningEnabled;
    boolean productHasNotifiedUser;
    boolean productWantsWscNotifications;
    uint8 productState;
    string companyName;
    string versionNumber;
    string pathToSignedProductExe;
};

根据MSDN 博客上面的 Microsoft 相关人员的说明，只需要往这个WMI接口里面填入相应的数据，就能够注册到 Windows 安全中心里面了。

这一切在昨天的时候都是运行着很好的，包括 Windows Vista 或者 Windows 7。但是，今天的现象是怎么回事呢？

通过相关的搜索，在MSDN论坛上面提到了：从 Windows Vista SP1 开始，Windows 安全中心引入了新的名字空间 root\securitycenter2。只有这一句话说明了这个信息。于是 Smallfrogs 开始猜测是不是 Windows 内部的时间炸弹引发了一些内部逻辑，在XXX的时候禁用了早期的 Windows 安全中心名字空间呢？

经过对 Microsoft Defender 和 Nod32 4.0 研究以后发现，果不其然，这2款杀毒软件已经使用了新的名字空间 root\securitycenter2，原先注册在 root\securitycenter 的信息已经丢失了。此后，在Microsoft 知识库里面也发现有一些升级补丁涉及到 root\securitycenter2。

因此肯定：今天的现象是由于安全中心协议变更导致的，由于 root\securitycenter 被停止使用，而 root\securitycenter2 没有被注册，所以出现了上述的不兼容的提示信息。

解决办法：

1. 暂时忽略 Windows 安全中心的提示信息
2. 等待各个杀毒软件厂商升级即可

PS：System Repair Engineer 和Windows 安全中心有交互了？嗯嗯，这是我的测试版本……

HOW TO：从Windows 7 RC 升级到 Windows 7 RTM？

如果使用Windows 7 RTM Build 7600，在Windows 7 RC里面安装，那么当选择升级模式的时候，会提示说不支持。

这次微软很奇怪，以往都是支持从RC升级的，这次不支持的理由我没有能够想清楚，不过下面的办法可以解除这个版本限制：

1. 把Windows 7 RTM 的安装盘里面的全部内容复制到 C:\Win7Source 目录里面；
2. 用记事本打开 C:\Win7Source\Source\cversion.ini文件，把 MinClient=7233.0 改为 MinClient=7100.0，保存；
3. 运行 C:\Win7Source\Setup.EXE 就可以选择升级模式从Windows 7 RC升级了。

我已经在我的笔记本上面实验了这个方法，在经过漫长的3个多小时的等待以后，升级成功完成。另外在升级的时候，建议联网，好像会从网络上下载一个1MB多的什么东东，不知道干啥用的。

Windows 7 研究——MinWin 初步探索

张康宗（Smallfrogs）
http://www.KZTechs.com

<本文欢迎转载，但是请注明来源和作者>

在很早的时候，网上就出现了关于新一代Windows 内核 MinWin 的说明，例如新一代 Windows 核心才有 25M 等等宣传，甚至还出现了一个字符界面构成的Windows 启动画面的图片。在临近 Windows 7 发布之前，Smallfrogs 将把自己所知的一些关于 MinWin 的内容呈现给大家。

在本文开始之前，先说一下 Windows 核心的具体含义吧。实际上，Windows 核心是由用户态模块和内核态模块构成的，换句话说这些模块是整个操作系统最最核心的部分。在Windows Server 2008 里面，诞生了一个 Server Core 安装模式，在这个安装模式下，Windows 没有了资源管理器等大多数 GUI 程序，但是在 Windows Server 2008 里面，Server Core 并不是那么的纯粹，各个组件的模块化还不足以进行更精细化的区分。

如果对Windows 开发稍微有点了解的都知道，Windows 里面的 API 有成千上万，各个 API 之间的关系错综复杂。要剥离出一个更纯粹的 Server Core会显得更加的困难。而 MinWin 的一个重要的目的就是创建一个独立的架构分区（architectural partitions），使之能够独立的构建、运行和测试，而MinWin被定义为一系列的启动和网络所需要的组件的最小集合，也就是说仅仅包括：

• Windows 内核（内核态的Ntoskrnel.exe、内核态的启动装载器、用户态的关键DLL等）
• TCP/IP协议栈
• 设备驱动
• ……

而要完成独立的架构分区，需要对一些关键的系统核心模块进行重构。在整个Windows里面，最最关键的用户态核心DLL模块有那么几个：

• ntdll.dll
• kernel32.dll
• advapi32.dll
• ……

上述几个DLL构成了Windows 用户态核心，而其他的一些DLL，例如Shell32.DLL等都是对上述几个API功能的封装和丰富等，换句话说，如果没有Shell32.DLL，那么系统应该也是能够正常运行的。

在上述的几个DLL里面，原先的分工是这样的：

• ntdll.dll：负责和Windows内核层打交道
• kernel32.dll：提供了文件、进程、线程、内存、堆栈等API，所有的Win32应用程序都会加载这个模块
• advapi32.dll：提供了一些Win32 API高级API，例如：注册表操作、服务操作、ACL操作等

但是在Windows 7里面，因为MinWin的需要，上述API的分工有了一些变化，部分API的实现从一个DLL迁移到了另外的DLL里面，而且还新增了一个DLL：kernelbase.dll。关于新增DLL的用途，今天暂时不用管它，先看看有哪些API的实现有迁移吧。

要判断API的迁移，最简单的办法就是分析PE的输出表，因为所有的Windows基础API的实现都是以__stdcall 方式导出的，只需要对输出表进行分析就知有没有变化了。Smallfrogs 分别对kernel32.dll和advapi32.dll的输出表进行了分析，发现注册表类的API的实现已经从Windows 7之前的advapi32.dll迁移到了kernel32.dll里面。

这是MinWin带来的第一个显著的变化，当然，MinWin 是不会那么简单的，后面一段时间，Smallfrogs 将继续给大家分享自己对 MinWin 的研究结果，例如兼容性问题、虚拟DLL等很多全新的、由 Windows 7带来的变化。

Windows 7 研究——IE8 松散耦合进程框架探索

张康宗（Smallfrogs）
http://www.KZTechs.com

<本文欢迎转载，但是请注明来源和作者>

在2008年8月份IE8 Beta刚刚面世不久的时候，我曾经用极短的篇幅介绍了一下IE8的新的Tab控制模型（详情见：《IE8 新特性分析：IE8的稳定性源自何处》 一文）。今天，我将继续和大家分享一些最近一段时间获得的新的知识。

IE8 松散耦合进程框架，英文原文是Loosely Coupled IE (LCIE)，是一种基于作业（Job）的进程管理方式。这种方式已经逐渐被各大浏览器所采用，例如Google Chrome。

下图是IE8的LCIE框架结构：

作业是Windows 2000引入的一种进程管理方式，可以用一个宿主进程管理多个子进程。管理进程可以给子进程设置很多属性，特别是一些和性能相关的属性，具体可以参考 SetInformationJobObject Function (Windows) 的API说明文档。

当我们安装完IE8以后，打开一个Tab，使用 Process Explorer 会发现，有2个iexplore.exe实例，这个就是最典型的LCIE表现：Tab工作在进程空间里面，有一个独立的框架进程用于管理Tab进程。

如下图所示，我打开了4个Tab，出现了4个Tab进程（进程ID分别为 9000、9672、6052、3056），框架进程的进程PID是7416：

因为LCIE的模型决定了IE的框架和Tab是独立的进程体，因此相互之间是需要通信的，根据Process Explorer的显示，框架进程和Tab进程的通信是使用的ALPC（高级本地过程调用，在Windows内核里面经常可以见到，效率很高）机制（在Windows Vista上面），关于LPC的技术解释，请Google搜索。

我们继续研究LCIE的标签创建方式。当我们新开启一个Tab以后，系统会创建一个iexplorer.exe进程用于和这个Tab绑定，那么我开启10个Tab以后，是10个进程吗？实际的测试结果是：不一定。具体创建多少个Tab进程实际是由IE框架确定的，根据目前已知的结论，IE框架会根据可用的物理内存大小确认最多创建几个Tab进程。

注：默认情况下，我的2台笔记本（物理内存均配置了4GB，可用内存一般在1.5GB左右）在Windows Vista里面，创建的Tab进程最多是5个。

那么，是否有可能控制Tab进程的数量呢？答案是可以的。IE8 Frame在启动的时候，会检查注册表

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main下面的TabProcGrowth键值（键值类型DWORD），利用这个键值，就可以操作IE8的Tab数量了。

关于IE8 LCIE的FAQ：

1、为什么不是每个Tab一个进程，而有一个上限呢？

因为创建一个进程的开销是远远大于创建一个线程的，创建一个进程，需要重新加载所有相关的模块，而且进程间的切换也会带来很大的性能损耗。IE8的LCIE机制在达到Tab进程最多数目以后，后续的新开网页将将采用负载平衡的机制让不同的Tab进程进行处理，以达到资源的最大利用。

2、LCIE模型里面，会话是怎么处理的？我怎么感觉到不同的Tab都使用的是同一个会话呢？

的确，因此Tab进程的出现，会话的处理是比较关注的一个点。在IE8里面，会话是和IE框架绑定的，在这个IE框架下的所有Tab，共享同一个会话，具体来说就是：假设第一个Tab进程访问了msdn.microsoft.com网站并属于了Live ID登录以后，后续新开的Tab进程如果也访问了msdn.microsoft.com网站，那么是共享刚才的Live ID的，除非过期；而且，即使你从开始菜单里面点击IE图标，新创建的窗口也是使用先前的会话的。

3、在LCIE模型里面，如果让不同的窗口使用不同的会话呢？

要在IE8里面，让不同的窗口使用不同的会话，可以点击文件菜单-->新建会话菜单项，使用这个方式，新创建的窗口将采用一个新的会话，以便和之前的会话区分开来。

4、为什么有时候IE8 Tab进程在访问的页面关闭以后，Tab进程还是存在呢？

这是为了性能考虑的，防止用户马上又新开一个窗口，前面说过创建一个Tab进程是需要很多资源的。在默认情况下，IE8的Tab进程在网页窗口关闭以后，将驻留60秒时间，然后再退出。当然，我们也可以通过设置注册表 HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main下的TabShutdownDelay DWORD键值来控制Tab进程的退出时间。注意：TabShutdownDelay的单位是毫秒（1秒等于1000毫秒）。

文末：

IE8相对于IE7来说，无论是进程框架和渲染引擎都得到了极大的改善和优化，而且在各种标准支持方面都比IE7好了不少，虽然IE8不是最快的浏览器，也不是应试分数最好的浏览器，但是无论是兼容性还是安全性方面，都是值得大家去安装的。如果你是因为受不了IE7的慢而使用FireFox或Chrome浏览器的，现在可以再体验一下IE8，相信会比IE7有着明显的改善的，呵呵。

下回，我将继续对Windows 7的一些核心组件撰文，继续分享Smallfrogs对于Windows 7的研究结果。敬请期待。

[Win7] Windows 7 相关研究心得分享启动了

张康宗（Smallfrogs）
http://www.KZTechs.com

由于工作原因，沉默了很长一段时间了，估计很多人都忘记我了吧，呵呵。

在这段时间里面，业界经历在翻天覆地的变化，而Windows也在翻天覆地的变化着，在Windows 7 RC 即将发布之际，我将把近期对 Windows 7 的一些研究心得给大家分享一下，从蛙眼的角度看看 Windows 7 到底有哪些变化。

整个系列文章会比较长，我所关注的重点是兼容性方面的内容，因为这也是我工作中所接触最多的一些点，大部分内容已经经过确认，但是少部分内容是我推测出来的，如果文章中有错误，请大家指出，谢谢。

第一篇：Windows 7 研究——IE8 松散耦合进程框架探索（2009/04/20）

第二篇：Windows 7 研究——MinWin 初步探索（2009/06/01）

第三篇：Windows 7 研究——Windows 7 安装包英文版和中文版的差异揭秘 （2009/08/08）

第四篇：Windows 7 研究——Windows 文件夹的秘密：Windows 目录到底占用了多少真实的硬盘空间 （2009/8/15）

BTW：这篇博文将持续更新，把最新的相关文章的链接加入进来。

WinSxS 混乱导致的应用程序不能启动

张康宗(Smallfrogs)
http://www.KZTechs.com

有人看过下面的MessageBox提示信息吗：

---------------------------
C:\dllsxstest.exe
---------------------------
C:\dllsxstest.exe

由于应用程序配置不正确，应用程序未能启动。重新安装应用程序可能会纠正这个问题。

---------------------------
确定  
---------------------------

如果看到这个错误，那么一定是因为运行库的manifest混乱或破坏导致WinSxS机制无法正常使用从而引起应用程序加载失败。

从Windows XP开始，微软引入了WinSxS机制用于解决DLL版本冲突的问题。解决方法是通过一个额外的清单文件（manifest）记录所需要的运行库的版本号等信息。进程创建的时候，CSRSS进程通过SxS.DLL模块解析manifest文件，然后加载合适的DLL版本。

今天，我这里处理了一个WinSxS版本混乱导致的应用程序无法加载的问题。

环境如下：

• 有一个EXE文件，不依赖任何的运行库
• 有很多DLL文件，分别在EXE文件目录的子目录下
• EXE文件所在目录下有一套安装的VC8运行库
• DLL文件需要依赖VC8运行库
• 因为各种原因，没有使用 vcredist_x86.exe 把VC8运行库安装到Windows\WinSxS目录下面

使用的时候发现，EXE文件加载DLL的时候，总是提示加载失败。DLL无法启动。我用 Process Monitor 监视了一下文件的读写操作，发现EXE文件在加载DLL的时候，CSRSS总是去读取 Windows\WinSxS 目录下的运行库文件，由于没有使用 vcredist_x86.exe 把VC8运行库安装到Windows\WinSxS目录下面，因此DLL加载失败了。

我很奇怪的问题是，为什么总是忽略了EXE目录下的manifest文件，而总是使用 Windows\WinSxS 目录下的文件呢？

以前知道manifest文件可以外置，也可以内置到PE文件的资源里面，难道是内置的问题吗？用Resource Hacker打开DLL文件，果然发现了内置的清单文件。把这个资源结点删除以后，保存退出，然后再使用EXE文件加载这个DLL文件，OK～问题解决了。这次使用的是EXE目录下的运行库文件而没有使用Windows\WinSxS目录下的文件了。

BTW：对于开发人员来说，自然不能编译以后再手工删除这个资源结点，解决方法很简单，把工程的manifest设置里面的 embedded manifest 功能关闭掉，这样编译以后就会出现编译生成的目标文件和一个额外的manifest文件。使用的时候，系统会首先尝试到Windows\WinSxS目录下面寻找文件，如果文件不存在，那么会在EXE文件所在目录下寻找，而不是去DLL所在目录下寻找文件。

问题解决以后，就需要想想问什么只有在部分系统上面出现这个问题了，检查发现：没有问题的系统都使用vcredist_x86.exe 把VC8运行库安装到Windows\WinSxS目录下面了，有问题的系统，发现WinSxS目录下没有运行库文件，自然不能使用了。

目前，很多软件都使用了VC8开发，而且都使用 vcredist_x86.exe 把VC8运行库安装到Windows\WinSxS目录下面，但是有某些软件在卸载的时候，又把这个运行库卸载了，结果就会导致类似提示“由于应用程序配置不正确，应用程序未能启动。重新安装应用程序可能会纠正这个问题”的错误的出现。这是最常见的一种现象。另外还有下面的几种可能会导致WinSxS混乱：

• manifest文件被破坏
• 复制了错误的manifest文件到错误的目录，导致manifest文件里面记录的内容和实际的DLL版本不符

最后，如果你碰到提示“由于应用程序配置不正确，应用程序未能启动。重新安装应用程序可能会纠正这个问题”，最佳的操作方法是看看这个文件依赖的运行库是否齐备，如果不会看，最简单的办法就是重新安装所有的运行库版本到系统里面。

下面是所有常见的32位运行库版本的下载地址：

• 适用于 Visual C++ 2005 开发的程序的运行库版本：http://www.microsoft.com/downloads/details.aspx?FamilyID=32bc1bee-a3f9-4c13-9c99-220b62a191ee&displaylang=zh-cn
• 适用于 Visual C++ 2005 SP1 开发的程序的运行库版本：http://www.microsoft.com/downloads/details.aspx?familyid=200B2FD9-AE1A-4A14-984D-389C36F85647&displaylang=zh-cn
• 适用于 Visual C++ 2008 开发的程序的运行库版本：http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=zh-cn
• 适用于 Visual C++ 2008 SP1 开发的运行库版本：http://www.microsoft.com/downloads/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=zh-cn

如果你不知道你使用的程序是什么版本开发的，那么就全部安装吧，嘿嘿～

BTW：WinSxS 技术从 Windows XP 开始引入，一直发扬到 Windows Vista 系统里面，表现形式就是随着系统使用时间的增加，Windows\WinSxS 目录会越来越大，这一点在 Windows Vista 系统里面会特别突出，因为 Windows Vista 系统的系统文件都是使用 WinSxS 目录存放的，Windows\System32 目录下看到的大部分文件实际上是 WinSxS 目录下文件的一个 Hard Link 而已 :)

Windows Vista RTM BUG？

今天同事反映，我们内部开发的自动化测试平台的一个案例驱动模块在 Windows Vista RTM 机器上发生了一个奇怪的现象，同样的代码在其他的Windows 2000、XP、Server 2003、Vista SP1 上面均工作正常，但是在 Vista RTM 系统上面没法工作。

问题现象是：

• 我们首先使用 CreateDirectory API 创建一个目录
• 然后对这个目录使用 FSCTL_GET_COMPRESSION 控制码设置NTFS压缩属性
• 然后在这个目录下面建立子目录
• 由于父目录已经设置了压缩属性，因此子目录也继承了压缩属性
• 对子目录使用 FSCTL_GET_COMPRESSION 控制码取消NTFS压缩属性
• 结果发现在 Windows Vista RTM 机器上面取消子目录 NTFS 压缩属性的时候 DeviceIoControl API 返回成功，但是实际结果是没有被解除压缩属性。

我把这段代码抠出来写了一个小程序，在下面的操作系统上均进行了试验：

• Windows 2000 SP4
• Windows XP SP1
• Windows XP SP2
• Windows XP SP3
• Windows Server 2003 SP1
• Windows Server 2003 SP2
• Windows Vista RTM
• Windows Vista SP1

发现只有 Windows Vista RTM 系统有这个现象，其他系统均是正常的。而且发现，如果设置压缩属性完成以后，把进程退出，然后再启动一个新的进程用于取消压缩属性，也可以达到预期的效果。但是如果操作是在同一个进程里面，那么问题就肯定出现。

鉴于只有Windows Vista RTM 有这个现象，难道是 Windows Vista RTM 的 BUG？

备注：

1. Windows Vista 已经关闭了UAC
2. 系统是一个干净系统，没有安装任何的第三方软件
3. 登录帐户隶属于 Administrators 组，且机器没有加入域
4. 使用资源管理器做同样操作没有这个现象

由于 Microsoft 没有公布非常详细的 Windows Vista SP1 Changes Log，因此我只能猜测是 Windows 的 BUG 了。但是为啥资源管理器不受影响呢？抽空debug一下看看，也许就知道具体原因了。

最后，还是强烈建议升级到 Windows Vista SP1，不仅仅是改善了性能，在兼容性方面也有很多修正和改善。

RTX 2008 Beta 1 导致 Windows Vista 无法使用 Run as administrator 命令

张康宗（Smallfrogs）
http://www.KZTechs.com

昨天晚上的时候发现，当右键点击Windows Vista的开始里面的快捷方式，选择 Run as administrator 命令的时候，没有UAC提示框弹出，而且consent进程也没有工作。由于这个功能对我非常的重要，立即开始调查。

调查结果如下：

• 所有的 LNK 文件均无法通过右键 — Run as administrator 方式启动
• 控制面板里面的“Change Product Key”点击无效
• 控制面板用户帐户里面的“Change My Environment Variables”点击无效
• 控制面板用户帐户里面的“Configure Advanced User Profile Properties”点击无效
• ……
• 实际上所有和LNK相关的内容，只要是以Run as administrator 方式启动的，都无效，包括使用 Windows API ShellExecute （关于如何使用 ShellExecute 以 run as administrator 方式启动程序，请见《如何将自身进程运行为admin模式》一文）。

看到这个现象，用其他的文件试了试，很正常，因此感觉不是系统内核层面上的问题，而仅仅是LNK文件的文件关联或相关的Shell内容出现错误。

首先检查的是LNK的文件关联数据，但是和原始的数据对比以后，发现没有异常，只不过多了一些软件自定义的Shell扩展。

启动 Process Monitor，对 Explorer.EXE 的行为进行监视，由于内容太多，一时半会找不出头绪，好像没问题……不过没有发现有consent.exe进程创建的记录，因此可以肯定是explorer相关的问题导致的。

再仔细观察了一下LNK文件右键菜单里面的内容，发现一个新增的项目：用RTX发送文件，而且这个项目和Run as administrator 在一组，难道是他？

刚好以前自己写过一个Windows Shell Menus Manager（http://www.kztechs.com/cxtmgr），用它看了看RTX相关的内容对应的文件是 c:\Program Files\Tencent\RTXC\RTXShlMenu.dll，用regsvr32 /u “c:\Program Files\Tencent\RTXC\RTXShlMenu.dll” 命令反注册以后，再次在LNK文件上点击右键，选择 run as administrator，哈哈，UAC弹出来了。

有问题的RTX文件信息：

File Name: RTXShlMenu.dll
File MD5: E61212BD331A32CA86D6B7B81812EB29
Common File Version: 1.0.0.1
Compile Time: 2008.03.21, 09:31:19 [GMT]
Digital Sign: NO

安装包信息：

File Name: RTXC2008Beta01(8.0.050.201).exe
File MD5: 8C334C845B6D590E740C90356DAF2EB2
Common File Version: 8.0.50.201
Compile Time: 2007.04.09, 07:44:33 [GMT]
Digital Sign: Yes.
Signed by [Tencent Technology(Shenzhen) Company Limited]

希望这篇帖子能够帮助碰到类似问题的人，提供一些思路吧。

一个奇怪的不能搜索的现象

今天有一个同事的电脑上出现了问题，表现为不能搜索特定文件服务器上的文件，详情如下：

文件服务器FS和本地客户端是通过VPN连接的（不在一个物理地区），文件服务器的操作系统应该是Windows Server 2003（未经证实）。

在客户端这边，有一台XP系统，访问文件服务器FS的一个共享目录Share，访问方式是直接使用内网的IP访问，登录帐号是一个域帐号，域控制器在文件服务器所在的物理地区。

现象是这样的：

1. 机器A使用Explorer，在地址栏输入\\IP\Share ，登录以后，Explorer 能够列举出共享目录里面的所有文件，而且很正常。
2. 但是列表以后，点击机器A的Explorer的搜索按钮，文件名里面输入任何内容，点击搜索，都会返回搜索到0个文件。
3. 把文件服务器FS的共享目录映射成一个驱动器，在机器A里面的命令行下面使用dir /s 命令搜索，没有问题。但是使用机器A的Explorer搜索隐射盘还是返回0个文件。
4. 使用机器A的Explorer搜索本地磁盘里面的文件，一切正常。
5. 使用机器A的Explorer搜索本地局域网里面的文件，一切正常。
6. 换一台XP机器B，使用同样的访问方式、同样的域帐号访问文件服务器FS的共享目录，使用Explorer的搜索功能搜索，也很正常……
7. ……

折腾了半天，没有搞定。比较奇怪，先记录下来，等有空的时候研究看看 Explorer 的搜索和普通的文件遍历有啥特别之处……

简单看了看机器A的环境，很普通，没有什么不正常的，我抓狂了……

捉鬼记：深入 Norton UAC Tool 实现原理

张康宗（Smallfrogs）
http://www.KZTechs.com

刚刚看到 Asuka 的一篇文章《Norton UAC Tool原理剖析》，文章中已经很好的解释了Norton UAC是如何做到 Don't ask me again的，从开发的角度上看，这个要实现不是很难，但是我感兴趣的地方是： Norton 是如何把 Microsoft 的 Consent.EXE 给截获的，如果能够截获 Consent.EXE，就很容易实现 Norton 的功能了。

下面就让我带领大家深入这个工具的实现细节吧：

1. 下载安装过程很简单，不停的Next就可以了。
   
   
2. 安装完成以后，我找了一个会启动 UAC 的软件试了试，果然出现了 Norton 的 UAC 提示框。Microsoft Windows Vista 的那个 UAC提示框不见了。当时很诧异！！
   
   
3. 当 Norton UAC 提示框正在询问的时候，用 Process Explorer 看了看进程，惊讶发现 Process Explorer 进程列表里面显示的是 Symconsent.EXE，但是这个进程的相信信息里面 Image 指向的是 Windows Vista 的 Consent.EXE。惊讶～～！
   
     
   
   发现上述的内容，Smallfrogs 第一反应是想到碰到鬼了～
   但是根据 Smallfrogs 多年的经验分析，得出这个“鬼”一定是人为的。看来 Norton UAC Tool 这个东东有搞头，于是乎马上振作精神，开始进一步的分析。
   
   
4. 启动 Process Monitor，开始检测进程的创建过程，果然，鬼情出现了：在触发 UAC 的时候，Consent.EXE 进程加载的时候，Consent.EXE 会执行一个 LoadImage 动作，但是发现 LoadImage 对象不是 system32\consent.exe，而是 system32\symconsent.exe，如下图：
   
    
   
   这是一个非常重要的现象，根据这个现象，Smallfrogs 当机立断，有东东做了 Hook。
   
   
5. 使用 Image File Execution Options 技术，对 consent.exe 设置了调试器通知，确认在触发 UAC 的时候，系统的确调用了 consent.exe 进程，而且进一步发现，调试器模式下，挂接 consent.exe 进程以后，Norton UAC Tool 的提示框没有出现。
   
   Smallfrogs 当时想：这只鬼很神奇啊～～难道要逼迫 Smallfrogs 做复杂、烦琐的内核调试吗？Smallfrogs 环顾四周，周围只有一台用了2年的本本，看来又要伤机器了。
   
   
6. 正在准备开启VMWare的时候，Smallfrogs 突然想起忘记看看安装程序做了什么事情了，于是乎对安装程序 NUACx86.exe 进行了一个简单的分析，发现不就是一个普通的EXE嘛，而且这个EXE不是 symconsent.exe，看来这个EXE 有隐藏的东东。在 Exescope 的帮助下，果然发现 NUACx86.exe 有附带几个资源二进制文件，解出来一看，哈哈，这只鬼终于现身了。
   
   Norton UAC Tool 安装了一个文件过滤驱动，叫做 SymAFR，当然，这个驱动通过了 Microsoft WHQL 认证（这只鬼做的还挺标准的），数字签名日期是 2008年2月29日 22:47:48。驱动的文件名叫做 SymAFR.sys。
   
   Norton UAC Tool 可能是这样实现的（有不对的地方请大家指正）：
   
   1、当 UAC 触发的时候，Windows Vista 尝试加载 system32\constent.exe。
   
   2、SymAFR.sys 截获了这个操作，然后转而让系统加载 symconstent.exe。
   
   3、symconstent.exe 成功的代替了 Windows Vista 的 constent.exe 进程，后面的事情就简单了。
   
   4、验证方法很简单，执行 sc stop symafr 命令以后，再看看你还能够看到 Norton UAC Tool 的提示吗？呵呵。
   

Smallfrogs 评论：恩，这是一个非常巧妙的方法！实现简单，稳定，有效～

注意：Norton UAC Tool 是会把每一个触发 UAC 的程序的信息上报给 Norton 信息收集中心的。

 --------------------------------

20080916 Update:

1、原文写的是 IEFO 劫持技术为笔误，实为 IFEO，即 Image File Execution Options
2、Exescope 是一个查看资源文件的工具，类似的还有 Resource Hacker 等
3、细心的朋友会发现，我的第一副截图里面的参数和 Asuka 的截图的参数不一样，他的截图里面指向的是一个 XML文件，针对这个问题，我做了一些分析，发现：当Norton UAC Tool 出现的时候，如果点击 Cancel，会创建一个新的 Symconsent.exe进程，新的进程的参数就是 Asuka 发现内容。新创建的 Symconsent.exe 进程应该是用于上报数据用的。感觉Gdier的报告！！