谁动了我的环境变量

突然之间,我的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亿的黑心官员,却容不下这样一个蛋!

    CMD shell窗口是可以更宽的

    今天刚发现原来Windows的 CMD(cmd.exe) 窗口可以调宽度的,对常使用vi看代码或用mutt读邮件的人来是个相当好的消息。打开CMD窗口属性,修改Layout里Windows Size的Width即可。

    make-cmd-window-wider

    我虽是个Windows平台上的程序员,除Vistual Studio外,Cygwin和WinDDK也同样是必备工具,差不多天天都会用到。但在CMD窗口下用vi和mutt的体验并不怎么好,特别是看Windows代码,80字节宽的窗口限制让代码看来起很乱,所以我一般会用gvim。

    现在可以在CMD窗口里用vim –On分屏打开两件文件了。