Squall Leonhart

the spectre patch is not responsible for the util issue here, the effect of the patch halves performance of fpu vp8.

Try disabling screen power management.

It's not really Fiery's fault, but there some new information Re the cause It was a bit premature to mark this thread fixed just because an issue with 1803 was found and worked around, some of us are not even on Win10.

They aren't gone, they weren't readily reproducible in the first place. https://forums.geforce.com/default/topic/1061921/geforce-drivers/announcing-geforce-hotfix-driver-398-46/post/5833546/#5833546

Testing 4652 under 17134, none of the clocks under Overclock update, everything under CPU Speed is now a static number I'm creating a feedback so Microsoft can follow up and implement a safe mutex for accessing the timer, Microsoft shouldn't be adding unsafe 'features' that cripple existing utilities. https://aka.ms/AA1ovm3

As much as nvidia cannot reproduce it, im still convinced it is a driver bug, i've seen it reported with users running evga precision, kombustor, aida64, gpu-shark a combination of aida64 and gpu shark running at the same time brought it on in 4 days, aida64 alone a week. Considering this rides on the tail of nvidia fixing the GDI leak, its suspicious. Testing 4652 under 17134, none of the clocks under Overclock update, everything under CPU Speed is now a static number

Don't mix up the issues Fiery, this bsod is occuring on 7 and 10 16299+17134

Start command prompt in admin mode Execute the following command: verifier /standard /driver nvlddmkm.sys If you haven't already enabled for kernel dump, Could you please follow the steps here: http://mywindowshub.com/how-to-configure-windows-10-to-create-dump-files-on-bsod/ and enable "Kernel memory dump" under System failure region Reboot the system Get a repro Zip dump and upload it on google drive, mail a share link to driverfeedback@nvidia.com

never e ver keep corsair garbage link open, it is not a safe or stable program.

Totally different problem.

nvidia are still claiming no repro, so i think they are missing a particular configuration requirement to bring it out. They might need one of our cfg files and sensor panels or whatever

Yep, the point was interaction with the driver is necessary.

This issue is occurring in the nvidia kernel driver, your isn't hasn't been fixed its just gone into a really random occurance cycle. A process cannot cause a bsod, a driver would have been flagged that was loaded by the process but it might be wrong too (as different utilities can be more or even less correct about analysing dump files with the symbols available. 397.55 or earlier are not affected by this, so if you're on 397.64 or .93, theres your culprit.

https://forums.evga.com/FindPost/2823774

Gigabyte are using a nasty mutex access, as usual :\

oh, there is previous feedback

Driver feedback to https://surveys.nvidia.com/index.jsp?pi=6e7ea6bb4a02641fa8f07694a40f8ac6 dump file to driverfeedback@nvidia.com

you are mixing system management utilities.

dump file must go to nvidia and feedback provided with system details, this is an nvidia driver bug. PS: it comes up as being in ntkrnlmp.exe here, all changes based on the application scanning the dump.

Turn hpet on, This is a platform bug where timers slowdown after resuming from sleep.

This topic involved a crash in the application that occured when it was left on that page of aida64, this has been fixed for a long long time now. PS: Don't turn off the page file, windows can't do some things with one turned off, such as allocate large virtual blocks (whether it intends to fill them or not). Set a Min/Max pagefile instead.

Drive type and model would be agood idea too ;), as well as the ahci driver in use.

Fiery is a busy man.

I believe the nvidia kernel mode driver is suffering a double free or use after free which is brought on via applications using nvapi, thats why the faulting process is one which accesses the card using this api. windows will often say ntoskernl or ntkrnlmp because of an imprecise timing issue in the exception handler, in my case its pointing at X64_0x1E_nt!KiDispatchException+1c7 which is definitely not the actual fault lol.

I don't, not without recompiling the claymore binary.