NVLDDMKM Reset TDR freeze during 3Dmark Port Royal

[fastfishy2]

EDIT: RTX 4070 Asus Dual, latest drivers.

 

After much work updating, clearing, and reinstalling various drivers (and fixing my RAM overclock) yesterday, I thought I'd eliminated this issue, but apparently not. Original thread: 

 

While running another 3Dmark Port Royal stress test today w/ HWINFO64 running in the back, I came back to my PC to find it had frozen about 60% of the way through, in the same manner as before. Keep in mind I've been able to run this stress test in the exact same scenario several times with no hiccups in between yesterday and today.

Checked Event Viewer and found 3 Error messages labelled "nvlddmkm" with event ID 0. They all reference "\Device\Video3" and "Restarting TDR occurred on GPUID:a00"

This is after I purged the video drivers with DDU, updated bios and cleared CMOS on the mobo, updated my chipset drivers for the motherboard, and did some OS repair stuff via command prompt administrator. So, I'm at a bit of a loss as to what more I can do. Is there some kind of solution on my end or is this something where I just take the graphics card back to the shop. I haven't had this happen during actual gaming and it seems to now exclusively happen during 3Dmark port royal stress test - Speed Way runs fine, and I can't even get it to happen on 100% of the Port Royal runs I do. It just seems to pick and choose at random which runs it will freeze.

[191x7]

Repair the "game files" of 3dmark.

 

Also, disable the Multiplane Overlay mpo.

[fastfishy2]

2 minutes ago, 191x7 said:

Repair the "game files" of 3dmark.

 

Also, disable the Multiplane Overlay mpo.

Alrighty, I've used the MPO registry edit file that Nvidia provides so that was quick and easy. I've also gone for removing 3Dmark completely and reinstalling it on another drive fresh. 

 

Question is, how likely is this to be a hardware issue? It never happens anywhere else and it's not even consistent in the one place it DOES happen... I only ask because I'm off work recovering from surgery for a week, so I have all the time in the world to mess around with software related issues. Getting to the shop to return a GPU on the other hand... somewhat more difficult.

 

Is 3Dmark known for these kinds of issues?

[191x7]

1 hour ago, fastfishy2 said:

Alrighty, I've used the MPO registry edit file that Nvidia provides so that was quick and easy. I've also gone for removing 3Dmark completely and reinstalling it on another drive fresh. 

 

Question is, how likely is this to be a hardware issue? It never happens anywhere else and it's not even consistent in the one place it DOES happen... I only ask because I'm off work recovering from surgery for a week, so I have all the time in the world to mess around with software related issues. Getting to the shop to return a GPU on the other hand... somewhat more difficult.

 

Is 3Dmark known for these kinds of issues?

3DMark is not known for such issues.

 

Check this thread, maybe we missed something

 

[fastfishy2]

5 minutes ago, 191x7 said:

3DMark is not known for such issues.

 

Check this thread, maybe we missed something

 

I think the only thing that remains to be checked is updating my card's Vbios. Everything else I know of on that list seems to have been updated. I also re-ran the test and had no hangup this time. Additionally I ran Furmark stress test @ 1440p with OCCT medium CPU stress test in the background and ran into no issues either. I am wondering whether a fresh windows reinstall, along with wiping all my drives in the process, might also be something to try.

[fastfishy2]

4 hours ago, 191x7 said:

3DMark is not known for such issues.

 

Check this thread, maybe we missed something

 

Ok. I've done a complete windows reinstall and put it on my NVME this time. Got everything downloaded and set back up again, fresh. I'm gonna run port royal a few times over the next day or so and see if I can reproduce the issue.

 

Do you think if it were a GPU hardware fault that it would be easier / more consistent to reproduce? I've gone so far as to run furmark and OCCT medium CPU stress test concurrently and nothing happened there either. I'll also have a Crack at memtest86 but it's odd that a RAM problem could occur in such a specific instance each time.

[191x7]

6 minutes ago, fastfishy2 said:

Ok. I've done a complete windows reinstall and put it on my NVME this time. Got everything downloaded and set back up again, fresh. I'm gonna run port royal a few times over the next day or so and see if I can reproduce the issue.

 

Do you think if it were a GPU hardware fault that it would be easier / more consistent to reproduce? I've gone so far as to run furmark and OCCT medium CPU stress test concurrently and nothing happened there either. I'll also have a Crack at memtest86 but it's odd that a RAM problem could occur in such a specific instance each time.

You've done well. Maybe a bit overkill, but fine, since unstable RAM affects everything (every read, write, action and transaction), the storage, programs, everything.

[fastfishy2]

12 hours ago, 191x7 said:

You've done well. Maybe a bit overkill, but fine, since unstable RAM affects everything (every read, write, action and transaction), the storage, programs, everything.

So far I've had no stress test hangup. One thing I have noticed is that my former (until yesterday) 860 EVO boot SSD was showing LBA errors in Samsung disk utility when doing a short SMART test. Neither my 970 Evo plus NVME (My current boot drive) or my 870 QVO SATA 2TB (My current bulk storage drive) had this problem. Could have been a contributor. In any case I'll keep re running various tests when I get time to see if the issue crops up again.

 

On the upside though, the system is definitely snappier running off an NVME. And the NVME is happy because it has one of those EK passive heatsinks on it.

 

EDIT: also as of this morning the 860 evo had nothing on it except an empty steam library folder, and as it's only 500gb and a few years old I just removed that storage space on disk manager and then powered down the system and physically removed it. I won't miss it. I did also check all my other drive firmware was up to date.

[fastfishy2]

22 hours ago, 191x7 said:

You've done well. Maybe a bit overkill, but fine, since unstable RAM affects everything (every read, write, action and transaction), the storage, programs, everything.

Ok, so the only other thing I've noticed since this morning is that I ran those OS check command prompts you told me to yesterday, the DISM and SFC ones. It found and repaired a couple of corrupt files. Otherwise things seem to be functioning more or less normal except for Steam deciding something was blocking its access to the VAC service, which I fixed by simply reinstalling steam. Is it a biggie if I find the odd corrupt file every now and then using that checking command?

[191x7]

37 minutes ago, fastfishy2 said:

Ok, so the only other thing I've noticed since this morning is that I ran those OS check command prompts you told me to yesterday, the DISM and SFC ones. It found and repaired a couple of corrupt files. Otherwise things seem to be functioning more or less normal except for Steam deciding something was blocking its access to the VAC service, which I fixed by simply reinstalling steam. Is it a biggie if I find the odd corrupt file every now and then using that checking command?

Yes, especially on a fresh system. Something causes file degradation on the system files, and that's not good.

Suche issues can arise if the system is doing something and you cut the power, get a BSOD, etc, it should not happen with normal/regular use.

The root cause should be found and solved. Maybe the XMP also isn't stable or the RAM was working too long on a manually set high overclock for the timings and voltage and some damage occurred.

I'd recommend running Memtest86+ or Passmark Memtest86, at least for a few hours, just to see if the RAM is fine.

What also affects the writes is the CPU. And the storage controller, chipset.

[fastfishy2]

24 minutes ago, 191x7 said:

Yes, especially on a fresh system. Something causes file degradation on the system files, and that's not good.

Suche issues can arise if the system is doing something and you cut the power, get a BSOD, etc, it should not happen with normal/regular use.

The root cause should be found and solved. Maybe the XMP also isn't stable or the RAM was working too long on a manually set high overclock for the timings and voltage and some damage occurred.

I'd recommend running Memtest86+ or Passmark Memtest86, at least for a few hours, just to see if the RAM is fine.

What also affects the writes is the CPU. And the storage controller, chipset.

Would TPU Memtest64 do the trick for a few hours? I read a guide saying I have to clear the CMOS and then run Memtest86 from a USB directly, and I'd rather not reset my CMOS again right now if 64 will work. 

 

Also, I can try to get the CBS log for you if that would help, I'm not so savvy on reading those.

[191x7]

2 minutes ago, fastfishy2 said:

Would TPU Memtest64 do the trick for a few hours? I read a guide saying I have to clear the CMOS and then run Memtest86 from a USB directly, and I'd rather not reset my CMOS again right now if 64 will work. 

 

Also, I can try to get the CBS log for you if that would help, I'm not so savvy on reading those.

No need to clear the CMOS, you need to check the settings you're using and not the base JEDEC spec.

[fastfishy2]

5 hours ago, 191x7 said:

No need to clear the CMOS, you need to check the settings you're using and not the base JEDEC spec.

Memtest86 did a full 4 pass test, took around 5 hours while I was sleeping. Passed with zero errors @ DOCP 3200MHZ CL16. I'll keep looking. Keeping in mind SFC did not find these errors until about 6 hours ago, my initial sweeps on the new install turned up nothing.

Did you want a CBS log if SFC pulls any more errors? I'm also going to run an extended SMART test on the new boot drive, as a precaution, although having both the 860evo and 970evo cause problems would be very very bad luck.

[191x7]

42 minutes ago, fastfishy2 said:

Memtest86 did a full 4 pass test, took around 5 hours while I was sleeping. Passed with zero errors @ DOCP 3200MHZ CL16. I'll keep looking. Keeping in mind SFC did not find these errors until about 6 hours ago, my initial sweeps on the new install turned up nothing.

Did you want a CBS log if SFC pulls any more errors? I'm also going to run an extended SMART test on the new boot drive, as a precaution, although having both the 860evo and 970evo cause problems would be very very bad luck.

I don't need the log.

Do the SSD-s run the latest firmwares?

What does Hard Disk Sentinel say about their health?

[fastfishy2]

7 minutes ago, 191x7 said:

I don't need the log.

Do the SSD-s run the latest firmwares?

What does Hard Disk Sentinel say about their health?

SSDs are on the latest Samsung firmware, I haven't run sentinel yet as I have another 3dmark run going. Will get on that, and probably do a chkdisk too. 

I forgot to mention that I did a windows update just prior to SFC finding those errors. Windows 10 if I haven't already mentioned. The only other time I got SFC hits on corrupt files was on my previous install after several months of use and updates (and a faulty boot ssd). The 970 Evo plus nvme also had a clean bill of health from extended SMART.