绝大多数的个人及商业用户客户端都采用了微软Windows操作系统,例如最近非常火爆的Windows 7和她的上一个版本Windows Vista,以及非常经典的Windows XP。当然,微软作为一家盈利性公司,从Windows XP开始,所有出售的Windows产品都需要输入产品密钥进行在线或电话激活后才能够正常使用。如果用户在安装完操作系统后不对系统进行激活,此时Windows将以“评估软件”方式来运行,一旦试用期终止,Windows所带的激活机制将会按预定义“策略”提示用户,并定时对用户的操作和使用进行“干扰”。针对不同Windows产品及Windows产品的不同版本,微软都为正版用户提供25位的序列号激活密钥。
用户一旦将产品密钥输入Windows并点击确定后,将自动执行如下步骤:
- 检查当前Windows版本
- 激活和解锁系统功能及特性
- 校验产品密钥的分配渠道
- 校验许可证类型
- 尝试联机激活,否则提示电话激活
- 校验一个唯一标识ID以确认激活是否被MS接受
微软的产品解密及激活信息其实是以数据文件形式将以上信息存储在 pidgenx.dll. 、Pidgenx.dll和pkeyconfig.xrm-ms文件当中,通过这3个文件,用户就可以在不连接到Internet的情况下确认当前序列号的详细激活信息,以及是否已被微软列入到黑名单当中。
通过使用pidgenx.dll数据中记录的产品密钥和算法,再通过一定的开发,便可以用离线方式验证序列号的许可证类型、适用的系统版本及其它信息。目前网络中已有的程序有Microsoft PIDX Check和Windows 7 Product Key Checker等。
Microsoft PIDX Check
当输入一个产品激活密钥后,Microsoft PIDX Check可以自动检查当前密钥的产品ID,ID1、ID2、适用系统的版本类型、子类型及各类等相关信息。
Microsoft PIDX Check下载:
Windows 7 Product Key Checker
Windows 7 Product Key Checker由俄罗斯程序员开发,其在图形界面的表现有所提高,它可以把产品密钥所涉及到的详细信息全部进行检查和显示,其中主要包括:产品ID、扩展ID、激活ID、适用系统版本、许可证类型及许可证使用渠道等。
Windows 7 Product Key Checker下载:
当微软正式对外宣布Windows 7在周三RTM时,微软便对外公布OEM厂商将在最早的几个工作日内获得Win 7 RTM介质。继承过去的传统,微软会给予或选择部分OEM厂商亲自到雷德蒙微软总部获取RTM介质的机会。2009年7月25日(东部时间)少数OEM厂商便已经到雷德蒙微软总部获取到了他们相应的RTM介质。
惠普: 在右边的是Sean Kovacs,惠普实验室工程师;左边的是Titan Fang,惠普系统工程师。

东芝: 右边的是Hideki Yagi,东芝董事;在左边是Michael Henry,东芝全球联盟经理。最左侧和最右侧分别是来自微软的Greg Taylor和Mari Kitajima。

联想: 中间的是来自联想的Nicole Hopper ,她左右两侧分别是来自微软的James Hendergart和 Zhan Ding。

华硕: 右侧的是华硕系统工程师Derek Li,左侧是来自微软的David He。

宏碁:左侧是宏碁工程师Yifan Li,右侧是来自微软的Clint Woon。

戴尔: 中间右侧是DELL软件工程师Christian Piccini。 最左边的是戴尔高级软件工程师Jay Hendricks。左侧第二位及最右侧这位分别是来自微软的Phil Burtscher和Matt Davis。

索尼:左右的是Sony项目经理Herbert Pang,右侧的是Sony软件工程师 Mina Bush。

富士通西门子: 左侧这位是来自富士通的项目经理Henning Klein,右侧是来自微软的Constantine Mitschke-Collande 。

各OEM厂商已经顺利的从微软拿到了Windows 7介质,相信在不久的将来,用户便可以买到心仪的带Windows 7操作系统的计算机。
微软会按原计划在2009年8月6日在MSDN/Technet上放出Windows 7和Windows Server 2008 R2的安装镜像和激活密匙,我提前把SHA-1和MD5放出来把,在网上随处下载镜像的朋友可以自行校验下。
Windows 7 Ultimate Retail English (x86)
Name: 7600.16385.090713-1255_x86fre_client_en-us_Retail_Ultimate-GRMCULFRER_EN_DVD.iso
Size: 2501894144 bytes
Date Modified: Tuesday, July 14, 2009, 17:32:44 PM
CRC: C1C20F76
MD5: D0B8B407E8A3D4B75EE9C10147266B89
SHA-1: 5395DC4B38F7BDB1E005FF414DEEDFDB16DBF610
Windows 7 Ultimate Retail English (x64)
Name: 7600.16385.090713-1255_x64fre_client_en-us_Retail_Ultimate-GRMCULXFRER_EN_DVD.iso
Size: 3224686592 bytes
Date Modified: Tuesday, July 14, 2009, 17:40:25 PM
CRC: 1F1257CA
MD5: F43D22E4FB07BF617D573ACD8785C028
SHA-1: 326327CC2FF9F05379F5058C41BE6BC5E004BAA7
Windows 7 Ultimate E Retail English (x86)
Name: 7600.16385.090713-1255_x86fre_cliente_en-us_Retail_UltimateE-GRMCEULFRER_EN_DVD.iso
CRC: 953EFBCC
SHA-1: BC10F09B86DCBAF35B31B0E6FBA7D006ACAAD28D
Windows 7 Ultimate E Retail English (x64)
Name: 7600.16385.090713-1255_x64fre_cliente_en-us_Retail_UltimateE-GRMCEULXFRER_EN_DVD.iso
CRC: 77BE890E
SHA-1: 029DCCEDD7691206010F84CE58343405A4DA92C9
Windows 7 Ultimate Retail Simplified Chinese (x86)
Name: 7600.16385.090713-1255_x86fre_client_zh-cn_Retail_Ultimate-GRMCULFRER_CN_DVD.iso
SHA1: B589336602E3B7E134E222ED47FC94938B04354F
Windows 7 Ultimate Retail Simplified Chinese (x64)
Name: 7600.16385.090713-1255_x64fre_client_zh-cn_Retail_Ultimate-GRMCULXFRER_CN_DVD.iso
SHA1: 4A98A2F1ED794425674D04A37B70B9763522B0D4
Windows Server 2008 R2 Volume License (VL) English
Name: 7600.16385.090713-1255_x64fre_server_en-us_VL-GRMSXVOL_EN_DVD.iso
Size: 2,996,799,488 bytes
SHA1: AD855EA913AAEC3F1D0E1833C1AEF7A0DE326B0A
默认情况下,Windows配置为当系统发生崩溃时尝试自动抓取一个当前操作系统的状态信息。接下来我们将讨论系统故障,非应用程序失败。Dump选项可以通过控制面板中的系统工具来进行设置。我们打开系统属性—高级选项卡,找到启动和故障恢复,点击设置,我们就可以看到Dump文件的相关配置。当系统发生崩溃时,有3类Dump文件可以被捕获:

- 完全内存转储:当崩溃发生时,将捕获整个物理内存的状态。此类转储文件大小为内存中页面文件大小+1MB的文件头。Windows NT4只支持完全内存转储,当然这也是Windows Server Systems的默认设置。
- 核心内存转储:当崩溃发生时,核心内存转储只捕获物理内存中内核态的页面文件读/写数据。这只是内核态的转储,并不包括用户态进程的页面。不过,由用户态进程页引起系统崩溃是不大可能的,通常都是由内核态引起。核心内存转储中包括:当前运行进程、线程和被加载的驱动等相关信息。核心内存转储文件大小=操作系统内核态内存占用大小+操作系统为驱动程序分配内存的大小。
- 小内存转储:小内存转储(又叫Mini-dump)是一个64K的转储文件(64位系统和Windows7里是128K,Vista512K),它包括:终止代码、参数和被加载的驱动列表。主要信息为崩溃时的当前进程、线程和内核堆。
注意:有的情况下我们需要进行完全内存转储,手动进行完全内存转储为程序停止响应的排错提供了最为丰富的信息。因为当程序Hang住时,我们需要查看用户态进程、死锁等等信息。不过,当你在选择捕获哪种Dump文件时,一定要考虑好捕获出来的文件大小。如上所述,完全内存转储文件大小会是在物理内存大小的基础上+1MB。(笔者8GB内存,再加1MB。恐怖啊……)
前面我们回顾了3种类型的Dump文件,实则在日常的工作中核心内存转储是我们系统崩溃和Bug检查时最常用到的。请记住,核心内存转储文件大小仅基于内核态内存占用和驱动内存占用。(在有更多内存的系统上,Dump文件过大是正常的。)目前我们还无法精准的计算核心内存转储文件大小,你可以尝试手动配置核心内存转储来查看页面文件是否足够大。对于设置最小的核心内存转储大小我们有一定的指导方针,但对于最大值目前还没办法:
|
物理内存
|
最小页面文件 (Kernel Dump)
|
|
< 128MB
|
50MB
|
|
< 4GB
|
200MB
|
|
< 8GB
|
400MB
|
|
>= 8GB
|
800MB
|
如果你担心页面文件设置过小,无法很好的捕获核心转储,我们唯一的办法就是通过KB244139所描述的方式使用CrashOnCtrlScroll方法造成手动崩溃。系统重启之后,我们可以手工查看Dump文件大小。另一种方法是在启动分区上手动设置2GB+1MB的页面文件大小(32位系统),这是因为32位操作系统内核态最大地址空间就是2GB。
除了配置正确的页面文件大小之外,我们也需要确保有足够的磁盘空间让Dump文件能够被正确的写入。与页面文件用来捕获Dump不同,Dump文件可以被写入其它的本地分区。在保存多个Dump文件时,请取消选择“覆盖任何现有文件”。不过请记住,这会给剩余的磁盘空间造成很大的压力。

下面我们来看Dump文件是如何被产生的。当系统启动时,会到注册表HKLMSystemCurrentControlSetControlCrashControl 读取崩溃转储选项。所有在图形界面所做的操作都会修改如下注册表值:
- 将事件写入系统日志=LogEvent
- 自动重新启动= AutoReboot
- 写入调试信息= CrashDumpEnabled
- 转储文件= DumpFile
- 覆盖任何现有文件= Overwrite

如果你的系统超过2GB内存,在图形界面中你将不会看到完全内存转储选项。其原因在KB274598中进行了描述。但我们可以通过将HKLMSystemCurrentControlSetControlCrashControl下的CrashDumpEnabled值设置为1来强制启用它(改这个值在图形界面中完全内存转储仍不会显示出来)。如果你需要完全内存转储来做更详尽的排错,也可以考虑使用Boot.ini中的MAXMEM开关将32位操作系统所使用的内存限制在2GB或更少(可以参考KB108393),此时系统就会将完全内存转储选项显示来。

现在回到Dump文件如何被产生这个话题。一旦转储功能被启用,操作系统会自动写一个以“Dump_”开头的磁盘迷你端口驱动到启动分区,并校验与创建Dump文件相关的所有组件。包括:磁盘迷你端口驱动、写入Dump文件的I/O管理函数和启动分区的页面文件。最终所得的校验结果会被保存起来,每当系统启动时KeBugCheck函数会重新进行校验并与之前的结果相比对。如果校验结果不匹配,将不会有Dump文件被写入磁盘(因为有破坏磁盘数据的危险);如果检验结果匹配,Dump信息会被写入已经被写到磁盘启动分区上的页面文件当中。文件系统会被完全绕过,因为它也有可能是造成崩溃的原因之一。当SMSS.EXE在启动过程中开启内存分页时,系统会仔细检查启动分区页面文件当中的信息。如果有崩溃信息,这部分页面文件就会被保护起来。如果启动过程中的所有或部分启动分区页面文件不可用,系统会提示虚拟内存过低(暂时)。启动进程执行完成之后WINLOGON.EXE会调用SAVEDUMP.EXE进程从页面文件中抽出崩溃信息,并将Dump文件写到磁盘上。
在Windows Server 2003上,某些过程可能会有不同,请参考KB886429。当Server启动之后,Windows会要求在启动分区上创建一个和物理内存相同大小的临时文件。如果磁盘空间不足,Dump还是会生成,不过会被系统缩减大小。在创建Dump操作过程的初期,会话管理子系统(SMSS.EXE)就会介入验证内存Dump信息是否有效。如果Dump信息有效,SMSS.EXE会将Dump文件重命名为Dumpxxx.tmp,进而存储Dumpxxx.tmp到启动分区并设置HKLMSystemCurrentControlSetControlCrashControlMachineCrash下的TempDestination和DumpFile值。SAVEDUMP.EXE便会读取这2个值,并在判定文件的有效性之后将Dumpxxx.tmp保存成Memory.dmp。
有很多病毒或木马都利用了Windows中一个非常有用的功能——自动播放,它们通常都把自己伪装成一个正常或有用的程序在计算机上运行。然后通过接入此计算机的即插即用设备来感染其它的计算机,以达到传播目的。比如,你将一个装有照片的U盘插入到计算机中,木马和病毒有可能注册到“打开文件夹以查看文件”选项上。当你直接执行“打开文件夹以查看文件”,木马或病毒就可直接被激活。不过,如果你选择第二个选项查看文件,你的系统将会是安全的。
插入感染AutoPlay的U盘
以上这红、绿两个选项看似是相同的操作,其实在执行方式上却有着天壤之别。很多技术高手都容易误选到第一个选项上,这让系统很可能执行木马或病毒,但绝大多数的Windows使用者都没有意识到这种潜在风险。
日渐增多的攻击
当AutoPlay作为一项新功能在WindowsXP中提供之后,为许多用户带来了方便。同时,微软也已经意识到,利用AutoPlay功能作为潜在繁殖和传播方式的病毒和木马总数正在显著增加。
增加用户信任
Windows 7针对AutoPlay功能进行了一项关键的改进。它可让通过AutoPlay在系统中隐藏执行的恶意程(如Conficker病毒)序无所遁形。
因为没有办法鉴定U盘上程序的来源,Windows 7已经不再允许系统从非可移动光媒体(CD/DVD)中直接执行AutoPlay任务。因为我们不可能知道IHV(独立硬件提供商)或其它人在U盘里做了些什么手脚。取消AutoPlay功能可以在很大程度上堵住当今病毒常用的一个传播渠道,帮助用户保护系统安全。当然,微软仍允许我们访问保存在计算机其它地方和AutoPlay任务。
由于这些变化和改进,当你插入一个存有照片且被恶意软件感染的U盘时,你可以看到的提示界面是:
Windows 7插入感染AutoPlay的U盘
另一方面,当您插入需要提示安装向导的光盘,Windows 7任然会执行ISV(独立软件开发商)提供的AutoPlay任务。例如:
CD的自动执行任务
这是Windows 7中针对AutoRun的第一个变化,并且微软将在后续的升级中为Windows XP和Windows Vista也进行这项改进。
小结
最后,如果您在使用Windows 7 RC,我们希望您对使用Windows更加从容和自信,因为在各方面的努力下,它已经变得更加安全。
最近评论