The Notebook Review forums were hosted by TechTarget, who shut down them down on January 31, 2022. This static read-only archive was pulled by NBR forum users between January 20 and January 31, 2022, in an effort to make sure that the valuable technical information that had been posted on the forums is preserved. For current discussions, many NBR forum users moved over to NotebookTalk.net after the shutdown.
Problems? See this thread at archive.org.

    Probably caused by : ntoskrnl.exe ( nt+7580c )

    Discussion in 'Alienware 17 and M17x' started by Mechanized Menace, Sep 8, 2010.

  1. Mechanized Menace

    Mechanized Menace Lost in the MYST

    Reputations:
    1,370
    Messages:
    3,110
    Likes Received:
    63
    Trophy Points:
    116
    I just BSOD'd three times in a row in Battlefield Bad company 2 because of this. What is this file? and how do i fix it?
     
    Mechanized Menace, Sep 8, 2010
    #1
  2. nzgeek

    nzgeek Notebook Evangelist

    Reputations:
    130
    Messages:
    352
    Likes Received:
    15
    Trophy Points:
    31
    I assume that you're running Windows 7 x64, and that you've got the latest patches installed.

    If that's the cause, then ntoskrnl.exe + 7580c if probably at the end of the function ObfDereferenceObject. From what I can see, this function is used by drivers in order to decrease the reference count to a kernel object.

    There's no easy way to figure out exactly which driver caused the issue. The only way is to install the Debugging Tools for Windows (x64 version here), then use that to analyze the dump file. There's a tool called WhoCrashed that can do some of the work for you, but I don't know how good it is. Your best bet is to give it a go and see what it tells you.

    If that doesn't work, post back and I'll see if I can step you through setting up the debugging tools properly in order to analyze the dump by hand.
     
    nzgeek, Sep 8, 2010
    #2
  3. Mechanized Menace

    Mechanized Menace Lost in the MYST

    Reputations:
    1,370
    Messages:
    3,110
    Likes Received:
    63
    Trophy Points:
    116
    I downloaded the Windows debugging tools already and used WinDBG to read the mini dump that is what it said it was probably caused by : Ntoskrnl.exe (nt+7580c) here is the mini dump file itself.
    090810-11029-01.dmp
     
    Mechanized Menace, Sep 9, 2010
    #3
  4. nzgeek

    nzgeek Notebook Evangelist

    Reputations:
    130
    Messages:
    352
    Likes Received:
    15
    Trophy Points:
    31
    That'll be where the faulty instruction occurred, but the real problem will be further down the call stack.

    Try opening the dump again and run the following commands:
    Code: 
    .symfix
!analyze -v
    .symfix will cause WinDBG to load symbols for Windows components from Microsoft. This allows you to look down the call stack, and see more info about the API calls inside the Microsoft components.

    !analyze -v analyzes the dump, and prints out a lot more information about the exception. The most important things to look for are what the error code is (e.g. ERROR_ACCESS_VIOLATION) and the call stack. Have a look for the first line with a ".sys" file name in it. This will almost certainly be the driver that's doing things wrong.

    If you're not sure about anything, post the results here and I'll have a look. If you feel like tinkering, you can find a list of WinDBG commands on windbg.info. It's a reference I have printed out at work for when I need to look at app crash dumps.
     
    nzgeek, Sep 9, 2010
    #4