操屁眼的视频在线免费看,日本在线综合一区二区,久久在线观看免费视频,欧美日韩精品久久综

新聞資訊

    一、事出原因

    最近不知道怎么回事,家里電腦經常性地出現藍屏(先死機后藍屏),很多時候有些文檔沒有保存便藍屏導致文檔丟失,其中也包括您現在正在看到的這一篇文章(撰寫本文時,藍了一次),以前一直比較懶,重啟大法一頓懟,然后重新再做編輯,只不過PPT重做簡直要人命,無奈之下,放下了所有的工作,來研究研究藍屏的原因,順便正兒八經使用一下Typora。

    PS:本文結尾提到的解決方案較為野蠻粗暴,可能讓你本就不富裕的家庭雪上加霜,請慎用!



    二、準備工作

    1. 使用的工具:WinDBG
    2. 導入的文件:C:\Windows\Minidump\xxxxxx.dmp

    關于WinDBG這款神器想必無需再做多的介紹,至于導入文件的目錄為windows在遇到藍屏之后會保存的dmp文件所在的位置,我的電腦是Win10系統,其它系統目前暫時不知道,在網上也有看到消息說要提前設置好,但是我并沒有設置,這里也貼一下設置的圖片吧。

    也有文章說寫入調試信息需要選擇第一個。

    另外需要設置WinDBG的訪問符號,在WinDBG官網中可以看到

    Symbol Server (Microsoft):

    復制代碼 隱藏代碼
    srv*c:\mss*http://msdl.microsoft.com/download/symbols

    Symbol Server (Citrix):

    復制代碼 隱藏代碼
    srv*c:\css*http://ctxsym.citrix.com/symbols
    .symfix c:\mss.sympath+ srv*c:\css*http://ctxsym.citrix.com/symbols

    可使用環境變量設置,也可在軟件File - Symbol File Path中進行設置,至此,準備工作一切就緒,下面即可進行分析。


    三、分析過程

    WinDBG打開dmp文件,稍等一會便可出現分析報告,我的分析報告如下:

     復制代碼 隱藏代碼
    Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
    Copyright (c) Microsoft Corporation. All rights reserved.
    
    Loading Dump File [C:\Users\Tory\Desktop\120421-10187-01.dmp]
    Mini Kernel Dump File: Only registers and stack trace are available
    
    Symbol search path is: SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols;SRV*c:\mysymbol* http://msdl.microsoft.com/download/symbols
    Executable search path is: 
    Windows 7 Kernel Version 19041 MP (6 procs) Free x64
    Product: WinNt, suite: TerminalServer SingleUserTS
    Machine Name:
    Kernel base = 0xfffff805`67c00000 PsLoadedModuleList = 0xfffff805`6882a1d0
    Debug session time: Sat Dec  4 20:02:02.508 2021 (UTC + 8:00)
    System Uptime: 0 days 1:07:26.549
    Loading Kernel Symbols
    ...............................................................
    ................................................................
    ................................................................
    ................
    Loading User Symbols
    Loading unloaded module list
    .........
    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************
    
    Use !analyze -v to get detailed debugging information.
    
    BugCheck 3B, {c0000005, fffff80567efbfd2, ffffe90838039420, 0}
    
    Probably caused by : Unknown_Image ( PAGE_NOT_ZERO )
    
    Followup: MachineOwner
    ---------
    
     *** Memory manager detected 62334 instance(s) of page corruption, target is likely to have memory corruption.
    
    5: kd> !analyze -v
    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************
    
    SYSTEM_SERVICE_EXCEPTION (3b)
    An exception happened while executing a system service routine.
    Arguments:
    Arg1: 00000000c0000005, Exception code that caused the bugcheck
    Arg2: fffff80567efbfd2, Address of the instruction which caused the bugcheck
    Arg3: ffffe90838039420, Address of the context record for the exception that caused the bugcheck
    Arg4: 0000000000000000, zero.
    
    Debugging Details:
    ------------------
    
    EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - 0x%p
    
    FAULTING_IP: 
    nt!RtlpIsNameInExpressionPrivate+92
    fffff805`67efbfd2 6683382a        cmp     word ptr [rax],2Ah
    
    CONTEXT:  ffffe90838039420 -- (.cxr 0xffffe90838039420)
    rax=ffff7b83a1b1ab84 rbx=0000000000000074 rcx=ffffa583a1b1ab40
    rdx=ffffe90838039fb0 rsi=0000000000000000 rdi=ffffa583a1b1ab40
    rip=fffff80567efbfd2 rsp=ffffe90838039e20 rbp=0000000000000000
     r8=0000000000000000  r9=ffffa583a1b1ab40 r10=0000000000000032
    r11=ffffe90838039fb0 r12=0000000000000000 r13=ffffbb07cac1d880
    r14=0000000000000000 r15=000000000000005c
    iopl=0         nv up ei pl nz na po nc
    cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00050206
    nt!RtlpIsNameInExpressionPrivate+0x92:
    fffff805`67efbfd2 6683382a        cmp     word ptr [rax],2Ah ds:002b:ffff7b83`a1b1ab84=????
    Resetting default scope
    
    CUSTOMER_CRASH_COUNT:  1
    
    DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT
    
    BUGCHECK_STR:  0x3B
    
    PROCESS_NAME:  QQPYUserCenter
    
    CURRENT_IRQL:  0
    
    BAD_PAGES_DETECTED: f37e
    
    LAST_CONTROL_TRANSFER:  from fffff80567efbe58 to fffff80567efbfd2
    
    STACK_TEXT:  
    ffffe908`38039e20 fffff805`67efbe58 : ffffbb07`00000003 00000000`00000000 ffffbb07`cac1d880 00000000`00000000 : nt!RtlpIsNameInExpressionPrivate+0x92
    ffffe908`38039f10 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!RtlIsNameInExpression+0x48
    
    SYMBOL_NAME:  PAGE_NOT_ZERO
    
    FOLLOWUP_NAME:  MachineOwner
    
    MODULE_NAME: Unknown_Module
    
    IMAGE_NAME:  Unknown_Image
    
    DEBUG_FLR_IMAGE_TIMESTAMP:  0
    
    STACK_COMMAND:  .cxr 0xffffe90838039420 ; kb
    
    BUCKET_ID:  PAGE_NOT_ZERO
    
    Followup: MachineOwner
    ---------
    
     *** Memory manager detected 62334 instance(s) of page corruption, target is likely to have memory corruption.
    

    重點關注第30行以下,其中BugCheck 3B, {c0000005, fffff80567efbfd2, ffffe90838039420, 0}大致可以看出錯誤代碼為0x0000003B,百度一下即可知該錯誤代碼多為軟硬件兼容性問題,此事心里大概有一個底了。Probably caused by : Unknown_Image ( PAGE_NOT_ZERO )這里其實可以關注一下,由于結果未“Unknown_Image”所以也失去了分析它的意義了。

    其實低49-54行給出了導致錯誤的進程具體位置,這個我看不懂,感興趣的大佬可以給我解釋一下,要怎么分析到他的具體地址。

    從第81行開始較為重要,其中拋出的“VISTA_DRIVER_FAULT”表示訪問驅動錯誤,PROCESS_NAME指向了QQPYUserCenter,表示罪魁禍首是該進程,即“QQ拼音用戶中心”,但是我實在想不通為什么QQ拼音和驅動又有關系了。

    繼續向下看到第94、95行, 表示該進程調用了ntdll中的RtlIsNameInExpression之后又調用了RtlpIsNameInExpressionPrivate+0x92函數時出錯了,該問題也可在第62-64行能夠清楚看到具體出錯的反匯編代碼。

     復制代碼 隱藏代碼
    FAULTING_IP: 
    nt!RtlpIsNameInExpressionPrivate+92
    fffff805`67efbfd2 6683382a        cmp     word ptr [rax],2Ah

    四、總結

    至此,分析全部結束,并做一下最終的總結:此次藍屏主要原因是QQPYUserCenter與某個軟硬件發生驅動訪問時出現問題,既然有驅動則多為硬件所致。

    在網上查詢了很多信息,用排除法最終鎖定了“Logitech MouseWare”即羅技鼠標,因為外設我就用了羅技的鼠標和鍵盤。


    五、解決方案

    更新Logitech的驅動


    六、參考文獻

    WinDBG官網

    WinDbg分析藍屏dump原因

    安裝與配置windbg的symbol(符號)

    WinDbg 藍屏分析 Windows Dump 文件教程

    windbg-> !analyze -v 信息詳解

    《藍屏0x0000003b》的解答

    電腦藍屏原因很多,但是大都是硬件和驅動程序不兼容所引起的,要想修復藍屏問題我們通過Windbag來對藍屏原因進行定位,Windbg是一款強大的調試工具,可能有很多小伙伴還不知道Windbg工具的使用方法,那就來看一下使用Windbg進行藍屏原因定位的使用教程吧。

    藍屏修復工具Windbg使用教程

    1、要使用Windbg,首先要設置好藍屏轉儲,這樣當藍屏時系統會以.dmp文件方式保留藍屏故障原因。右鍵單擊桌面計算機圖標--選擇屬性,單擊高級系統設置,在啟動和故障恢復欄中單擊設置,在寫入調試信息欄中選擇小內存轉儲(如果已經設置了可忽略此步驟),小轉儲目錄為%SystemRoot%\Minidump(藍屏文件存放位置),也就是C:\Windows\Minidump文件夾。

    2、搜索下載安裝Windbg。

    3、安裝成功后,啟動Windbg。

    4、先為Windbg軟件設置符號表路徑,作為藍屏原因分析數據庫,否則軟件將沒有作用。單擊File--選擇Symbol File Path。

    5、在彈出的對話框Symbol Path文本框中輸入SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols,單擊OK。

    6、設置完畢后單擊File--選擇Open Crash Dump來打開藍屏文件,在彈出的對話框中點選到C:\Windows\Minidump文件夾,單擊我們要分析的藍屏文件,單擊打開。

    7、接下來就是對文件進行分析,這需要一定的經驗和知識。這里我們著重可以看一下System Uptime(開機時間)和Probably Caused By(可能引起故障的原因是)。

    8、需要進一步分析,可以單擊!analyze -v

    9、可以從中提取到藍屏錯誤代碼和引起藍屏的程序名稱,再通過網絡搜索這些程序名和代碼等方式弄清原因。

    以上就是藍屏修復工具Windbg使用教程的全部內容,通過使用Windbg,我們就能比較容易的確定導致電腦藍屏的原因了。

網站首頁   |    關于我們   |    公司新聞   |    產品方案   |    用戶案例   |    售后服務   |    合作伙伴   |    人才招聘   |   

友情鏈接: 餐飲加盟

地址:北京市海淀區    電話:010-     郵箱:@126.com

備案號:冀ICP備2024067069號-3 北京科技有限公司版權所有