青春时代是一个短暂的美梦,当你醒来时,它早已消失得无影无踪了。
 
昨日:篇  今日:篇   总帖:篇   会员:
今日:0    总帖:39
admin
626
为32位及64位7PE、8PE添加DISM组件,支持/WIMBoot参数。先解包你的PE,执行以下操作,然后重新打包即可。文件下载:Dism组件包添加方法:1、复制DISM相关文件:将x64目录下的所有文件及文件夹复制到64位PE的system32目录下,将x86目录下的所有文件及文件夹复制到32位PE的system32目录下,如提示文件已存在,直接覆盖即可。2、导入服务项:运行regedit打开注册表编辑器,选中HEK_LOCAL_MACHINE主键,“文件”菜单——加载配置单元——选中PE的system32\config目录下的SYSTEM,项名称设为“ST”(不含引号),双击导入压缩包中的wof.reg,然后展开HEK_LOCAL_MACHINE主键,选中ST后,“文件”菜单——卸载配置单元。
0 0 381天前
admin
488
WIN8一般只用DISM挂载处理WIM文件,因为DISM在8时代替换了过去IMAGEX的绝大部分功能,但不等于WIN8的ADK工具中就没有了IMAGEX了。不过,现在很少再用IMAGEX,除了/INFO功能外。WIN7时,DISM、IMAGEX的分工各有不同。下面讲失败的挂载与卸载导致无法进行下一次挂载问题应该如何解决。常见的情况有:卸载没有完成,命令窗口被关闭了,或者挂载没完成,命令窗口被关闭了,这样挂载目录中还有残留文件和目录。还有一种情况是,卸载时,挂载目录处理读写状态,比如你打开了挂载目录中的某个文件,或正常读取某个目录。如果不进行清理,失败的记录将保留在系统的LOG中,这些都会导致下一次挂载无法进行。所以执行卸载时,要注意不要有读写挂载目录中的任何文件的任何行动,也不要打开挂载目录中的任何目录。如果已经有这样的情况,要进行一次清理。处理办法如下:1、DISM对于WIN8及更高的系统,以管理员身份执行DISM命令(系统自带):dism /cleanup-mountpoints对于WIN7,以管理员身份执行DISM命令(系统自带):Dism /Cleanup-Wim2、imagex在部署工具命令提示窗口(或者在IMAGEX.EXE所在目录,建立一个CMD文件来执行),执行:imagex /cleanup以上的命令将帮你清理失败的挂载与卸载。
0 0 381天前
admin
658
转载自:http://bbs.duba.net/thread-23349493-1-1.html1、 概述这个病毒被封装在GHOST系统盘,通过电脑装机、重装系统等途径传播,并且自带驱动对抗杀软,隐藏自身目录防止被查杀。该病毒通过配置文件劫持指定浏览器和主页,并且可通过云端链接升级,十分灵活。2、 样本简介该病毒保存在C:\Program Files\bwlock下,整个bwlock目录被驱动drinst.sys保护,防止杀软扫描,同时病毒主程序bwlock.exe开机自启动,主要功能是根据配置文件锁定浏览器主页。SafeProtect.dll被驱动注入杀软和浏览器进程用于自保护和主页劫持。 图1、GHOST盘中病毒目录下的文件图2、病毒功能大致流程图3、 详细分析 3.1 bwlock.exe行为分析 bwlock.exe是病毒主程序,主要功能是根据配置文件篡改指定浏览器快捷方式参数和注册表主页设置,以及升级驱动和dll模块。 1、获取主页地址 访问www. *****.com/kzr/zhu/2015.htm获得要锁定的主页地址,其中Indexurl为要锁定的主页,Driverurl为保存到本地的网页文件,用于重定向到Indexurl。如下图:图3、主页配置2、篡改浏览器lnk参数和注册表主页设置读取配置文件C:\Program Files\bwlock\llq.ini,修改浏览器主页。配置文件升级地址为www.*****.com/kzr/llq/20150101/xpllq_32.htm 。配置文件内容如下:图4、浏览器主页劫持配置文件部分内容修改主页时,根据配置文件,对“[要修改的浏览器]”,修改其桌面和任务栏lnk参数为C:\Windows\index.htm;对“[whitelist]”不进行修改;对“[要删除的浏览器]”,删除其桌面和任务栏lnk。 根据配置文件中[项名]、[键名]、[键值]的信息来控制驱动修改注册表中的主页设置,如下图:图5、修改注册表主页设置3、云端升级驱动和DLL模块 通过访问www.*****.com/kzr/DriverUpdate/UpDateConfig.txt进行模块升级;更新驱动文件和dll模块。图6、云端升级配置信息3.2 drinst.sys驱动行为分析 该驱动主要功能是注入DLL到指定进程、隐藏自身及防止网页保护模块加载。 1、DriverEntry行为首先检查驱动同目录下是否存在bwlock.exe并且检查特征码判断是否为自身的文件;如果存在并通过验证,则hookSSDT和NTFS派发函数,对自身进行过滤保护。驱动通过接收bwlock.exe的控制码来设置bwlock.exe的启动项,确保长期驻留系统。DriverEntry代码如下:图7、驱动DriverEntry代码2、HOOK 系统服务描述符表(SSDT) HOOK函数ZwEnumerateValueKey、ZwOpenKey、ZwQueryValueKey用于保护自身注册表服务项;HOOK函数NtSetInformationProcess用于注入SafeProtect.dll到指定进程。图8、HOOK SSDT这里HOOK的3个注册表相关函数都先过滤了部分系统进程和自身进程,然后过滤注册表路径和键值,如果为自身驱动的服务名或者包含子串“bwlock”就返回失败,禁止杀软访问。图9、白名单进程过滤图10、注册表关键字过滤NtSetInformationProcess的钩子函数对以下进程通过插入apc线程来注入DLL,apc线程直接调用Loadlibrary加载DLL。图11、注入dll到指定进程图12、通过插入APC远程加载dll3、HOOK NTFS的派遣函数 对NTFS HOOK了3个派遣函数:MJ_IRP_CREATE、MJ_IRP_DIRECTORY_CONTROL、MJ_IRP_SET_INFORMATION图13、HOOK NTFS派遣函数在派遣函数中匹配当前进程是否在白名单中,若是则放行,否则匹配路径是否包含字串“bwlock”,包含则过滤掉,防止自身目录被杀软扫描。由于过滤有进程白名单,所以通过资源管理器是可以查看和删除该病毒所在目录的。图14、文件访问过滤白名单和关键字4、保护自身进程及拦截网页保护模块 在ObReferenceObjectByHandle的钩子函数中会检查当前进程和引用目标对象,如果当前进程在白名单中或是浏览器进程则放行;否则,如果文件对象路径中包含bwlock、safehmpg.dll(360网盾防护模块)、tswebmon.dat(电脑管家网页防火墙模块)或进程对象为bwlock.exe,则进行拦截;目的是防止浏览器加载安全模块以及保护自身。图15、ObReferenceObjectByHandle拦截代码PsLookupProcessByProcessId的钩子函数会检查当前进程和目标进程,如果进程在白名单中或是浏览器进程则放行;否则如果目标进程为bwlock.exe则拦截,防止结束进程bwlock.exe。图16、PsLookupProcessByProcessId拦截代码3.3 SafeProtect.dll行为分析 该dll被注入到浏览器进程,功能是劫持命令行参数及拦截浏览器加载主页保护模块。加载后在dllmain中解密文件C:\Program Files\bwlock\Confighp.txt,得到主页路径C:\Windows\index.htm;当前进程如果是bwlock.exe,结束并返回。 1、劫持命令行参数 如果是kxetray.exe,则hook 系统API函数CreateProcessA/W;在钩子函数中修改命令行参数为之前解密的主页路径。 如果是其他进程,则生成命令行”EXEPATH”C:\Windows\index.htm(EXEPATH为当前进程全路径),hook 系统API函数GetCommandLineA/W,修改函数开头第2字节处的DWORD值为命令行的地址,使得进程读取命令行时得到设置好的主页路径。图17、hook GetCommandLineA/W劫持命令行参数2、拦截主页保护模块hook系统API函数LoadLibraryA/W,在钩子函数中匹配加载dll路径,如果包含下图中字串则直接返回,防止浏览器加载安全软件的主页保护模块。图18、hookLoadLibraryA/W过滤杀软模块4、 防范措施根据以上分析,该病毒通过修改浏览器快捷方式参数、劫持命令行参数、篡改注册表主页设置来劫持主页;并通过驱动HOOK来对抗杀软和保护自身;由于该病毒通过GHOST系统盘传播,在新安装或者重装系统时尽量使用正版操作系统,不要从网上下载GHOST盘安装,并且一定要第一时间安装安全软件,防止系统被不法分子安装病毒木马,沦为其牟取非法利益的工具。注:本文转载自网络,个人觉得不错,分享给各位技术员同行。
0 0 427天前
admin
494
作者:想了好久链接:https://www.zhihu.com/question/21883209/answer/19617109来源:知乎著作权归作者所有,转载请联系作者获得授权。前几天,突然发现默认浏览器的Chrome的主页被篡改为了hao123。每次第一次打开,都自动跳转到http://www.hao123.com/?tn=29065018_59_hao_pg这个网址。自己到网上搜了一下,试了各种方法最终还是无果,本着屌丝懂技术,神都难不住的精神决定自己破掉它。(*^__^*) 嘻嘻……<一> 缩小包围圈1、chrome设置?对chrome中的启动时、外观属性都进行了修改,仍然没有解决问题。&amp;amp;lt;img src="https://pic4.zhimg.com/c4934bf010bea48b811258eaad0f3cbf_b.jpg" data-rawwidth="837" data-rawheight="458" class="origin_image zh-lightbox-thumb" width="837" data-original="https://pic4.zhimg.com/c4934bf010bea48b811258eaad0f3cbf_r.jpg"&amp;amp;gt;2、快捷方式中添加了参数?发现不管是从桌面快捷方式还是直接点击exe文件,chrome主页都被篡改。这就排除了是在桌面快捷方式中的目标栏中添加了hao123网址的缘故。哎,查看一下桌面chrome快捷方式不就得了,整的这麽麻烦。囧。&amp;amp;lt;img src="https://pic1.zhimg.com/c08ba2010964ad2bd041eb343f1e7038_b.jpg" data-rawwidth="366" data-rawheight="461" class="content_image" width="366"&amp;amp;gt;3、chrome.exe被篡改或者chrome配置文件被修改?将chrome的配置文件和可执行文件一同拷贝到虚拟机中,擦,在虚拟机中就没问题。说明问题不在chrome身上。那会是什么问题呢?山重水复疑无路,柳暗花明又一村。转折来了,将chrome.exe重新命名后,再打开浏览器,主页就是设置的www.google.com.hk,这样就没问题了。测试一下,将firxfox.exe重命名位chrome.exe后,主页也被篡改位流氓导航页。看来chrome.exe是个关键词啊!一个解决方案就这样诞生了,太easy了吧。但是这里面到底隐藏着什么奥秘呢?继续整!<二>我要看代码1. 先上第一个利刃,microsoft旗下的Process Explorer。查看chrome.exe的主进程信息如下,亮点就在下图中。&amp;amp;lt;img src="https://pic1.zhimg.com/1689f0289790459e26e24d0e87d90874_b.jpg" data-rawwidth="903" data-rawheight="329" class="origin_image zh-lightbox-thumb" width="903" data-original="https://pic1.zhimg.com/1689f0289790459e26e24d0e87d90874_r.jpg"&amp;amp;gt;小伙伴们一定看到了Command line下面的编辑框里有我们久违的流氓url吧。这个Comand line是什么东东? Windows下常见的创建进程的api就是CreateProcess,这个函数申明如下。&amp;amp;lt;img src="https://pic4.zhimg.com/9a323005cc07f736f4fd12c4a165a1df_b.jpg" data-rawwidth="746" data-rawheight="324" class="origin_image zh-lightbox-thumb" width="746" data-original="https://pic4.zhimg.com/9a323005cc07f736f4fd12c4a165a1df_r.jpg"&amp;amp;gt;其中的第二个参数,就是Command line,在我们这里就是chrome.exe应用程序的参数。该api的详细介绍在http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx。现在的问题就是这个command line是谁传递给chrome.exe进程的?弄清楚这个问题之前,先要搞清楚,windows下,双击或者右键打开应用程序时,该应用程序进程是谁创建的?查阅资料发现,通过双击或者右键打开的应用程序进程都是由explorer.exe这个进程调用CreateProcess创建的。那么,我们的流氓url Command line 就一定是explorer.exe传递给chrome.exe。看来explorer.exe有问题了。测试一下,通过任务管理器中的创建新任务的方式启动chrome就没有流氓导航了。但是通过和虚拟机中的explorer.exe文件对比,发现主机和虚拟机中的两个文件完全相同。Exe运行时不光要加载自身的.exe程序文件,还要依赖一些动态库dll。是不是dll有问题。利刃2上场。2、ollydbg闪亮上场。用od加载explorer.exe运行,查看所依赖的dll。&amp;amp;lt;img src="https://pic2.zhimg.com/94d0c04001c18cc6899916ba839c87fd_b.jpg" data-rawwidth="910" data-rawheight="329" class="origin_image zh-lightbox-thumb" width="910" data-original="https://pic2.zhimg.com/94d0c04001c18cc6899916ba839c87fd_r.jpg"&amp;amp;gt;看到有几个可疑的非系统dll,QvodExtend.dll, QvodWebBase.dll,按理说explorer.exe是不会依赖非系统dll的。想起来,网上说的卸载Qvod可以解决问题。这个怎么能说卸就卸呢?万万不可以的。问题肯定是在调用CreateProcess之前出现的,在当前模块中查找调用CreateProcess的地方,一共有四个点,全部设置断点,然后调试explorer.exe进程?当然时调试失败了。~~~~(>_<)~~~~ 但是重新加载explorer.exe运行,然后查看kernel32.dll的CreateProcess的代码发现了重要的问题。下图就是kernel32.dll中的CreateProcess代码,尼玛不是说好了的CreateProcess将调用CreateProcessInternalW吗?这儿怎么上来直接 jmp QvodWebB.10008B90?QvodWebB你要闹啥啊!!!&amp;amp;lt;img src="https://pic4.zhimg.com/56ab58b4f88019ab9570214375c45003_b.jpg" data-rawwidth="624" data-rawheight="560" class="origin_image zh-lightbox-thumb" width="624" data-original="https://pic4.zhimg.com/56ab58b4f88019ab9570214375c45003_r.jpg"&amp;amp;gt;看看下面这个正版的CreateProcess吧。&amp;amp;lt;img src="https://pic4.zhimg.com/12bbf8cf2fe987f574e9cf96982874eb_b.jpg" data-rawwidth="611" data-rawheight="561" class="origin_image zh-lightbox-thumb" width="611" data-original="https://pic4.zhimg.com/12bbf8cf2fe987f574e9cf96982874eb_r.jpg"&amp;amp;gt;至此,整个流程大致出来了。QvodWebBase.dll将kernel32.dll的CreateProcessW代码的前5个字节改为了一条jmp指令,改变了CreateProcess的正常执行流程。实际上,CreateProcessA,CreateInternProcessW,CreateInternProcessA都被注入了相应的跳转指令。<三>深入巢穴 QvodWeb如何随explorer.exe加载,QvodExtend.dll, QvodWebBase.dll到底都做了些什么?先mark,后面接着整。1.先看看QvodExtend.dll, QvodWebBase.dll都导出了些什么函数。&amp;amp;lt;img src="https://pic3.zhimg.com/f001721d7591449edfc92ce397f2081a_b.jpg" data-rawwidth="833" data-rawheight="296" class="origin_image zh-lightbox-thumb" width="833" data-original="https://pic3.zhimg.com/f001721d7591449edfc92ce397f2081a_r.jpg"&amp;amp;gt;下面是QvodWebBase.dll导出的函数。可以看到有InstallWindowsHook钩子函数。下面是QvodWebBase.dll导出的函数。可以看到有InstallWindowsHook钩子函数。&amp;amp;lt;img src="https://pic4.zhimg.com/8a794913984d780f7ef326ca24570573_b.jpg" data-rawwidth="829" data-rawheight="295" class="origin_image zh-lightbox-thumb" width="829" data-original="https://pic4.zhimg.com/8a794913984d780f7ef326ca24570573_r.jpg"&amp;amp;gt;同时,用IceSword扫描时发现,QvodExtend.dll还是个BHO。同时,用IceSword扫描时发现,QvodExtend.dll还是个BHO。&amp;amp;lt;img src="https://pic3.zhimg.com/a985644ee77a0cb8cb5bcd67a16a0d3e_b.jpg" data-rawwidth="1236" data-rawheight="300" class="origin_image zh-lightbox-thumb" width="1236" data-original="https://pic3.zhimg.com/a985644ee77a0cb8cb5bcd67a16a0d3e_r.jpg"&amp;amp;gt;同时,测试发现如果将QvodExtend.dll重命名后,就不会出现主页被篡改,同时explorer.exe也不会有QvodExtend.dll和QvodWebBase.dll模块。由此可以推断,QvodExtend.dll随explorer.exe或者ieplorer.exe启动时,会向系统注册QvodWebBase.dll中的钩子函数,接着再是加载QvodWebBase.dll时,该dll的DLLMain入口函数会向当前进程注入Jmp指令。反汇编QvodExtend.dll代码可以发现,注册QvodWebBase.dll中的钩子函数的代码&amp;amp;lt;img src="https://pic1.zhimg.com/dcf520216d63419ab3908197d0116e04_b.jpg" data-rawwidth="1011" data-rawheight="579" class="origin_image zh-lightbox-thumb" width="1011" data-original="https://pic1.zhimg.com/dcf520216d63419ab3908197d0116e04_r.jpg"&amp;amp;gt;至此,整个过程告一段落。至此,整个过程告一段落。解决办法就是删除或者重命名QvodExtend.dll和QvodWebBase.dll。不知道会不会影响qvod,目前不得而知。----------------------------------------------分割线------------------------------------------------------------------------------QvodExtend.dll在其dll_main函数中,判断当前的模块是explorer.exe或者iexplore.exe,若两者都不是则退出;否则读取qvod安装目录下的QvodCfg.ini文件获取 QvodWebBase的版本号,找到 QvodWebBase.dll后调用LoadLibrary加载该模块(加载过程中会向CreteProcessA/W中注入代码,这个代码就是在CreateProcessInteralA调用之前修改comand line参数),接着调用GetProcAddress获得 QvodWebBase安装钩子的导出函数installwindowshook,并执行该函数,该钩子的类型是WM_CBT。整体流程就是这样。 ----------------------------------------------分割线------------------------------------------------------------------------------ 该实验的软件版本是QvodPlayer5.17.152.0,目前在最新版本中该问题已经解决。
0 0 427天前
admin
612
      PC机半个月时间多次出现GUI挂起的消息框, 以及出现了3次:      突然黑屏几秒后显示: 显示器驱动程序已停止响应并且已成功恢复。        把我给郁闷的!粗略上网一看,这是个普遍而且顽固的问题,从Vista时代就继承下来,解释和解决方案多得眼花缭乱,但没有一个真正权威的说法。于是花了几天的时间上网细搜,查中文论坛,查英文论坛,给微软的写信,看技术文档,折腾驱动等等。        首先来说这个症状,win7系统下黑屏恢复,且跳出“显示器驱动程序已停止响应并且已成功恢复”,这个现象本身只说明一件事:系统的 超时检测和恢复 (TDR)服务, 执行到了显卡挂起热重启故障处理的最后一步。黑屏是系统reset显卡之前的瞬间,在重设分辨率。这是微软的技术文档自己描述的,没有任何疑问。 顺便吐槽一下win7中文版坑爹的翻译,明明人家说的是Display Driver,是指显卡驱动,却翻译成显示器驱动,纯属误导。               好了,这个现象就像是咳嗽。咳嗽的发生有无数种理由。肺癌会咳嗽,支气管炎会咳嗽,咽炎会咳嗽,感冒会咳嗽,呛到水了也会咳嗽。 在计算机上也同理。       以下是Tom's hardware论坛上一位老外大牛的精辟阐述:        What this error is telling you is that the card has crashed.       This is generally a hardware problem. It could be brought on by an excess of heat, a bad overclock, something wrong with the card itself, or something wrong with a part feeding the card (MB or Power). If the card is clean, you are sure nothings else in the system is broken, and the cards are not overclocked then the issue is probably with the cards or the motherboard.        This is a specific error (in a way.. it is also painfully general in that it does not tell you the exact issue) as it points directly to the GPU. It is very unlikely the problem is with a part of the system unrelated to the GPU (overclock on the memory or cpu for instance). However, SLI or crossfire adds an extra bit of issue to this as cards that work fine alone may have problems together that would trigger TDR.      他的意思主要是:跳这个错误,总是指向跟GPU相关的问题。但具体是什么问题非常难以确定。有可能是过热,有可能是胡乱超频,有可能是显卡体质, 有可能是驱动。      从我几天中看到的无数错误报告中,可以总结出以下几点相对宽泛的结论:        1. 出现在各种显卡,各种驱动中。且XP没有这问题。都是出现在Vista或Win7。看起来像是废话,TDR本来就是Vista之后才有的服务嘛!其实这不是废话。因为很多人的 系统是在XP跑得很好,同样的硬件升级到Vista和Win7之后频繁出错。这意味着很大程度上,跳这个错误是在误杀,overkill。系统软硬件没有问题,是新操作系统的配合 出了问题。      2. 大量的黑屏跳框出现在显卡低负荷状态下,比如看网页用qq,很少的出现在高负荷状态下,比如渲染软件,吃显卡游戏。有一些出现在某些游戏的特定场景中,而且 一定出现非常准时。这意味着显卡本身的硬件质量问题虽然不能排除,但绝不是主流的原因。        3. 很多种方法都解决了各自系统中的问题,比如换XP,显卡降频,禁用光驱,换大功率电源,刷显卡BIOS,换驱动,取消win7带3D的主题,取消win7的Aero功能,用16 位色。但没有一种能解决所有人,甚至只是大部分人的问题。        4. 禁用TDR服务能够保证你不跳框。其他什么都不保证。这就像是用麻醉咽喉来治疗咳嗽。能保证你不咳,其他什么都不保证。 除了禁用光驱这个我想破头也想不明白,其他的解决方案多少都是可以理解的。要理解它们,先来看下TDR到底怎样工作。             TDR是微软为了解决显卡挂起导致系统死机的问题而开发的,首先在Vista上启用,后来在Vista SP1上有更新,win7下全盘继承。发展这个的原因很微软:windows的爱崩溃 在XP年代及以前,是大家嘲笑的对象。所以微软下了大功夫来解决崩溃死机的问题。他们的统计发现,XP约有20%的系统崩溃/卡死是因为显卡挂起,需要重启,占所有分类 故障原因的头把交椅。而显卡挂起的原因又是多种多样的。因此头痛医头,脚痛医脚的TDR就应运而生。它不是去解决显卡的问题,而是致力于先要诊断显卡挂起,而在确诊后, 系统用一个服务去热重启显卡,结果系统就没有崩溃/卡死嘛!这就是微软的终极目的。       TDR的工作流程:        1.WIN系统中有一个服务组件,一直在检测系统图形堆栈中GPU执行每个任务的时间。Vista的默认超时点为2秒,(Win7默认没有变,但判断程序有区别)。如果GPU要认领一 个任务,但超过等待时间之后还没认领到手,或者认领之后超过等待时间还发来没完成响应,则系统诊断GPU已经挂起了。这个过程叫超时等待检测。       2.操作系统准备恢复GPU。它会通知WDDM 驱动程序,停止GPU访问其他硬件(如内存)的权限,并搜集硬件状态信息。       3.操作系统重置图形堆栈的回溯状态。图形堆栈中清除视频内存的分配。WDDM驱动程序重置GPU硬件状态。图形堆栈执行最后的操作,并将桌面恢复到响应的状态。        OK,以上第三步的动作就是你的黑屏和恢复跳框。1,2步的时候用户感受是桌面反应迟缓,不可用。类似于死机之前,但时间很短暂。 在Vista SP1,TDR又做了一些改进,大体是放宽了判据,改为侦测多次短暂挂起。具体的参数没有找到。     看完TDR的工作流程之后,可以试着来看看这些解决方法的道理: 显卡降频:原来的超频不当,使得显卡反应在某些条件下迟缓了,被TDR误杀。 换大功率电源:供电能力不足导致显卡反应迟缓,被TDR时不时点名批评。 取消window的3D,Aero,上16位色:这一系列的解决方案能起作用,都意味着windows主界面的显示需求和显卡之间的配合出现了问题。显然不是显卡能力的问题: windows那点界面花招,刚性需求哪能跟游戏比。问题基本可以肯定是出现在2D和3D频繁切换时,显卡由于工作频率频繁切换,出现了瞬间反应迟缓的问题。这是 显卡硬件,固件,驱动和windows界面显示需求几方面配合不良出现的小摩擦,本来不是大问题,用户可以完全无知无觉,但是在TDR的没事找事,放大之下,成了很恶心的用户体验。      换显卡驱动能解决一些人的问题,也证明了这种配合问题不是什么大毛病。      进游戏特定场景出问题:看起来也像是2D/3D切换带来的麻烦。      刷显卡BIOS:刷法是把2D和3D的工作频率刷平。这个解释已经很明显了。      禁用TDR:KO。 换XP:KO的平方。。。       原理基本清楚了,现在来看遇到的时候该怎么解决。 首先来认识另一位Tom's hardware的大牛,这人是个修电脑的,也是个认死理的。在已知显卡降频、禁用TDR、禁用windows 3D主题可以完美解决某客户问题后,拒绝接受这些屈服 性方案。他把一套硬件逐个换,驱动逐个试,各自跑了几星期之后,终于得出以下结论:       So my conclusion: this is a Windows problem with drivers and hardware which can only be fixed by replacing the video card with one requiring completely different drivers. Then you can go back to the original drivers and video card without problems (for who knows how long before they become corrupted again). Something in Windows (Vista & Win 7) is corrupting drivers from both Intel and ATI.       简单滴说,排除其他硬件故障和驱动问题之后,他认为这是windows的内在问题。在他的试验中,出问题的系统换成另一块完全用不同的驱动的显卡,可以解决,但不能长时间维持。 解决之后换回原来的显卡和驱动,又能正常工作了,但还是不能长时间维持。所以这个问题居然有了时间因素了:“Win7和Vista里面有某种邪恶的存在,在腐蚀显卡驱动程序, 不管是N卡还是A卡!”       听起来像是危言耸听,但看了官方的TDR的工作原理之后,我觉得他的结论也不是不可能。因为TDR首先是一个诊断程序,诊断程序不太可能只用2秒这么一个死板的参数。肯定还有 另外一些没有公布的,搜集硬件数据的判据。而这些数据是积累-学习型的。诊断程序现在很多都会学习。TDR的邪恶大概就就在于它的诊断程序不好,太敏感,经常对显卡运行的 小毛刺甚至显卡驱动的一些无辜信息大动干戈。而且这些误差会随着它的学习程序而积累。这也解释了为什么这故障很多,但并不是每台win7的机器都有:TDR在大多数的系统环境下 还是能正常诊断的,只是在某些显卡/驱动/硬件环境/操作系统/使用条件组合下,它对显卡反应迟滞和挂起之间的区别产生了微妙的误解。我看所有报告的感觉,似乎是中低端的显卡 和新驱动的组合,误杀的可能性和频率越变大。有一些开发商有意改进的特定版本新驱动,出错的可能性会变小,比如560Ti的 285.66驱动。这意味着开发商也知道是什么出了问题, 有一些驱动的解决办法,但不完美。      我的解决方案: 首先是更换驱动。我的硬件都是新买的,装机诊断很认真,来源很可靠,系统装得也很仔细。那么最大的可能性是驱动。我三次黑屏都在驱动285.62版本下。更换295.73后,我有意地 多次运行大游戏并多进程切换界面,取消/恢复windows界面效果,跑Aero应用。自我感觉很好,一直没出问题,但是正在得意了一个星期之后,又出现一次。这次包括黑屏之前连跳两个 “GUI挂起”消息,在毫无显示负载的情况下。 这证明更换驱动只是部分解决了配合问题,“邪恶的”TDR仍然会在用户图形界面做出一些奇怪的错误动作时,黑屏误杀。 于是我果断禁用了TDR。到现在为止,一切正常,没有发生过问题。      我的最终建议:     1. win7系统下黑屏恢复,且跳出“显示器驱动程序已停止响应并且已成功恢复”,跳这个错误,除了指向显示问题,什么都没有说明。你首先是需要忽略这个东西,从其他证据来分析 你的显示系统究竟有什么问题。如果你显卡过热或者过分超频或者电源不行,那么禁用TDR不能解决问题,只能让你频繁死机。不要简单听信任何一种神奇的解决方案,因为人家的问题 很可能不是你的问题。初步分析出原因,再说解决方法。      2.出问题的大多数人的硬件自身都没问题,纯粹是windows在作孽。如果你对自己的硬件判断没有信心,而且不在乎界面漂亮,你大可以取消win7高级界面风格试试,就算给黑社会交 保护费消灾了。      3 如果你有信心,判断自己的显卡硬件没问题,禁用TDR是个好选择。毕竟现在的windows没那么容易崩溃了。禁用TDR的负面效果,是你真正因为显卡挂起而死机的时候,会真的死掉, 而不是win7帮你热重启显卡。其实这还是一个怀疑自己显卡/驱动是不是真有问题时的诊断方法:禁掉TDR,看它死不死机。      4.换显卡驱动是很简单的事,不妨一试。但很可能不能完全解决问题。 不推荐刷显卡BIOS,动作有风险,而且这保护费也交得太高了!2D跑3D频率对显卡不太好。      最后,禁用TDR的注册表值: HKLM\System\CurrentControlSet\Control\GraphicsDrivers的TdrLevel:REG_DWORD。修改值为:TdrLevelOff(0)-禁用检测。 (https://msdn.microsoft.com/en-us/library/windows/hardware/ff569918(v=vs.85).aspx)     修改方案2:      1. Open REGEDIT      2. Using Windows 7, go to HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Control\GraphicsDrivers      3. Once there you will most likely have to create a new DWORD (32bit users) or QWORD (64bit users). Name it TdrDelay.      4. Once created, change the value to 8. This will allow the GPU 8 seconds to respond instead of 2 seconds. I did this myself, and now im back up and running at full speed. I can watch my movies and play all my games again! Cheers!
0 0 447天前
快速发帖 高级模式
桂公网安备 45010302000666号 桂ICP备14001770-3号
您的IP:54.160.153.233,2018-02-26 09:28:13,Processed in 1.07812 second(s).
免责声明: 本网不承担任何由内容提供商提供的信息所引起的争议和法律责任。
Powered by HadSky 5.4.1