先抛出个结论，之后给分析结果,说明（文中的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版本后，开机启动过程中，经过上面一系列的异常调用，最终系统会被卡在欢迎界面或个别电脑出现黑屏的情况。
