先抛出个结论,之后给分析结果,说明(文中的dllmain对应dll入口点,模块的入口点函数名不一定名字都是dllmain)
结论:
Dwm.exe进程初始化LdrInitializeThunk内部先映射dll,在一块儿调用这些dll的dllmain,在调用user32的dllmain时,加载英伟达的nvinitx.dll这个模块使用SHGetShellFolder,该函数使用了rpcrt4.dll中的一些数据,但是锁相关数据还没有被初始化(因为按调用顺序先后还没有调用到rpcrt4.dl它的dllmain)就使用,之后导致异常,出现死锁情况。最终导致黑屏或者卡在系统欢迎界面。
分析的简要过程:1.从卡时获取的dump上看explorer卡在ConnectPort到dwm.exe的一个port。
2.查看dwm.exe中的线程,发现其中一个线程卡在调用SHGetShellFolder函数内部。这个卡之后就导致explorer.exe工作异常,一直卡在链接dwm.exe中的port。
3. 查看锁sechost!SddlSidLookupCritical的状态,发现此锁被dwm.exe主线程占用,没有释放。 仔细分析发现主线程正常情况下不应该释放不了这个临界区。
4.猜测只可能出现什么异常导致没有释放这个临界区。
(上双机调试)调试发现dwm.exe的主线程中英伟达nvinitx.dll的dllmain会调用SHGetFoldPathW函数,这个函数调用的时候,已经占用了锁SddlSidLookupCritical,这个时候在去调用RPCRT4.dll中相关函数,却在调用EnterCriticalSection获取rpcrt4的临界区GlobalMutex出现异常,跳出到shell32中的异常处理函数_GSHandlerCheck_EH,这个时候导致没有释放SddlSidLookupCritical锁,SHGetFoldPathW就返回了。查看了下异常,发现rpcrt4中的临界区该临界区GlobalMutex没有初始化,dllmain 内部很多其它变量值也没有初始化,可以确定是dllmain没有被调用到。
5. ida分析可以知道GlobalMutex的初始化在rpcrt4.dll的dllmain内部 。所以可以知道出问题的原因就是rpcrt4.dll的dllmain没有调用到,那么为什么会导致这个dllmain没有调用掉呢?
6. 分析发现这个SHGetFoldPathW的调用是在nvinitx.dll的dllmain中。
ntdll!LdrpInitializeProcess函数先映射导入表中的dll在调用这些dll中的dllmain函数。
这个出问题环境调试发现rpcr4.dll中dllmain并没有调用到,这个时候gdi32的dllmain函数内部调用loadlibrary加载nvinitx.dll,并调用nvinitx.dll的dllmain函数,但是这个时候调用LdrpLoadDll加载rpcr4.dll的时候,(之前刚映射,这个时候LdrpLoadDll发现rpcr4.dll已经被映射了,所以就不会调用这个rpcr4.dll的dllmain函数)
Loadlibrary调用LdrpLoadDll(这个函数先检查模块rpcr4.dll是否映射,发现已经映射就不会调用这个的dllmain,接下来调用其它函数使用临界区GlobalMutex就出现异常崩溃)这个rpcr4.dll的dllmain会在接下来的ntdll!LdrpRunInitalizeroutines函数内部调用 。
7.更新了英伟达显卡驱动372.54及372.70版本后,开机启动过程中,经过上面一系列的异常调用,最终系统会被卡在欢迎界面或个别电脑出现黑屏的情况。
相关阅读:
版权声明
本文仅代表作者观点,不代表本站立场。
本文系作者授权发表,未经许可,不得转载。
本文地址:/Hardware/xianka/96022.html