Nothing Is Secret

后Oracle生活

离开Oracle有几天了，但并没有闲下来，一直在忙Ext2Fsd hash-tree directory indexing的实现。代码工作已基本完成，简单的测试只在laptop里的虚拟机里做过，但后面的测试才是真正让人皱眉的事情。

从xp到vista再到win7，无论32位还是64位，所有系统上都要做个测试才行。我所有的虚拟机都跑在Dell T7500工作站上，但工作站已于上周二还给公司了，所以还要将所用数据迁移到另外一个系统上来。这个周末差不多全耗在这个上面了。当初打算好的目标机器出现了个新问题，主板一通电就自动开机，关机时系统只会重启。电源问题好像是ASUS的诟病，遇到这个问题的人还真不少。这是个AMD双核系统，主板是很老的M2N4-SLI，内存已升至8G，跑几个虚拟机还是没问题的。一直纠结在换个烧包的  i7或6核的AMD还是买个新主板接着装老酒的选择上，但最后还是决定买MSI的KA790GX-M替换老的M2N4主板，旧U及老DDR2接着用。几番折腾，搞定系统。又重新接好AVR m8 (我的电源控制系统)，这样可以远程控制电源了。顺代将我的小P3 Server的系统盘换了，原来的是有坏道的40G 2.5寸盘，还是03年买的呢，用到现在还挺好，但空间不够了。现在换成了120G的。Linux的resize2fs真好使，为什么Windows总要依赖于第三方的支持？！

系统搭好了，测试机也有了，但下面的问题更让人头疼，怎么设计测试及怎么来测！想得我头都大了，也没有想好。或许这是惰性想推迟行动的绝佳借口，呵呵。

谁动了我的环境变量

突然之间，我的Visual Studio 6.0不能编译任何程序了，总是提示如下错误：

Making help include file...
Compiling resources...
Compiling...
Command line error D2004 : '/Zm' requires an argument
Error executing cl.exe.

就在约1个小时前还是可以的，而且这一个小时内我一直在看代码，并没有安装或卸载过任何软件。

查看plg文件，也没有什么异常。找到错误代码D2004相关的介绍，然后添加/Zm100选项，但错误照旧。

将整个Visual Studio目录copy到另一台Server 2008系统上，竟然是好的。也就是说问题并不是VS6本身，可能是系统环境或动态库的问题。

目前的系统之前已休眠过多次，上次重启约在一周前，还是因为无线网络没有反应才重启的，但在此之后直到现在一切都工作良好。第一反应就是该重启系统了，但在重启之前还想再调查调查，毕竟重启或许能消除问题，但并不能真正解决它。

即然VS6 GUI环境不行，那就尝试下makefile。结果makefile方式编译成功，意料之外！

就在进行makefile的cmd窗口中，查看了下环境变量，发现环境变量竞然是ifskit 2003的编译环境。重新打开了一个cmd窗口，结果还是ifskit 2003的环境，相当诡异。

我之前编译ext2fsd以创建browser文件时用过ifskit 2003，这个窗口到还是是打开的，并没有关闭。但它怎么可能会成为系统默认环境的呢？误操作？我并没有更改过环境变量！难道是系统出错？

百思不得其解之际，想起来之前explorer崩溃过一次，我只得重新加载了explorer.exe进程。随即打开procexp查看explorer.exe进程的Environment：

process_env

问题原来在这里！explorer崩溃时我一般会在taskmgr里重新加载explorer.exe，有时也会在cmd窗口里。而这次，却是在ifskit 2003的编译环境里加载的，结果此环境就被explorer.exe作为子进程继承过去了。然后Visaul Stuido 6.0作为explorer的子进程也继承了同样的环境，结果编译时用错了的编译器。

先验证一下，CTRL-ALT-DEL调出taskmgr，然后加载了一个新的cmd.exe，查看环境变量，确定是正确的，不再是ifskit 2003的编译环境了。然后以新的环境重新启动Vistal Stdio 6.0，尝试编译程序，编译成功，至此问题解决！

做好人难

看了姜文的新片子--让子弹飞，片子有点血腥，但通片让人相当痛快，除霸安良，劫富济贫，很有武侠的范！硬碰硬，枪对枪，谁怕谁！

所以流氓不可怕，但怕的是流氓有文化！ 老六为了只值一个铜板的“公平”不得不划开肚肠，让我想起了河南小伙张海超，就为了驳斥权威部门做出的“肺结核”诊断，不得不开胸验肺！

当有文化的流氓一会“硬”一会“软”地耍流氓的时候，善良的人除了自残、自裁、自焚还能干什么？（去幼儿园可不是善良的人该办的事，要不自宫以明志，可否？）

所以，想做个好人，无论是兵荒马乱还是盛世太平，没有枪还真不行！“枪”是什么？“枪”就是让流氓怕咱们的东西！

朋友，你有枪吗？那，你会造吗？

用Windbg替代VSJitDebugger

习惯了Windbg，准备用Windbg替代Vistual Studio的VSJitDebugger.exe来做Postmortem Debugger。但尝试了下面两种办法都没有成功：

  1. 1, Windbg –I （设Windbg为默认的debugger应对Unhandled User Mode Exceptions）
  2. 2, 直接改注册表:[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug]

直到在http://msdn.microsoft.com/en-us/library/ff542967.aspx里才看到，64位系统里对64位和32位程序有不同的设置：

1, A failing 64-bit application will be debugged according to the settings stored in the \\HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug key.

2, A failing 32-bit application will be debugged according to the settings stored in the \\HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug key. However, if the Debugger value in this key specifies an application in the %windir%\system32 directory, Windows will look in %windir%\syswow64 instead.

  • 将两处的AeDebug都设成Windbg后，分别对64位和32程序进行测试，Windbg被加载并成功attach到问题进程上。

    • D:\Documents> type AeDebug-Windbg.reg

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug]
    "UserDebuggerHotKey"=dword:00000000
    "Debugger"="\"C:\\Program Files\\Debugging Tools for Windows (x64)\\windbg.exe\" -p %ld -e %ld -g"
    "Auto"="1"

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\AutoExclusionList]
    "DWM.exe"=dword:00000001


    [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug]
    "UserDebuggerHotKey"=dword:00000000
    "Debugger"="\"C:\\Program Files\\Debugging Tools for Windows (x64)\\windbg.exe\" -p %ld -e %ld -g"
    "Auto"="1"

    [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug\AutoExclusionList]
    "DWM.exe"=dword:00000001

    IE8 下载即崩溃

    这几天Green Browser一直不老实工作，只要我点下载或另存文件就异常退出，升级成最新版本问题也没能解决。然后检查IE8，同样会出异常退出，看来是IE8的问题。

    先禁掉可疑add-on插件，问题照旧，还是不能下载任何文件。启动IE8 w/o add-on模式，问题还是存在，这下快轮到我崩溃了。

    调用Visutal Studio分析，发现问题在Wpc.dll模块中，stack trace如下：

         Wpc.dll!WPCSecurity::CheckSID()  + 0x1d bytes   
         Wpc.dll!CWpcSettings::Initialize()  + 0x11 bytes   
         Wpc.dll!CWebSettings::Initialize()  + 0x3a bytes   
         Wpc.dll!CWindowsParentalControls::GetWebSettings()  + 0x68 bytes   
    >    ieframe.dll!InitWPCSettings()  + 0xeb bytes   
         ieframe.dll!CheckFileDownloadSettings()  + 0x26 bytes   
         ieframe.dll!CDocObjectHost::CDOHBindStatusCallback::_ProcessCONTENTDISPOSITIONBindStatus()  + 0x11d bytes   
         ieframe.dll!CDocObjectHost::CDOHBindStatusCallback::_ProcessSecurityBindStatus()  + 0x7a6f0 bytes   
         ieframe.dll!CDocObjectHost::CDOHBindStatusCallback::OnProgress()  - 0x15 bytes   
         urlmon.dll!CBSCHolder::OnProgress()  + 0x40 bytes   
         urlmon.dll!CBinding::CallOnProgress()  + 0x31 bytes   
         urlmon.dll!CBinding::OnTransNotification()  + 0xfb50 bytes   
         urlmon.dll!CBinding::ReportProgress()  + 0x2c bytes   
         urlmon.dll!COInetProt::ReportProgress()  + 0x58 bytes   
         urlmon.dll!CTransaction::DispatchReport()  - 0xa bytes   
         urlmon.dll!CTransaction::DispatchPacket()  + 0x31 bytes   
         urlmon.dll!CTransaction::OnINetCallback()  + 0x83 bytes   
         urlmon.dll!TransactionWndProc()  + 0x28 bytes   
         user32.dll!_InternalCallWinProc@20()  + 0x23 bytes   
         user32.dll!_UserCallWinProcCheckWow@32()  + 0xd3 bytes   
         user32.dll!_DispatchMessageWorker@8()  + 0xee bytes   
         user32.dll!_DispatchMessageW@4()  + 0xf bytes   
         ieframe.dll!CTabWindow::_TabWindowThreadProc()  - 0x32182 bytes   
         ieframe.dll!LCIETab_ThreadProc()  + 0x4433 bytes   
         iertutil.dll!CIsoScope::RegisterThread()  - 0x3227 bytes   
         kernel32.dll!@BaseThreadInitThunk@12()  + 0xe bytes   
         ntdll.dll!___RtlUserThreadStart@8()  + 0x23 bytes   
         ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes   

    ieframe.dll!InitWPCSettings() 尝试加载Wpc.dll，然后在Wpc中发生异常。Wpc.dll是处理Parental Controls的模块，对此了解不多，网上也没有多少介绍。

    先找到我上次做的系统备份，是一个月前做的，竟然没找到这个文件，于是揣测是近期新装的程序或Windows update安装的。但到底是什么软件还很难去定位。

    c:\Windows\SysWOW64>dir Wpc.dll
    2009/07/14  09:16           308,736 Wpc.dll
    c:\Windows\SysWOW64>dumpbin /headers wpc.dll |grep version
                9.00 linker version
                6.01 operating system version
                6.01 image version
                6.01 subsystem version
                   0 Win32 version

    查看PE文件头，OS竟是6.1，资源中的版本号是1.0.0.1。这里要注意一点：Windows 6.1是Windows 7，Microsoft比较搞笑。我当前的系统是Windows Server 2008 AMD64，是Windows 6.0，就试着用另一台Visata AMD64的Wpc.dll替代这个，结果竟然正常运行。看来IE8 crash是这个Wpc.dll的问题。

    再检查一下Vista系统的Wpc.dll

    C:\Windows\SysWOW64>dir Wpc.dll
    2008/01/21  10:51           296,960 Wpc.dll
    C:\Windows\SysWOW64>dumpbin /headers Wpc.dll | grep -i version
    Microsoft (R) COFF/PE Dumper Version 9.00.30729.01
                8.00 linker version
                6.00 operating system version
                6.00 image version
                6.00 subsystem version
                   0 Win32 version

    Vista系统的Wpc.dll资源中的版本号也是1.0.0.1。看来二者是用同一source code分别针对Vista和Win7做的不同的编译。

    同时将本系统的64位Wpc.dll恢复成Vista系统的，至此Green Browser/IE8下载又正常工作了。

    国家之大，竞容不下一个蛋

    egg_house_in_china

    曾受到全国人民关注的蛋形小屋消失了！就在此前城管称蛋形小屋系私搭乱建应自行拆除!

    堂堂人民共和国容得下“老爸是李刚”这样的败类儿子，容得下贪污20亿的黑心官员，却容不下这样一个蛋！

    Pages:  1 2 ... 36 37 38 39 40 ... 46 47