Computer crashes after few minutes when putting to sleep - BSOD

Monday, August 19, 2019

BC - https://www.bleepingcomputer.com/forums/t/702602/computer-crashes-after-few-minutes-when-putting-to-sleep/?p=4852247



jcgriff2


  • BSOD Kernel Dump Expert

  • 1,237 posts

  • ONLINE

  •  
    • Gender:Male
    • Location:New Jersey Shore
    • Local time:12:33 PM
    Posted Today, 12:33 PM
    Hi. . .
     
    You are getting closer - but no cigar yet!
     
    With 0x9f (0x3,,,) bugcheck dumps, you need to run the !irp command on P4 (Paremeter 4 - the 4th number inside the parenthesis after the 0x9f bugcheck).
     
    So... after you run !analyze-v and perhaps one of the list [loaded] modules commands (like lmnt or lmntsm to view the loaded [into RAM] drivers, you then want to run a  .bugcheck command to obtain P4, then run the   !irp command. It should then tell you the 3rd party driver that is hiding under pci.sys. pci.sys is a Microsoft Windows driver and therefore cannot be the actual cause of your BSODs as Windows drivers are sacrosanct.
     
    Anyway, in one of your dumps (all 3 dumps, by the way, had 0x9f (0x3,,,) bugchecks). So I just selected one of them - filename = 081419-18203-01.dmp
     
    As I mentioned, I first executed a Windbg kd> command - .bugcheck (note the period before "bugcheck"); the result -
    Bugcheck code 0000009F
    Arguments 00000000`00000003 ffff970c`7019f060 fffff807`6058e8b0 ffff970c`7e96f620
    The number we are after here is P4 - the 4th number (the memory address of the blocked IRP), which is ffff970c`7e96f620
     
    Then you issue the !irp command followed by P4, like this -
    !irp ffff970c`7e96f620 
    -
     
     
    . . .the output will be this -
    0: kd> !irp ffff970c`7e96f620
    Irp is active with 5 stacks 4 is current (= 0xffff970c7e96f7c8)
     No Mdl: No System Buffer: Thread 00000000:  Irp stack trace. 
         cmd  flg cl Device   File     Completion-Context
     [N/A(0), N/A(0)]
                0  0 00000000 00000000 00000000-00000000      Args: 00000000 00000000 00000000 00000000
     [N/A(0), N/A(0)]
                0  0 00000000 00000000 00000000-00000000      Args: 00000000 00000000 00000000 00000000
     [N/A(0), N/A(0)]
                0  0 00000000 00000000 00000000-00000000      Args: 00000000 00000000 00000000 00000000
    >[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
                0 e1 ffff970c7f0c7050 00000000 fffff8076399b3d0-ffff970c84fcdc00 Success Error Cancel pending
           *** WARNING: Unable to verify timestamp for L1C63x64.sys
    *** ERROR: Module load completed but symbols could not be loaded for L1C63x64.sys
     \Driver\L1C nt!PopSystemIrpCompletion
       Args: 00014400 00000000 00000004 00000002
     [N/A(0), N/A(0)]
                0  0 00000000 00000000 00000000-ffff970c84fcdc00      Args: 00000000 00000000 00000000 00000000
    ... but you are only after the portion of non-zero numbers in the center -
    >[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
                0 e1 ffff970c7f0c7050 00000000 fffff8076399b3d0-ffff970c84fcdc00 Success Error Cancel pending
           *** WARNING: Unable to verify timestamp for L1C63x64.sys
    *** ERROR: Module load completed but symbols could not be loaded for L1C63x64.sys
     \Driver\L1C nt!PopSystemIrpCompletion
       Args: 00014400 00000000 00000004 00000002
    If you look through that jumbled mess of data, you will see    L1C63x64.sys  
     
    That is your  Qualcomm Atheros AR8171/8175 PCI-E Gigabit Ethernet Controller (NDIS 6.30) driver (this info came from a file in your zip attachment - systeminfo - at the very bottom of the report).
     
    Next, we look up the driver in the Sysnative Driver Reference Table (DRT) as we need a driver update site. The DRT contains over 4,500 drivers in it that we've been working on for over 9 years now. Drivers are manually added 1-by-1 to the SQL DRT table.
     
    DRT - https://www.sysnative.com/drivers/ -- enter the driver name in the search box
     
    It returns - https://www.sysnative.com/drivers/driver.php?id=L1C63x64.sys - and lists 2 possible driver update sites.
     
    Please note that Atheros in general does not keep their drivers updated, so you may not be able to find an update. If so and your system is a desktop PC, you'll need to purchase a new(er) PCIe Ethernet card to continue using Ethernet or live with the blue screens as they will likely increase in number and frequency as time goes on. Basically, you have another app or it could be a Windows networking related driver that is not playing nice with your current Atheros Ethernet driver. Some other driver has a conflict with it. 
     
    The likely problem with your Atheros driver is its age -
    L1C63x64.sys Mon Sep 18 13:32:11 2017 (59C02D4B)
    Two years old for a networking driver in today's world is very old. Most driver developers (like Intel, Netgear, etc...) update every 4-6 months - both Ethernet and wifi.
     
    So, you need to locate an Atheros driver update with a timestamp greater than September 2017.
     
    Please let me know how you make out.
     
    Also, try the !irp command on the dumps. I think that you did very well with Windbg, especially setting up the symbol path, which is where most people trying Windbg fail.
     
    Regards. . .
     
    jcgriff2
     
     
     
     



     
     
     
     
     

    244x90_BC_04-04-2019.png

    0 comments:

    Text

    Powered by Blogger.

    Search This Blog

    Popular Posts