Ndis.sys BSOD

Status
Not open for further replies.

altheman

Posts: 419   +0
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
 

Attachments

  • minidump.zip
    21.9 KB · Views: 9
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:
 
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??
 
The minidump you uploaded is dated 11th of october, and is therefore quite old.

Do you have any more recent mindumps?

Regards Howard :)
 
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:

--------------
EDIT
-------------
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.
 
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 :)
 
you are the only one who is helping, so im grateful :) . i'll look into the battery thing and try and get a replacement.
cheers
 
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.
 
Here are the details of your minidump.

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

THREAD_STUCK_IN_DEVICE_DRIVER_M (100000ea)
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.
Arguments:
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

DEFAULT_BUCKET_ID: GRAPHICS_DRIVER_FAULT

CUSTOMER_CRASH_COUNT: 1

BUGCHECK_STR: 0xEA

LAST_CONTROL_TRANSFER: from f7f7c534 to 804da0a4

STACK_TEXT:
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

FOLLOWUP_IP:
nv4_mini+52534
f7f7c534 ?? ???

SYMBOL_STACK_INDEX: 1

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nv4_mini+52534

MODULE_NAME: nv4_mini

IMAGE_NAME: nv4_mini.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 434b4d01

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 :)
 
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.

----
EDIT
----
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.
 
Status
Not open for further replies.
Back