1. TechSpot is dedicated to computer enthusiasts and power users. Ask a question and give support. Join the community here.
    TechSpot is dedicated to computer enthusiasts and power users.
    Ask a question and give support.
    Join the community here, it only takes a minute.
    Dismiss Notice

ndis.sys BSOD

By altheman ยท 12 replies
Nov 24, 2005
  1. Hi all!!
    I booted my pc and windows got stuck at the loading screen. I rebooted, got through to the desktop, ran chkdsk/f, and rebooted again to do the check.
    After chkdsk, the pc rebooted automatically, and after the loading bar, I got a BSOD with ndis.sys in the description. after reboot, it happened again, but thrid time i got through.
    I think this may be 'cos i patched my tcpip.sys to increase the number of half open connections, because after googling, I found that NDIS meant Network Driver Interface. I unpatched it again, and have had no bsods so far. after loading the minidump on windbg, it gave the message that it was a graphics driver fault. I reinstalled my nvidia driver, although i sure that nvidia was not the cause.
    Anyway, id like to get to the bottem of this, as last time it happened, i had to reinstall windows to fix it. Ive attached the minidump so all you clever ppl can have a look at it. :)
    My specs:

    Win XP Pro, SP2
    Geforce 5200fx
    120gb seagate hd
    512 pc3200 ram

    thanks in advance

    Attached Files:

  2. howard_hopkinso

    howard_hopkinso TS Rookie Posts: 24,177   +19

    Hello and welcome to Techspot.

    Yes your minidump does indeed reference your videocard driver. More interestingly perhaps is the bugcheck of EA.

    A device driver problem has caused the system to pause indefinitely (hang). Typically, this is caused by a display driver waiting for the video hardware to enter an idle state. This might indicate a hardware problem with the video adapter, or a faulty video driver.

    In this case it does seem as though your videocard, or driver is responsible.

    Regards Howard :wave: :wave:
  3. altheman

    altheman TS Rookie Topic Starter Posts: 425

    thanks for the quick reply.

    im not used to this stuff which is why im a bit confused.
    why does it reference ndis.sys in the blue screen, and also, this problem has occured only very recently. im am in the process of upgrading my graphics card, so will this help.
    is it possible that anyother factors are causing it??
  4. howard_hopkinso

    howard_hopkinso TS Rookie Posts: 24,177   +19

    The minidump you uploaded is dated 11th of october, and is therefore quite old.

    Do you have any more recent mindumps?

    Regards Howard :)
  5. altheman

    altheman TS Rookie Topic Starter Posts: 425

    my windows date and time are correct. it might be my bios time, but ill check this later. the BSOD happened yesterday 24th Nov. im not sure why the minidump is dated like that, unless another bsod happened before. my options are set to write a minidump, and to not auto restart.
    btw after the dump is loaded, this line loads up:
    Debug session time: Thu Nov 10 18:59:06.858 2005 (GMT+0)
    seems like my time management is screwed :mad:

    just checked my bios, time and date are 100% correct. my only explanation is that the time and date of windows was wrong before, but was syncronized via the net. last sync time was yesterday at 19.01.
  6. howard_hopkinso

    howard_hopkinso TS Rookie Posts: 24,177   +19

    That could be a symptom of a faulty cmos battery. Change the cmos battery.

    Regards Howard :)
  7. altheman

    altheman TS Rookie Topic Starter Posts: 425

    could the cmos battery cause a bsod??
  8. howard_hopkinso

    howard_hopkinso TS Rookie Posts: 24,177   +19

    I don`t know is the answer. But it`s an explanation as to why your time gets screwed up.

    Like I said your minidump was quite old. In any case it`s very difficult to make a diagnosis from just one minidump. We normally require 5 or 6 minidumps.

    I don`t suppose I`m helping you much at the moment, but I can only tell you what was in the minidump you provided.

    Regards Howard :)
  9. altheman

    altheman TS Rookie Topic Starter Posts: 425

    you are the only one who is helping, so im grateful :) . i'll look into the battery thing and try and get a replacement.
  10. altheman

    altheman TS Rookie Topic Starter Posts: 425

    Quick update:
    I manually forced a BSOD (using the registry hack.) this time the minidump was correctly dated. im pretty sure now that the time and date on my pc was wrong. im not the only one who uses it, its a family pc. but id really like to get to the bottem of that first bsod.
  11. howard_hopkinso

    howard_hopkinso TS Rookie Posts: 24,177   +19

    Here are the details of your minidump.

    1: kd> !analyze -v
    * *
    * Bugcheck Analysis *
    * *

    The device driver is spinning in an infinite loop, most likely waiting for
    hardware to become idle. This usually indicates problem with the hardware
    itself or with the device driver programming the hardware incorrectly.
    If the kernel debugger is connected and running when watchdog detects a
    timeout condition then DbgBreakPoint() will be called instead of KeBugCheckEx()
    and detailed message including bugcheck arguments will be printed to the
    debugger. This way we can identify an offending thread, set breakpoints in it,
    and hit go to return to the spinning code to debug it further. Because
    KeBugCheckEx() is not called the .bugcheck directive will not return bugcheck
    information in this case. The arguments are already printed out to the kernel
    debugger. You can also retrieve them from a global variable via
    "dd watchdog!g_WdBugCheckData l5" (use dq on NT64).
    On MP machines it is possible to hit a timeout when the spinning thread is
    interrupted by hardware interrupt and ISR or DPC routine is running at the time
    of the bugcheck (this is because the timeout's work item can be delivered and
    handled on the second CPU and the same time). If this is the case you will have
    to look deeper at the offending thread's stack (e.g. using dds) to determine
    spinning code which caused the timeout to occur.
    Arg1: f8d1b600, Pointer to a stuck thread object. Do .thread then kb on it to find
    the hung location.
    Arg2: 82252450, Pointer to a DEFERRED_WATCHDOG object.
    Arg3: f896dcbc, Pointer to offending driver name.
    Arg4: 00000001, Number of times "intercepted" bugcheck 0xEA was hit (see notes).

    Debugging Details:

    FAULTING_THREAD: f8d1b600




    LAST_CONTROL_TRANSFER: from f7f7c534 to 804da0a4

    83ff2244 f7f7c534 f6c2c200 81eb34a0 f7f99e2f nt!READ_REGISTER_ULONG+0x6
    WARNING: Stack unwind information not available. Following frames may be wrong.
    83ff230c 8054f3a5 83ff232c 00000001 00000000 nv4_mini+0x52534
    83ff23c4 00000000 00000040 00000300 00000400 nt!MiReserveAlignedSystemPtes+0x2d2

    STACK_COMMAND: .thread fffffffff8d1b600 ; kb

    f7f7c534 ?? ???


    FOLLOWUP_NAME: MachineOwner

    SYMBOL_NAME: nv4_mini+52534

    MODULE_NAME: nv4_mini

    IMAGE_NAME: nv4_mini.sys


    FAILURE_BUCKET_ID: 0xEA_IMAGE_nv4_mini.sys_DATE_10_11_2005

    BUCKET_ID: 0xEA_IMAGE_nv4_mini.sys_DATE_10_11_2005

    Followup: MachineOwner

    Regards Howard :)
  12. gary_hendricks

    gary_hendricks TS Rookie Posts: 107

    Sounds like a video card driver problem.
  13. altheman

    altheman TS Rookie Topic Starter Posts: 425

    OK, it happened again. this time i ran chkdsk/f and rebooted. once it got to the countdown, it blue screened. no minidump, although my settings are set to make one.

    seemed that the problem was related to daemon tools 4. i uninstalled dt4 and ran chkdsk/f. no probs this time round. also ran memtest, no problems either.
Topic Status:
Not open for further replies.

Similar Topics

Add New Comment

You need to be a member to leave a comment. Join thousands of tech enthusiasts and participate.
TechSpot Account You may also...