IE8 新特性分析：IE8的稳定性源自何处

MS宣称IE8增强了很多稳定性方面的改进，今天我抽了点时间，对这个问题进行了一个分析。

从Windows 2000开始，Windows提供了一种新的机制对多个进程进行统一的管理。这种机制被命名为Job（作业）。作业的一个最大特点是能够对一个进程组进行统一的管理。

对比之前IE版本的多标签页实现，之前版本的每个Tab页是基于线程的方式进行的，这种方式最大的问题是一旦某一个线程发生问题，整个IE进程都会出现问题。而且这种问题是很难彻底解决的。在IE8里面，MS终于把Job（作业）的思想进行了一次比较大规模的运用，每一个（或几个）Tab页会对应一个进程，然后有一个总的进程进行管理（如下图）

这种设计的好处就是一个Tab崩溃以后，只会影响这个Tab，对于其他的Tab是不影响的。同时，最外面的框架进程能够知道子Tab的情况，也就能够很好的实现“灾难恢复”了。

下面是父框架进程和子进程的启动参数的不同，可以看到，Job里面的进程是通过一些特殊的参数进行启动的。

当然，IE8的这种结构也带来了一些问题：

• 从开发的角度上看，带来的最大问题就是进程间的通信和管理问题，不过我相信，这一点对于恐龙级别的MS来说是小菜一碟了。
• 从用户的角度上来看，进程对资源的消耗还是很大的。换句话说，同样的浏览模式，IE8对内存资源的消耗应该会大于IE7或者更早的版本。换来的好处是更加的稳定。

IE8，Good！

Smallfrogs
http://www.KZTechs.com

Hyper-V 网络故障存档

上周，我在公司环境里面部署的2台Hyper-V RTM服务器里面，有一台出现了问题，问题现象是：虚拟机里面的网卡无法从DHCP服务器获得IP地址，在虚拟机里面使用 ipconfig /renew 命令，报告无法找到 DHCP 服务器，重启虚拟机也无法解决问题。

整个过程是这样的：

1. 我的一台基于Realtek 网卡的Hyper-V服务器外接的交换机出现问题，导致Hyper-V服务器断网了，同样，Hyper-V里面运行的虚拟机的网络也断了。这台Hyper-V服务器和里面的虚拟机的IP获取方式均是通过外部的DHCP服务器获取的。
2. 经过数十分钟以后，网络恢复了，Hyper-V服务器的网络恢复正常，但是奇怪的是，3台虚拟机里面的网络都未能恢复。
3. 我先怀疑是虚拟机的问题，于是用ipconfig/renew命令和重启，均未能维护网络。
4. 由于Hyper-V服务器上还运行着其他自己编写的服务端程序，不能重启系统，于是我重启了Hyper-V的网络管理服务，结果无效。
5. 最后不得已，我重启了Hyper-V服务器，重启以后，虚拟机里面的网络终于恢复了。

由于当时的时间很紧，我没有研究具体的原因，仅仅是找到了一个解决方法，今天把过程记录下面，大家可以看看具体原因是怎么回事？我目前也不知道。只不过感觉和网卡有关，因为我另外一台使用的是Intel网卡Hyper-V服务器，就没有碰到类似问题。

AppInit_Dlls，一个特殊的注册表键值

Smallfrogs
http://www.KZTechs.com

如果你对计算机安全有所了解，那么各种各样的注册表启动项应该会有所了解，今天我会细述一个很著名的启动项：AppInit_Dlls键值。

AppInit_Dlls键值位于注册表 HKLM\Microsoft\Windows NT\CurrentVersion\Windows下面，相对于其他的注册表启动项来说，这个键值的特殊之处在于任何使用到User32.dll 的EXE、DLL、OCX等类型的PE文件都会读取这个地方，并且根据约定的规范将这个键值下指向的DLL文件进行加载，加载的方式是调用 LoadLibrary。

验证方法有很多，最容易想到的就是使用调试器，在LoadLibrary调用的时候下断点，你会发现User32.DLL读取了这个键值并且使用了LoadLibrary去调用这个键值指向的DLL文件。一个更好的方法就是看看 KB197571 的介绍了。

AppInit_Dlls的键值是一个非常危险的键值，从某种程度上来说，这是一个Windows最容易被人利用的漏洞，因为只要有任何的恶意软件在这里进行了修改，那么就意味着任何使用到User32.DLL的进程都会被AppInit_DLLs指向的DLL所注入。因为进程内部的DLL是共享整个进程空间的，因此意味着进程里面的DLL是可以控制整个进程的行为的。由于User32.DLL是一个非常非常通用的DLL，它提供了大多数Win32用户界面、消息相关的功能，只有极少数的程序不会使用User32.DLL，因此一旦有恶意软件修改了AppInit_Dlls键值，那么整个系统都有可能处于非常危险的状态。

众所周知，Windows服务程序的启动时机是可以非常早的，往往在用户登录之前就完成启动了，而这个时候最常见的Run键值还不一定被处理完，而且Windows服务程序拥有相当高的权限（默认是Local System，可以对系统里面所有的资源进行操作），因此如果一个恶意软件被加载到Windows服务里面，那么是会非常危险的。前文提到，任何进程使用了User32.DLL，都会对AppInit_Dlls键值指向的DLL进行加载，如果是一个Windows服务程序，也不例外！

由于AppInit_Dlls是一种系统全局性的Hook（system-wide hook），要规避此类的Hook的确很困难，虽然使用驱动程序进行保护能够规避此类问题，但也不是非要使用驱动程序进行处理的。前文说过，只有当使用到User32.DLL这个模块的时候才会触发读取AppInit_Dlls指向的DLL，如果不使用User32.DLL，那么AppInit_Dlls是不会被使用到的。但是要让一个程序不使用User32.DLL会变得非常困难（命令行窗口没有使用User32.DLL），因为任何的窗口、消息都和这个模块有关，为了保证有良好的用户体验，100%的窗口程序都和这个模块有关。从开发角度来说，最好的一种解决办法就是将程序功能逻辑和界面逻辑完全分离，功能逻辑模块负责功能，界面逻辑模块负责界面显示，2者之间采用IPC机制进行交互，功能逻辑模块不依靠User32.DLL,，而且作为独立进程进行处理，这样就可以规避AppInit_Dlls造成的Hook了。

类似的Windows安全相关的缺陷点其实还有很多的，这些缺陷点的来源是为了保证向下的兼容性。相信MIcrosoft已经发现并正在修补这些地方，从Windows Vista上可以看到，AppInit_Dlls的键值在Windows Vista上是不起作用的，因此在Windows Vista里面，这个键值已经被抛弃了（改用另外一个键值执行类似的功能，但是增加了基于UAC的安全防护）。

Hyper-V RC1 升级补丁安装记

惭愧啊，本blog很久不更新，都长草了。

最近几个月实在忙得厉害，今天抽出1个小时更新一下最近的流水账吧。

由于工作环境的需要和出于对新技术的追求，最近我一直在研究基于硬件级别的虚拟机，说是研究，实际上还停留在很肤浅的应用层次。研究的对象是 Windows Server 2008 里面的Hyper-V虚拟机组件。

由于今天时间的关系，关于Hyper-V虚拟机组件的一些心得今天就没有时间和大家分享了，今天提及的问题是关于 Hyper-V RC1 升级补丁的安装问题。

Hyper-V RC1 补丁放出来很长一段时间了，我在发布的第2天就下载并进行了安装，安装过程进行了重启，重启以后，当时我很惊讶的发现虚拟机启动的时候还是显示着 RC0 的字样，当时我猜想是不是MS的显示错误，也就没有多关注，认为我已经把Hyper-V RC1补丁安装成功了。

但是今天我检查 WindowsUpdate 日志的时候，居然发现有一个Fail。一查，居然是在安装 Hyper-V RC1 的时候报告的安装失败。错误代码是：0x80070020。

既然安装失败了，那好，我再来安装一次，运行RC1安装包，一切正常的操作结束以后，重启以后发现还是提示安装失败，比较奇怪哦。

第二次尝试，把正在运行的2个虚拟机关闭，运行RC1安装包，一切正常的操作结束以后，重启以后发现还是提示安装失败，大惊。

算上第一次的失败，安装Hyper-V RC1升级包连续失败了3次了，好奇心油然而生，我就不信我搞不定这个补丁的安装。也罢，祭出本人法宝：Microsoft Exchange Server Error Code Look-up Tool，查询看看 0x80070020 错误号代表的字符串含义，查询到的结果是 STIERR_SHARING_VIOLATION，恩，共享违例。

知道错误号的详情以后，我就知道安装失败的原因了：安装的时候文件没法替换成功。解决方法也很简单：

1. 关闭虚拟机；
2. 停止Hyper-V相关的3个服务；
3. 将上述3个服务的启动类型从自动改为手动；
4. 运行Hyper-V RC1 升级包安装

执行上述操作以后，重启以后，哈哈，成功升级到Hyper-V RC1，然后再把3个服务启动类型设置为自动，启动这3个服务，启动虚拟机，一切恢复正常。

再回过去看看KB知识库的描述 KB450049，上面写的是：

...

All virtual machines must be shut down correctly before you install the Hyper-V Release Candidate 1 update

...

仅仅执行上述操作好像不行啊，不知道这篇KB的作者有没有自己尝试过呢？呵呵。

顺便抱怨一点的是，Hyper-V虽然提供了上层和底层两套API接口，底层的接口层次太低了，我不需要这么低的，而对于上层的接口，功能不够，虽然是基于WMI的，但是我跟喜欢纯C的接口类型，不知道是否是因为我跟不上时代的进步了。

BTW：Hyper-V RC0 挺稳定的，我的测试环境部署了2套虚拟机（Windows XP SP3 和 Windows Vista SP1），每天这2个虚拟机里面的工作环境会执行非常复杂的任务，每天需要从6：00——24：00连续执行任务，而且有大量的重启任务和高负载任务，但是经过这么多天的试用，运行Hyper-V机器没有发生过任何的不稳定情况，还是很不错的。

下次，我会进一步把现阶段学习到的知识分享给大家，时间上我尽可能在近期完成吧，敬请期待。

Smallfrogs
http://www.KZTechs.com

Microsoft Windows Vista UAC 之数字签名认证

Smallfrogs[张康宗]
http://www.KZTechs.com

2007年12月份的时候，我曾经撰写过一篇文章《Windows Vista UAC 和 可信任安全》（http://blogs.itecn.net/blogs/smallfrogs/archive/2007/12/31/windows-vista-uac.aspx）。文章中对4种UAC提示框分别作了一个说明，今天，我们继续这个话题，说说UAC提示框里面的数字签名认证部分的内容。

Windows Vista里面数字签名认证对于用户层和内核层是不同的，这一点我提前说明一下。

众多周知，UAC的用户态提示框是consent.exe进程触发的。UAC提示框会检查进程的数字签名信息，对于被信任的进程会显示绿色（系统模块）或者灰色（有数字签名的第三方模块），对于未知的数字签名信息显示黄色，对于被阻止的数字签名信息显示红色。

那么Windows是如何检测数字签名的呢？实际上，Windows内置了很多受信任的根证书，只要使用这些根证书对文件进行数字签名签署操作，就可以让Windows Vista这个文件所信任。

用KZTechs.COM - FileDigitalSignVerify工具扫描Windows Vista Windows目录，会发现所有的系统文件都是有数字签名的，签署者可能是 Microsoft Windows，也可能是 Microsoft XXX。对于使用Microsoft Windows证书签署的模块，UAC提示框一定是绿色的。如果不行，可以运行 regedit.exe 看看 ^_^

但是，有一个特例：IExplore.EXE。如果你用 Run as Adminisrator 方式启动IExplore.EXE，你会看到一个黄色的UAC提示框。

难道是IExplore.EXE没有数字签名？不，IExplore.EXE也有数字签名的，用KZTechs.COM - FileDigitalSignVerify (http://www.kztechs.com/filedsv/)工具可以清楚的显示数字签名相关信息以及证书链信息。

下图是使用 KZTechs.COM - FileDigitalSignVerify 工具 1.2 版本对 regedit.exe和iexplore.exe这2个文件的数字签名信息进行检查：

绿色部分是对iexplore.exe检查的结果，下半部分是对regedit.exe检查的结果。-p 参数是显示证书链信息。

从上图的证书链可以看到，这2个文件都被Microsoft Windows的数字签名所签署，而且证书是有效和合法的。而 Microsoft Windows 证书是由 Microsoft Windows Verification PCA 证书颁发的，而 Microsoft Root Certificate Authority 证书颁发了 Microsoft Windows Verification PCA 证书。Microsoft Root Certificate Authority 作为根证书，是被系统所信任的。

那么为什么以Run as Adminisrator 方式启动IExplore.EXE，你会看到一个黄色的UAC提示框？

我用google进行了相关搜索，结果是：未知

难道是Microsoft BUG？

Smallfrogs
http://www.KZTechs.COM

Windows Vista SP1 清理工具 vsp1cln.EXE 揭秘

本文含有危险动作，仅供学习使用。本文所列数据或方案未经严格测试，仅供参考。

Microsoft在Windows Vista SP1 WAIK里面附带了一个新的工具：vsp1cln.EXE。这个工具是用于：在Vista RTM环境里面安装SP1之后，将Vista RTM文件清理用的。主要是给那些不再卸载Vista SP1的用户。

这个工具有594KB，体积不小，但是我更关心的是他的实现原理，经过简单的分析以后发现，vsp1cln.EXE的实现原理很简单，vsp1cln.EXE内置了所有的Vista RTM文件列表数据。

用资源编辑工具打开vsp1cln.EXE，会发现一个资源ID为256的节点，展开一看是一些很熟悉的字符：

对Windows熟悉的人一看就知道上述字符串是WinSxS的命名方式，换句话说vsp1cln.EXE的主要清理功能的数据来源就是上述列表。上述列表每一行对应一个Windows\WinSxS下的子目录。我统计了一下上述列表所对应的子目录全部加起来以后的文件大小：1445MB，基本符合执行vsp1cln.EXE以后的磁盘空间增加范围。vsp1cln.EXE的基本逻辑就那么简单，但是从引入表可以发现，vsp1cln.EXE实际上还会执行其他的动作，删除文件仅仅是一个中间的过程而已，呵呵。

Smallfrogs
http://www.KZtechs.com

Internet Explorer 7.0 的安全模式

Windows 操作系统有安全模式，这一点大家都清楚。但是在IE7里面，Microsoft也引入了一种针对IE的安全模式。

如果我的记忆没有发生错误，那么从XPSP2开始，Microsoft就在IE里面引入了IE Addons管理功能来管理加载在IE里面的插件。

通过这个IE Add-ons设置，可以管理所有加载在IE里面的插件。

但是一个正常的IE里面，会存在很多很多很多的Add-ons，其中有微软的，也有第三方的。一个一个禁用显得非常麻烦，所以在IE7里面，Microsoft增加了一个开关用于控制IE add-ons。

在命令行提示符下运行：
"C:\Program Files\Internet Explorer\iexplore.exe" -extoff

将启动一个IE7的特殊模式：无插件模式。

在这个模式下，所有的插件将全部临时被禁用。而你不再需要一个一个的在add-ons界面里面禁用插件了。

Smallfrogs
http://www.kztechs.com

Windows Vista SP1 = Windows Server 2008

不知道大家是否已经安装了Windows Vista SP1和Windows Server 2008。作为Windows Beta Tester，Smallfrogs 很早就安装了 RTM 版本的 Windows Vista SP1和Windows Server 2008。

安装完成 Windows Server 2008 以后，按照惯例，我首先会检查各个重要文件的版本号，结果发现：Windows Server 2008 RTM版本的系统重要文件的版本号、MD5值和 Windows Vista SP1 RTM 完全一致！

换句话说，Windows Server 2008 和 Windows Vista SP1 都建立在同一个平台上面。如下图所示：

依靠上述的层次结构，Microsoft能够大量的简化软件的研发代价，对于底层软件的开发商来说，也能够降低大量的开发和测试代价，对于用户来说，由于Windows 体系架构决定了大量的底层功能是在Core里面完成的，因此对于用户来说，Windows Vista SP1 和 Windows Server 2008 的底层功能和底层性能是完全一样的。换句话说，Microsoft是利用各种注册表设置和上层的文件差异来区分 Server 版本和 Client 版本的。

Smallfrogs
http://www.KZTechs.com

[2007/02/16 20:54 Update]
我简单统计了一下，总共有 3965 个PE文件（EXE、DLL、SYS、OCX等）文件是一样的，其他非PE文件我没有统计。

另外，Windows Server 2008 RTM Symbols 已经放出，从 Symbols 分析也可以得出 Windows Server 2008 和 Windows Vista SP1 底层文件完全一致。

Windows Vista UAC 和 可信任安全

Smallfrogs[张康宗]
http://www.KZTechs.COM

Level 200

UAC，Windows Vista 里面重要构成部分。对 Windows 安全保护起着绝对重要用途。

但是，UAC 不等于绝对安全，当你碰到UAC提示框的时候，请千万小心后面的陷阱：

众所周知，UAC提示框触发的时候，Windows 会检测新创建进程映象文件的数字签名：

• 如果新创建的进程的数字签名被阻止了，那么会显示一个红色的提示框：

• 如果新创建的进程没有合法的数字签名，那么会显示一个橘黄色的提示框。

• 如果新创建的进程拥有一个受信任的第三方数字签名，那么会显示一个灰色提示框。

• 如果新创建的进程拥有一个受信任的Microsoft数字签名，那么会显示一个绿色的提示框。

随着今后Windows Vista用户量的增多和培训的努力，大多数用户对于UAC的提示框都产生了一种条件反射：对于灰色或者绿色的UAC提示框完全信任，直接点击Continue按钮了。

这种做法产生了一种严重的安全问题点：UAC检查的是新创建的进程的映象文件。如果这个新创建的进程通过了UAC检查，那么他将获得完全的管理员权限，也就是说这个新创建的、通过UAC检查以后的进程，再创建其他的子进程，将不会触发UAC提示。

换句话说，如果利用某种手段，就可以让一个危险程序隐蔽的运行起来，而用户看到的UAC提示框不是直接针对这个危险程序的。

操作步骤：

1. 在《如何将自身进程运行为admin模式》文中我说过，利用ShellExecute可以创建一个显式需要完整管理员权限的进程。
2. 因此，我创建了一个Demo程序，显示的将命令行解析器 cmd.exe 创建为拥有完整管理员权限的进程。
3. 先前说过，当一个进程拥有了完全管理员权限以后，它创建的子进程即使会触发UAC动作，也不会看到了。利用这个特性，我的Demo程序成功的将显示需要完整管理员权限且一定会触发UAC提示的 SREng 主程序创建起来了，且看到的UAC提示不是 SREng 的。

代码片段：

TCHAR   szPath[] = _T("c:\\windows\\system32\\cmd.exe");
TCHAR   szParam[] = _T("/c start d:\\Smallfrogs\\Codes\\SREng\\Product\\SREngPS.EXE");

ShellExecute(NULL, _T("runas"), szPath, szParam, NULL, SW_SHOW);

编译上述代码，运行以后会看到一个很有意思的现象：我希望运行SREng，但是不想看到SREng 的UAC，因此我用 cmd.exe 的UAC代替了SREng的UAC提示（如下图所示）：

大多数用户看到上述的UAC提示框的时候，都会点击Continue按钮，因为UAC提示框是绿色的，很少有用户会点击 Details 按钮，因为这个按钮很不显眼。但是当我们点击Details按钮以后，我们会看到别有一番天地：

Details里显示：程序利用 cmd.exe 的 /c 参数创建SREng进程，而 cmd.exe 又被显示的被赋予完整管理员权限，因此  cmd.exe 创建的 SREng 进程也继承了 cmd.exe 的管理员权限，且不会出现 UAC 询问对话框。

利用上述方法，UAC 提示框被成功替换了。

解决方法

既然我今天公布了这个方法，那自然会公布相应的解决方法：碰到UAC提示的时候，切记一定要点击 Details 按钮，看看命令行参数。如上图那样，如果看到 cmd.exe 后面跟了一些不属于预期内容的参数，请不要点击 Continue 按钮，否则UAC这层脆弱的防护措施就失效了。

强烈建议每次看到UAC提示框，无论什么情况，都点击Details按钮看看，以免恶意程序神不知鬼不觉的被运行了。

Smallfrogs
http://www.KZTechs.COM

IE7 for Windows Vista 内存泄漏？

自从Windows Vista RTM的那天起，我的工作系统就换为Windows Vista了。

运行Windows Vista的机器配置应该算不错了，除了显卡一般以外，2G的物理内存以及足够Windows Vista流畅运行了。

但是我对 IE7 for Windows Vista 却异常郁闷，我明显的感觉到 IE7 for Windows Vista 有内存泄漏。

表现：

1. 打开一个IE进程，主页为about:blank，检测这个时候的内存占用。
2. 新建一个标签页，主页为about:blank，检测这个时候的内存占用。
3. 关闭刚刚新建的标签，检测这个时候的内存占用。
4. 重复2和3动作多次以后，观察内存占用曲线，会发现呈现的是一个递增的曲线。我知道可能有人会解释说是缓存的缘故，但是即使是缓存也不应该出现递增的趋势的，因为我已经把自己创建的新Tab关闭了。

下图是我运行IE近20分钟以后，打开多个TAB，然后关闭以后的内存占用量：

Working Set 居然占用了 200 多M。有人可能认为是IE的插件导致的，我最初也是怀疑是IE的插件导致的。但是当我使用插件管理器把所有第三方插件全部禁用以后，观察，内存还是呈现递增趋势。

内存递增不是最关键的问题。最麻烦的问题是：

当内存使用量上升到一定程度是，就不能再创建任何新的窗口了（这里说的窗口表示所有的窗口程序），必须关闭一些标签才能打开新的窗口（例如任务管理器）。

窗口的限制应该是Windows Vista 自身的一个机制导致的，我目前没有找到一个能够量化的指标。不过在我机器上，当IE进程的Working Set 到达 280M 左右的时候，我就不能够再创建任何窗口程序或者新建IE的标签页了。这个时候很有可能没法正常的关闭IE的全部标签页，最后我的解决方法是：结束IE进程。

由于IE这个麻烦的内存泄漏（至少我认为是这样的），我不得不写了一个小程序常驻内存，检测IE进程的内存使用量。如果达到一定的阀值就提示我准备关闭现有的IE进程，新建一个新的IE进程了。

Smallfrogs
http://www.KZTechs.com

如何将自身进程运行为admin模式

张康宗
http://www.KZTechs.COM

Level:300

在Windows Vista里面，进程是分权限级别的。Windows会根据manifest内容、Windows Installer detection、兼容性数据库等方法判断一个进程是否需要一开始就运行在完整admin模式下。

但是不是所有的程序一开始就需要运行在完整admin模式下的，例如任务管理器TaskMgr.EXE。在Windows Vista里面，启动任务管理器以后，默认只能显示当前账户相关的进程信息，只有当点击下面这个按钮并回应UAC提示以后才能显示所有用户的进程信息：

请注意上面这张图片，Show processes from all users 按钮前面有一个Windows 安全中心的图标。这个表示这个操作需要触发UAC。这个倒是没有什么特别的。问题的关键在于：TaskMgr是怎么触发UAC的？

我们知道，一个没有完全admin权限的进程是没法直接创建更高权限进程的，也就是说一般权限下的进程是没法直接创建完全Admin权限进程的。因此CreateProcess API函数肯定是不能使用的。如果使用CreateProcessAsUser函数，那么需要提供一个比较高的令牌才能完成，这个需要有额外的来源，而TaskMgr显然不具备这种能力。那TaskMgr是怎么完成这个神秘的动作呢？

上述问题我思考了数个月，上网搜索也没有搜索到有价值的内容。直到昨天晚上才有空去调试一把，看看到底是怎么玩的。

我用windbg attach到 taskmgr 进程上，然后把所有的进程创建相关函数全部设置了断点，然后点击Show processes from all users 按钮，结果ShellExecuteExW函数被断下了，难道ShellExecuteExW有什么特殊的地方吗？查阅最新的MSDN关于ShellExecuteExW的说明文档，什么介绍都没有。是断点有问题吗？

继续使用windbg单步调试，当程序执行到下图的时候，有一个看起来很关键的函数调用：

call    SHELL32!ShellExecuteNormal (7656e6ce)，看到这个名字我的第一个直觉是这个是真正的执行函数，前面还有很多操作仅仅是一些检查步骤。当执行完call    SHELL32!ShellExecuteNormal (7656e6ce)指令以后，UAC框弹出了。看到UAC框的弹出，我已经可以确认任务管理器是使用ShellExecuteExW某个在MSDN上面没有公开的操作触发UAC的。根据前面的描述，call    SHELL32!ShellExecuteNormal (7656e6ce)指令是一个关键指令，因此需要检查call    SHELL32!ShellExecuteNormal (7656e6ce)指令之前的参数操作。

呵呵，这回我盯上了push esi指令了。

windbg里面查看esi对应的内存内容以后发现可能是一个结构体，由于是ShellExecuteExW函数里面执行的，因此我猜测这个结构体是 SHELLEXECUTEINFO，对照SHELLEXECUTEINFO结构体的定义，果然和esi内容相符。最后一步就是检查结构体里面各个参数的情况了。当我发现LPCTSTR lpVerb指向的参数内容（db 0xe5d93c命令）是“runas”这个字符串的时候，Taskmgr 将自身提示为完全admin权限的方法也就揭晓了：

在Windows Vista里面，ShellExecuteExW lpVerb的参数可以传入runas命令，使得系统调用 ShellExecuteExW  的时候，会强制将目标文件以完全admin模式启动，即使目标文件的manifest没有申明需要完全admin权限。

效果等同于在目标程序上右键点击，然后选择 run as administrator 菜单内容。

幕后：当全部搞定以后，我上网google了一下，发现这个方法早有人提及了，而且还是在 Vista Compatibility Team Blog 上面，我花的1个多小时全部白费了，为啥先前都没有搜索到呢？？郁闷。

Windows® Internals, Fifth Edition

这段时间太忙了，一直无暇上来写东东，今天抽空上来露个脸，做一个广告：

Windows® Internals, Fifth Edition is coming soon...

 
不知道大家是否看完Windows Internals Forth Edition了？现在，第5版就快出了，Are you ready?

关于Windows® Internals, Fifth Edition 的介绍，请看：这里

Delve inside the Windows kernel with noted internals experts Mark Russinovich and David Solomon, in collaboration with the Microsoft Windows product development team. This classic guide—fully updated for Windows Vista and Windows Server 2008, including 64-bit extensions—describes the architecture and internals of the Windows operating system. You’ll find hands-on experiments you can use to experience Windows internal behavior first hand, along with advanced troubleshooting information to help you keep your systems running smoothly and efficiently. Whether you’re a developer or a system administrator, you’ll find critical architectural insights that you can quickly apply for better design, debugging, performance, and support.

写在金山软件在香港上市之前

在这个技术BLOG里面写这个文章好像和我的这个技术BLOG总体氛围不符，不过我不这样看，因为下面说的事情可能是中国软件业的一件不小的事情。

再过几个小时，金山软件就要在香港联交所上市了，股票代号（HK:3888）。

金山软件有限公司，自1989年将我们的第一款办公软件产品WPS 1.0投放市场以来，目前已经成为中国最知名的软件企业之一，中国领先的应用软件产品和互联网服务供应商。金山软件在珠海、北京、成都、大连四地分设研发中心，2005年成立日本合资公司。公司目前主要涉及软件和网游两大核心业务，创造了WPS Office、金山词霸、金山毒霸、剑侠情缘、封神榜等众多知名产品。同时，金山旗下拥有国内最知名的大型英语学习社区爱词霸网（http://dict.iciba.com）以及大型在线游戏交流社区逍遥网（www.xoyo.com）。2006年8月金山软件获新加坡政府直接投资的全球性投资管理公司GIC、英特尔投资和新宏远创基金的大规模投资。新注入的资金将用于加速金山的发展，实施其技术立业和国际化战略。

上面这段文字是金山软件官方网站上的介绍，我不清楚这里有没有人没有听说过金山软件公司这个名字的，如果你没有听说过，那么我认为你的计算机水平还没有入门，呵呵。

作为国内知名的通用软件厂商，金山软件公司出品的软件已经相当多了，我这里虽然没有具体的统计数字，但是我们可以从另外一个角度来验证金山软件的知名度问题：

由于国内现状，大多数人机器里面安装的软件还是盗版的。如果你有幸在盗版软件市场溜达一圈以后就会发现，会有很多软件合集的出现，这些合集里面一般都有大量的知名软件，其中肯定会存在一款或者一款以上的金山软件出的产品。此外，还有大量的金山软件产品合集出现。

我想，制作盗版软件光盘的人肯定不是傻子。为了能够更好的把货卖出去，我相信他们在选择盗版对象的时候一定会选择知名软件或者受大众喜好的软件，否则生产出来的盗版软件是没法卖出去的。我在这里不是宣传盗版软件，我希望每个人机器上使用的软件全部是正版的。我在这想表达的是我们是能够从盗版软件的流行动态里面看到一个产品的兴衰成败的，当一个软件非常流行的时候，盗版率就会非常高，反之。

从1989年金山软件到现在2007年，19年里面，我不止一次的听说金山软件即将上市的消息，今天，这个消息终于可以成为现实，祝贺他们。

虽然金山软件上市对于我个人来说并没什么直接的影响，但是我认为，代表中国老一辈软件公司的金山软件公司，他的上市，绝对是可以计入中国软件业大事记的，因为在中国，到今天为止，创办于20世纪80年代的中国软件公司还有多少家继续存活呢？

在这历史性的时刻到来之前，写上一笔以纪念今天这个也许能够进入中国软件业大事记的日子。

另外，从Sina上看到的消息是，Sina将对本次金山软件上市过程做全程的连线报道（Sina关于金山软件上市的专题：http://tech.sina.com.cn/focus/kingsoft_HK/index.shtml）。

Smallfrogs
http://www.KZTechs.COM

Windows Vista 里面延迟删除技术的变更

我曾经在“故事系列”技术文章之一的——《延迟删除的故事》里面描述了Windows 2000/XP/Server 2003里面使用到的延迟删除数据记录方式。

在 Windows 2000/XP/Server 2003 里面，包括Microsoft在内的各个软件厂商在碰到文件被占用无法马上替换问题的时候，都会使用MoveFileEx API函数让系统在注册表

Key：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
Value:PendingFileRenameOperations

键值下面建立一个延迟删除列表，系统在下次启动的时候，CSRSS.EXE进程将根据这个列表对文件进行延迟更新或者延迟删除操作。

注：PendingFileRenameOperations是一个REG_MULTI_SZ类型的注册表键值，不能直接通过注册表编辑器编辑，否则会造成延迟删除列表被破坏。要查看这个键值的内容，可以使用注册表编辑器或者使用我以前开发的 PendMove 工具，

对于Windows XP和Windows Vista两个操作系统在安装完需要重启的补丁以后的PendingFileRenameOperations键值数据以后会发现，Windows XP是利用PendingFileRenameOperations控制被占用文件进行被占用文件的升级和删除操作的。而Windows Vista并没有使用这个键值控制被占用文件的升级和删除操作。那么Windows Vista 补丁程序是怎么实现的延迟删除呢？

首先，需要明确的一点就是Windows Vista 新增的 Restart Manager 机制并没有完全被使用如果按照以前的说法，Windows Vista 在安装完补丁程序以后基本上是不需要重启的，但是现在看来每次打补丁都必须重启系统，至少进几个月的补丁都是这样的。

那么Windows Vista是如何得知被占用文件的目标文件和源文件信息，如何进行升级的呢？

在进行一番搜索以后，发现Windows Vista是利用一个/多个XML文件记录数据信息，在一个特别的目录里面存放临时文件和升级文件的。我们知道，以前打完Windows 补丁，都会在Windows目录下出现在$KB目录，但是Windows Vista好像没有这个内容，看不见吗？不是看不见，是因为根本就没有生成。

实际上，Windows Vista 是利用 %SystemRoot%\WinSxS 目录来存放临时文件、备份文件和配置信息的，Windows 会在适当的时候根据配置文件来完成文件的更新操作。

打开 %SystemRoot%\WinSxS 目录，会看到两个XML文件，pending.xml 和 cleanup.xml。前者记录了文件的新版本信息和旧版本信息，后者用途好像是用于清理环境的。

根据XML文件的描述，很容易得知：

• %SystemRoot%\WinSxS\Backup 目录存放旧版本的文件
• %SystemRoot%\WinSxS\Temp 目录存放需要升级到的新版本文件
• 注意：Windows Vista 的升级机制又不同于以前版本的Windows，是增量升级哦。也就是只需要下载不同的片段内容，Windows Vista 会根据片段内容和原始文件进行拼接以后，生成新的文件。

最后留一个问题给大家：Windows Vista 之前的操作系统是利用 CSRSS.EXE 实现文件更新的，那么Windows Vista呢？

系统通知区域、任务栏ToolTip无法正常显示之谜

在开始正文之前，先介绍2个术语：

• 通知区域：官方术语Notification area。又称为托盘区（Tray）。其实就是屏幕右下角那块显示时间和日期的区域。
• ToolTip：一个默认是浅黄色背景的浮动窗口，一般显示在鼠标指针的旁边。

正常情况下，当你把鼠标指针移动到通知区域时，Windows会以Tooltip的形式显示一些信息。但是，有的时候你还发现Tooltip被任务栏遮住了，如下图所示：

最严重的情况是你根本看不到Tooltip信息。

这个问题最常见于Windows XP 和 Windows Server 2003。究其原因是因为Windows XP/Server 2003的BUG造成的，某些情况下，Tooltip 的Z 序错误导致任务栏窗口遮住了Tooltip窗口。

从开发的角度来说，任务栏和Tooltip都具有TopMost属性，当Tooltip的TopMost属性丢失以后，就会造成上面所说的问题。

知道原因以后就好办了，解决方法有2个：
1、重启或者注销系统。
2、编写一个小工具，修复Tooltip的窗口属性。

重启或者注销的代价太大，我不愿意经常使用，因此我采用第2种方案。我写了一个修复上述问题的工具供大家免费使用，工具可以从下面地址下载到：

• http://www.kztechs.com/traytooltipfix/traytooltipfix.zip
• http://download.kztechs.com/files/traytooltipfix.zip

解压缩以后运行会显示下面的界面：

操作很简单，直接点击修复按钮即可。

修复完成以后，系统通知区域、任务栏ToolTip将恢复正常显示。

Smallfrogs
http://www.KZTechs.COM