If this is your first visit, be sure to check out the FAQ by clicking the link above.
You may have to register before you can post: click the register link above to proceed.
To start viewing messages, select the forum that you want to visit from the selection below.

As you see, it points to nv4_disp.dll as the probable culprit.
Presumably something has changed, but I can't fathom what. However, I
have had several hard crashes apart from the BSOD, mainly when using
my video editor (Movie Edit Pro 2014) so maybe that's another possible
cause.

After much research I found this article about the BSOD and followed
its instructions to download a replacement nv4_disp.dll file.

3. Has this bug (if that's what it is) been fixed in more recent
versions of the driver?

4. Which version is recommended for a user like me, no games but some
intensive video editing/rendering?

5. Why are there so many apparent duplicates of this file, and at
least two sizes?

6. Can I expect another similar export to work, or have I got to
replace the DLL with the small substitute again? (This is typically a
3 hour run, so not keen to repeat lightly without being confident it
won't cause a BSOD again.)

As you see, it points to nv4_disp.dll as the probable culprit.
Presumably something has changed, but I can't fathom what. However, I
have had several hard crashes apart from the BSOD, mainly when using
my video editor (Movie Edit Pro 2014) so maybe that's another possible
cause.

After much research I found this article about the BSOD and followed
its instructions to download a replacement nv4_disp.dll file.

3. Has this bug (if that's what it is) been fixed in more recent
versions of the driver?

4. Which version is recommended for a user like me, no games but some
intensive video editing/rendering?

5. Why are there so many apparent duplicates of this file, and at
least two sizes?

6. Can I expect another similar export to work, or have I got to
replace the DLL with the small substitute again? (This is typically a
3 hour run, so not keen to repeat lightly without being confident it
won't cause a BSOD again.)

Any advice would be warmly appreciated please.

I'm hardly an expert, but I can make a few suggestions.

First of all, the System folder and your DLLs are "protected"
by Windows File Protection. There are at least two copies
of the file, the working one and one in a DLLCache. If you
attempt to remove the working copy, the system notices the
file got changed, and replaces it with the one in the
DLLCache. That's how your system is overriding your
repair attempts. It's crafty.

So WFP has probably been preventing this "magic substitution"
of yours from actually working.

To replace a DLL, I would recommend reinstalling the
same version of driver again. When you run something
that has a "setup.exe", the OS knows it's an installation
attempt. It also knows, if the top level unpacking
operation unpacks a .msi and the system installer
routine is called to install the contents of the
..msi. So there are package formats that the operating
system recognizes as "needing the services and permissions
of installation".

Then the DLL unpacked can be copied into the two places,
and it becomes "the new king".

There are an infinite number of web pages that will
encourage you to do silly things. They will offer
you copies of DLL files you don't need (radically
wrong size), give you bad recipes for replacement and so on.

I generally keep a copy of my current driver (if I
can remember to do so), and add tags to the file name
so I know what it is later. I use two underscores in
a row, to separate the downloaded file name, from my
added tags. Maybe it would be

nvidia_driver__306_3_for_8800GT.exe

Then later, I can search on "306" or "8800GT" and
figure out where I left it. I'm not really organized
enough, to know what I did with it. That's why I use
a tagging system.

*******

For some reason, on this machine (WinXP) I can find

C:\NVIDIA\Win2k\175.19\English\

implying at some point, I must have "unpacked" a driver
not intended for this OS. You might look to see whether
the 306.3 driver is already sitting on your C: drive.

Now, it turns out, that is actually a Win2K/WinXP driver,
and the version happens to match what I'm using right
now (I just checked the version and figured out why
it is there). So that was put there when the driver
was originally installed.

While you could search for the 306.3 thing on
your computer, you could see if an unpacked driver
is already waiting to be (re)installed. Then you won't
need any of those cheap and cheerless sites that
encourage you to "copy DLLs".

You can do things like this. This would be
a typical sequence of an NVidia user who
does driver updates once in a while.

1) Install 175.19
2) Install 306.3

When you do that, the second installer should be using the
"uninstall" left behind by the first installer. So
the unstated "stage 1.5", is the uninstallation
of the existing file set.

Another way to do it would be:

1) Install 175.19
... time passes
2) Time to upgrade.
Uninstall 175.19 (Add/Remove or Programs and Features control panel)
The uninstaller will ask for a reboot.
3) System comes up in VESA fallback driver mode.
Screen is limited to 640x480 or 800x600.
Make sure you have a driver to run, as you
don't want to be parked in VESA mode forever :-)
4) Now, looking at your tiny screen, you
install 306.3 driver.
The installer asks for a reboot.
5) System comes up running NVidia 306.3

So that's an example of manual uninstall,
reinstall of something else, and involves
at least two reboots. The previous procedure
is even a way of changing from an NVidia card
to an ATI, or from an ATI to an NVidia card.
By uninstalling the driver while the old card
is still present, you avoid leaving cruft in the
System folder. You would change the video
card brand, just before step 3. So step 2.5
would be "change video card brand, swap in
new card".

So those are examples of valid ways of doing
things, and those ways rely on the Windows installer
logic (Windows recognizing the thing you're doing
is an install, and elevating appropriately for it),
as well as the logic inside the installer doing
the right thing, like removing the older driver
first before installing the new one.

*******

Lastly, if you get in a scrape, and you know what
you're doing, you can try messing with files while
booted into Linux. But this requires a thorough
understanding of Windows File Protection, and
isn't normally recommended unless you've made
a real mess. For example, you could uninstall
the existing NVidia driver, when it asks for
a reboot, you insert your Linux LiveCD and
go searching for extraneous files you left
there with your "experiments". Linux allows
you to override permissions or overcome
Windows File Protection.

Various third parties have made driver cleaners.
Back in the day, I probably used "Detonator Destroyer",
as I didn't know the "rules of driver removal", the
computer had at least three different brands of video
cards in it, and AGP DMA/DIME was busted on my system.
So I had no choice but to try to learn from my
mistake, by running *specific* (not general purpose)
driver cleaners. My system was so messed up, at
that point, I reinstalled the OS. So that's
what happens if you don't follow proper hygiene.
If you keep changing video cards, installing
different brands of drivers, without removing the
old ones, it can catch up with you.

*******

A BSOD from a video card, sure, it could be
a corrupted file. But just as easily, a
defect in a card, like bad video RAM, could
also cause problems. Or, it could even
be some other driver that has upset things.
Drivers run in Ring0, and drivers must
be designed by experts, as they can easily
"shoot one another in the foot". Programs
in Ring3, if they foul up, the important
system things are in Ring0 and are protected.
But a rogue driver, because it lives in
Ring0, can cause as much havoc as it wants.
Think back to anything you installed, just
before these problems appeared.

As you see, it points to nv4_disp.dll as the probable culprit.
Presumably something has changed, but I can't fathom what. However, I
have had several hard crashes apart from the BSOD, mainly when using
my video editor (Movie Edit Pro 2014) so maybe that's another possible
cause.

After much research I found this article about the BSOD and followed
its instructions to download a replacement nv4_disp.dll file.

3. Has this bug (if that's what it is) been fixed in more recent
versions of the driver?

4. Which version is recommended for a user like me, no games but some
intensive video editing/rendering?

5. Why are there so many apparent duplicates of this file, and at
least two sizes?

6. Can I expect another similar export to work, or have I got to
replace the DLL with the small substitute again? (This is typically a
3 hour run, so not keen to repeat lightly without being confident it
won't cause a BSOD again.)

Any advice would be warmly appreciated please.

I'm hardly an expert, but I can make a few suggestions.

First of all, the System folder and your DLLs are "protected"
by Windows File Protection. There are at least two copies
of the file, the working one and one in a DLLCache. If you
attempt to remove the working copy, the system notices the
file got changed, and replaces it with the one in the
DLLCache. That's how your system is overriding your
repair attempts. It's crafty.

So WFP has probably been preventing this "magic substitution"
of yours from actually working.

To replace a DLL, I would recommend reinstalling the
same version of driver again. When you run something
that has a "setup.exe", the OS knows it's an installation
attempt. It also knows, if the top level unpacking
operation unpacks a .msi and the system installer
routine is called to install the contents of the
.msi. So there are package formats that the operating
system recognizes as "needing the services and permissions
of installation".

Then the DLL unpacked can be copied into the two places,
and it becomes "the new king".

There are an infinite number of web pages that will
encourage you to do silly things. They will offer
you copies of DLL files you don't need (radically
wrong size), give you bad recipes for replacement and so on.

I generally keep a copy of my current driver (if I
can remember to do so), and add tags to the file name
so I know what it is later. I use two underscores in
a row, to separate the downloaded file name, from my
added tags. Maybe it would be

nvidia_driver__306_3_for_8800GT.exe

Then later, I can search on "306" or "8800GT" and
figure out where I left it. I'm not really organized
enough, to know what I did with it. That's why I use
a tagging system.

*******

For some reason, on this machine (WinXP) I can find

C:\NVIDIA\Win2k\175.19\English\

implying at some point, I must have "unpacked" a driver
not intended for this OS. You might look to see whether
the 306.3 driver is already sitting on your C: drive.

Now, it turns out, that is actually a Win2K/WinXP driver,
and the version happens to match what I'm using right
now (I just checked the version and figured out why
it is there). So that was put there when the driver
was originally installed.

While you could search for the 306.3 thing on
your computer, you could see if an unpacked driver
is already waiting to be (re)installed. Then you won't
need any of those cheap and cheerless sites that
encourage you to "copy DLLs".

You can do things like this. This would be
a typical sequence of an NVidia user who
does driver updates once in a while.

1) Install 175.19
2) Install 306.3

When you do that, the second installer should be using the
"uninstall" left behind by the first installer. So
the unstated "stage 1.5", is the uninstallation
of the existing file set.

Another way to do it would be:

1) Install 175.19
... time passes
2) Time to upgrade.
Uninstall 175.19 (Add/Remove or Programs and Features control panel)
The uninstaller will ask for a reboot.
3) System comes up in VESA fallback driver mode.
Screen is limited to 640x480 or 800x600.
Make sure you have a driver to run, as you
don't want to be parked in VESA mode forever :-)
4) Now, looking at your tiny screen, you
install 306.3 driver.
The installer asks for a reboot.
5) System comes up running NVidia 306.3

So that's an example of manual uninstall,
reinstall of something else, and involves
at least two reboots. The previous procedure
is even a way of changing from an NVidia card
to an ATI, or from an ATI to an NVidia card.
By uninstalling the driver while the old card
is still present, you avoid leaving cruft in the
System folder. You would change the video
card brand, just before step 3. So step 2.5
would be "change video card brand, swap in
new card".

So those are examples of valid ways of doing
things, and those ways rely on the Windows installer
logic (Windows recognizing the thing you're doing
is an install, and elevating appropriately for it),
as well as the logic inside the installer doing
the right thing, like removing the older driver
first before installing the new one.

*******

Lastly, if you get in a scrape, and you know what
you're doing, you can try messing with files while
booted into Linux. But this requires a thorough
understanding of Windows File Protection, and
isn't normally recommended unless you've made
a real mess. For example, you could uninstall
the existing NVidia driver, when it asks for
a reboot, you insert your Linux LiveCD and
go searching for extraneous files you left
there with your "experiments". Linux allows
you to override permissions or overcome
Windows File Protection.

Various third parties have made driver cleaners.
Back in the day, I probably used "Detonator Destroyer",
as I didn't know the "rules of driver removal", the
computer had at least three different brands of video
cards in it, and AGP DMA/DIME was busted on my system.
So I had no choice but to try to learn from my
mistake, by running *specific* (not general purpose)
driver cleaners. My system was so messed up, at
that point, I reinstalled the OS. So that's
what happens if you don't follow proper hygiene.
If you keep changing video cards, installing
different brands of drivers, without removing the
old ones, it can catch up with you.

*******

A BSOD from a video card, sure, it could be
a corrupted file. But just as easily, a
defect in a card, like bad video RAM, could
also cause problems. Or, it could even
be some other driver that has upset things.
Drivers run in Ring0, and drivers must
be designed by experts, as they can easily
"shoot one another in the foot". Programs
in Ring3, if they foul up, the important
system things are in Ring0 and are protected.
But a rogue driver, because it lives in
Ring0, can cause as much havoc as it wants.
Think back to anything you installed, just
before these problems appeared.

Paul

Thanks a lot, Paul, really appreciate that thorough reply. Quite a lot
to think about and try.

I did somehow manage to replace the original nv4_disp.dll with that
'this will fix it' smaller one. (I used a tool called Unlocker, which
offered to do delete it on the next reboot. I then immediately ran my
3 hour export from my video editor - and at last it completed without
the BSOD. ;-)

But I'm baffled, because even though I had not re-booted after that,
the original file was back in \System32!

So we'll have to see what happens the next time. Exports of that
length are very infrequent, so it will be a while before I know. I may
well do as you suggest and re-install 306.23 over the top. Is it
really necessary to uninstall first? I seem to recall reading (years
ago) that the installation program was clever enough to do all that
itself.

Meanwhile I've located my folder of nV drivers, including 306.23, and
added a bunch of more recent versions. Here's my full set: