ndis.sys BSOD

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:

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.

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??

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

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

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.

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