NVIDIA GeForce 496.13 WHQL driver download & Discussion

That sounds good. I think I'll give these drivers a try, too. Currently I'm still using Geforce 460.89 so it's about time to update.

 

They obviously do in this case. Memtest86 run with zero errors, and no prior BSOD's in over a year of running this configuration. The day I update to the latest drivers I start to BSOD. Clean install of windows - BSOD. Roll back the drivers, no BSOD. Display drivers came up as the listed cause in the logs in almost every crash.

 

No.

Memtest can't prove the absence of issues.

 

Call of duty cold war crash with these drivers , confirmed here :
GeForce 496.13 GRD Feedback Thread ( | NVIDIA GeForce Forums
many users report the problem
goind back to 472.12 and no problem at all

 

many people think 5g = covid too,

issue is the game.

 

But I don't think 5g = Covid

I any case , the game the game doesn't crash with 472.12 for me , only with 496.13

 

I just realized that NV devs should have added a button to clean the shader cache manually from NVCP (without searching for it across whole disk).

 

what happens if you set it to disabled option, my guess it would delete them or it should IMO.

Edit: ok, I was wrong, setting to disabled does not remove them, unless I need to run each game again.

 

You could probably write a program that removes all possible shader caches, to think about it, maybe a good idea to have just that included in DDU.
Not sure if it is possible, but could be pretty annoying if a game on Steam has it's own compiled shaders + Steams + Nvidia's + DirectX.

 

What are you even talking about? Of course display drivers can cause memory management bugchecks. You know why? Because they allocate and free memory all the time. In kernel mode. Using the kernel allocator. It just needs to pass a bad pointer while trying to free memory, say because of a clearly impossible ~*~**DrIvEr BuG~*~*~, and presto.

When memtest86 can make the system survive several passes of the intentionally problematic patterns that cause things like e.g. rowhammer, it's safe to say that sudden frequent memory related BSODs, that also happen to go away rolling back a driver, are definitely not a hardware issue with RAM.

Stop giving bad advice.

 

it has auto clean behavior, most issues are stemming from games own compilation of shaders that are written to appdata or my docs locations.

 

No they can't, these allocations are virtual and only the kernel has metal access.

the nvidia umd is where 99% of the optimisations and fixes are made and cannot trigger a 1a.

also people with good stable systems aren't getting them, only people with ignorantly claimed "mem test proves its ok" systems are getting issues.

The only bad advice is inferring that memtest can prove a system is without issues.

https://en.wikipedia.org/wiki/Evidence_of_absence

educate yourself on the modern memory controller as well as dimm cell defect locations, memtest is false confidence.

Majority of actual memory stability conditions occur with multithreaded data access on data persisting over several row refresh cycles, electron leakage between refreshes as well as bitflips are 2 of the prime reasons DDR5 has on chip ecc

Memtest is not capable of testing multichannel ddr4 systems to a degree of confidence required for "memtest had no issues" to have any meaning to me.


Test 7 should be used with atleast 32 passes for me to focus on anything else.
https://superuser.com/posts/1413045/revisions


1a bsods as a driver bug would affect everyone with no discrimination

 

You clearly have absolutely no idea about operating system memory management.

And nevermind that there's a kernel driver, that's surely not static, nor impervious to bugs. UMD driver passes down bad data to the kernel driver, which may or may not handle it well, due to unsatisfying data sanitization, and kablammo, system is gone.

What does multithreading have to do with it? Do you realize that it all goes through the same single memory controller?

What do you even think memtest86 does? So according to you, a stupid game relatively reliably crashing the system is a clear diagnostic indicator of faulty memory, but a tool specifically designed to create an extensive workload with known problematic patterns, some backed by security research, is useless? What moon logic is that?

Also, the primary purpose of on-chip ECC is to allow looser manufacturing tolerances. It doesn't cover corruption over the memory bus. If you want ECC, you'll still need sticks with a parity chip.

 

I don't know what else to tell you other than I updated my drivers and changed nothing else - and I had constant BSOD's with NVIDIA as the culprit in the logs. I rolled the drivers back and I haven't had a single BSOD in 2 days.

I thought I'd post in case anyone else with a 2080s experiencing the same issues happened to find this. Seems like you're kind of blindly defending NVIDIA for no real reason?

 

I deal with this stuff irl every day and have done for almost 17 years (not including the years i built and tuned pc's as a hobby., I know what is and isn't the driver and I know what to be testing based on the system exception and parameter of that exception.

You provoked an existing instability with the driver update or introduced cross-driver incompatibility with other third party driver tools, the old driver doesn't provoke the existing issue because of processing pattern differences.

• the faulting module will often return differently depending if you use bluescreen view or windbg, the actual source is usually neither, parameter depending.
  
• 1a bsods are memory corruption (bitflip or cache parity) write after free, PTE descriptor, etc, not use after free or double free bsods which are resolved to 0000001E (Kmode exception not handled)
• page fault in non paged location, pfn list corrupt, etc all have their own exception names
• pte descriptor bsods are system agnostic, write after free are potentially software combo antagonized

The kernel dumps i've walked through are not stack consistent, there is no coherency between systems experiencing it and all the dumps are returning parameter 0x403 and 0x31

The new driver is agressively milking performance out of systems and systems with any sort of weakness are being caught out, progress be like that sometimes.

https://www.reddit.com/r/overclocki...ver_had_an_overclock_that_was_stable/gfy2a1n/

https://www.reddit.com/r/overclocki...clocking_instability_after_gpu_driver_update/

 

Kmode exception not handled can be caused by drivers. I was receiving this error during BSOD's with the new drivers. I am not now.

I have put this hardware through every diagnostic test available, with multiple passes and they've all been error free. It seems short sighted to defacto blame hardware, particularly when a system has been running without a single error/bsod/freeze etc for 12 months.

I have literally zero interest in arguing with you - if anyone else comes here with this issue, roll back your drivers. It'll resolve the problem.

 

Then its this

send a google drive link for kernel or mini dumps to driverfeedback@nvidia.com after filling out their feedback form.

forum reports of bsods are useless without them.

 

This driver causes random flickering(fast TDRs) in 2D, random Dots( Red, Black ) ( also under 2D ) in UWP Apps
And sometimes opened Windows are a Pixel mess
While gaming everything is fine but Desktop

I guess the random Driver Resets is causing this graphical mess on the Desktop
Rolling back to 472.12 and the bug is gone

 

sounds similar but different to what @venturi obseved.