BSODs on RS5/1809

[undon3]

Hello everyone.

I could use a bit of help with some BSODs I am experiencing in the new October update. It's a clean install, deletion of previous partitions. Very little stuff on it, minimalistic, mostly default settings, no crazy OS tweaks etc. I will have to link the dumps separately as I deleted them from the C: partition after I uploaded to Onedrive. I'll still attach the tool results as I assume it will save me listing specs and everything. The PC is tested mercilessly for stability under prime95/LinX/memtestx86/Win10 memtest. It passes 24 hrs of prime95 with AVX, Blend, SmallFFTs, In Place large FFTs, each. The PSU is a 6 months old Leadex II 650W Gold from Superflower, basically the same as EVGA Supernova G3. Besides the BSODs, the game I play these days (Destiny II) also crashes to desktop. I have 2 of its dumps as well. The BSODs happened while I was playing. RS4/1803 was stable. Everything is stock, no OCs, well XMP if you want to consider it, but at 3000MHz it's not a huge XMP, plus it's tested with Blend for 24 hrs. Running Verifier now for the non-Microsoft drivers on the PC will see what happens if I try to play Destiny II.

· OS - Windows 10 RS5
· x64 ?
· Clean install.
· retail
· almost 1 yr age
· 2-3 weeks RS5 install.

· CPU 8700K
· Video Card Gigabyte 1070ti
· MotherBoard - MSI Gaming Plus Z370
· Power Supply - Superflower Leadex II 650W
· Desktop

Here comes the link:

Onedrive folder containing the 2 BSOD dumps and the Destiny 2 dumps, archived

View attachment SysnativeFileCollectionApp.zip

Appreciate any help. I don't really feel like returning to 1803, so I'd rather fix this if possible. Please reply if you require any additional info.

Many thanks!

 

[cwsink]

Hi undon3,

The event log shows a 0x124 bugcheck happened on 14 Oct. Those often show up in unstable overclocks. Have you been attempting to overclock the system? If so, I'd suggest removing any overclocks including the memory which looks like it's set for DDR4-3000. The highest setting officially supported by Intel for your CPU is DDR4-2666 so please change the memory to that setting or lower; at least while troubleshooting.

Has the system crashed while doing other things or only while running Destiny?

 

[undon3]

Hi undon3,

The event log shows a 0x124 bugcheck happened on 14 Oct. Those often show up in unstable overclocks. Have you been attempting to overclock the system? If so, I'd suggest removing any overclocks including the memory which looks like it's set for DDR4-3000. The highest setting officially supported by Intel for your CPU is DDR4-2666 so please change the memory to that setting or lower; at least while troubleshooting.

Has the system crashed while doing other things or only while running Destiny?

The bugcheck from 14 Oct is irrelevant, I was refining an OC and the voltage was too low. Hence I didn't include the dump or mention it, BSODs when you OC are expected. The 2 BSOD dumps I linked are for stock operation, those are important.
Happening only during Destiny 2 gameplay. Temps are fully in check (69C max for GPU, CPU 60C). There are no OCs on the RAM, that's an XMP, and it's tested with prime95 Blend for 24hrs, and with memtestx86 and Windows memory testing. I mean, if we ignore XMP, why even buy faster RAM? Mine would be just 2400MHz without XMP.

Also in RS4 there were no crashes/BSODs with XMP, and Destiny 2 was... almost stable. There were still very rare (maybe once 1-2 weeks) CTDs but never BSODs. I've ran it with an hour with Verifier on for the non-Microsoft drivers and nothing happened. I'll try some more later.

I hope there's info in the 2 dumps that I linked that's useful. Also since you checked the event viewer log, I'm sure you noticed the backgroundtaskhost/cortana.signals.dll crashing on almost each reboot. Yet again, not a thing at all in RS4. Have no idea why that's happening either, but it's tanking my Reliability History really bad and it's annoying as hell.

 

[undon3]

Nothing in the dumps I linked that provides any shred of info on the issue? I assure you they were at stock operation, yes, with XMP, as the memory vendor advertises it, and I didn't just enable XMP, I know it can cause issues at times, this is why I tested for memory errors with:
- the Win 10 memory test
- memtestx86 ran from boot for 8 hours or so while I was asleep
- Blend prime 95 with AVX to stress the IMC for 24 hrs
- these tests on top of SmallFFTs and AIDA64 and LinX, each 24hrs
What more can somebody do to test stability?

Anyway, if the BSODs would be easy to reproduce and regular, sure, I'd definitely try XMP off. The problem is I got 2 BSODs in 14 days of usage. It's not regular. Even if I turn XMP off, there might be a new CU, a new Nvidia driver, a new Destiny 2 update, you'll never know for sure if XMP off truly helped without easily reproducible BSODs.

I'm posting this not because I'm in a hurry, but because I'm getting the feeling that it is assumed the BSODs happened while OCing, which I have to stress yet again it's not the case. The BSOD that's mentioned in the response post is simply a benign "voltage too low" typical BSOD.

So is there anything in those dumps that's of use? Should I provide more info? Since making the OP there were no BSODs, but Destiny 2 crashed again with same typical EXCEPTION_ACCESS_VIOLATION error (it generates logs in TEMP and sends them to Bungie, the devs, at least sometimes, other times it crashes to a dmp, which I linked).

Thanks.

PS: running Destiny 2 under Verifier for non-Microsoft driver didn't produce anything outside bad framerates and performance which is to be expected. After 2-3 hours I gave up as it was somewhat unplayable and I expect a crash would have happened already. Left Verifier on for a day. Nothing. Then today I had another Destiny crash that I mentioned earlier, which is an improvement after the 3-4 crashes of 2-3 days ago. Tried to run the game as admin as I hoped that it lacks some privileges to access some data, but it still crashed.

 

[cwsink]

I can give you some notes I've made regarding the dumps. I don't see anything definitive, honestly. It just looks like general memory corruption which can be caused by buggy drivers or hardware issues. I don't see many 3rd party drivers loading nor do I recognize them as drivers I've seen cause problems on other systems.

** Notes **
[FONT=Verdana,Arial,Tahoma,Calibri,Geneva,sans-serif]The 0x3b bugcheck dump shows a thread owned by procexp64.exe (Process Explorer) threw an exception when it tried to read an invalid memory location. The function being called which threw the exception was dxgmms2!VidSchQueryProcessNodeStatistics. In fact, if I use .trap to set the context to the time when the exception actually happened, all of the cores look like they are executing the same function. I suspect Process Explorer was sampling all of the cores for information but something went wrong on core 1.

[/FONT]
[FONT=Verdana,Arial,Tahoma,Calibri,Geneva,sans-serif]The 0x18 bugcheck dump shows a thread owned by destiny2.exe tried to dereference an object while in the kernel which caused the system to detect an invalid value for the object being referenced in the context of what the function was trying to do; dereference the object. In this case it was an Event object and it looks like the reference count was already 0 prior to the attempted dereference.

[/FONT]
[FONT=Verdana,Arial,Tahoma,Calibri,Geneva,sans-serif]It's not obvious to me how they would be related. Kernel memory corruption is the only thing that comes to mind. Either a driver bug or hardware problem. I'd want to eliminate the possibility of a hardare problem by making sure the hardware isn't being pushed beyond its officially supported settings.

[/FONT]
[FONT=Verdana,Arial,Tahoma,Calibri,Geneva,sans-serif]The 2 process dumps for destiny2.exe suggest an object reference is invalid but the developer's code didn't check for that possibility. So, either lazy programming or whatever went wrong didn't seem like it could possibly go wrong to the developer.

*********​

If you have any other dumps we can look at it might help. It often takes several to spot a pattern. I'd very much recommend removing the XMP as I've seen the tests you've used miss problems. In my mind it would be best to be sure the system is stable with officially supported settings for all parts.[/FONT]

 

[undon3]

Got it. I almost understand everything you said. Which is great. I don't have anything to offer right now as there was just a Destiny 2 crash yday and instead of producing a dump, it produce a log in TMP and sent it to Bungie. I also sent logs and dumps to Nvidia and Bungie. Instability really irks me, hence the extended stability testing.

If I get another BSOD, I'll post it here, and then I have two plans:

- ditch XMP (but I really need to find a way to enable it safely and stress test its implementation if it turns out to be the culprit, I don't want to run 2400Mhz speeds on advertised 3000MHz memory.)
- ditch the last Nvidia driver (which is supporting RS5 and the new WDDM 2.5 in the OS) and install older one after DDU removal in safe mode

The graphic card is also stable, although testing possibilities are limited. Furmark and other power viruses aren't really reliable, so there's just looping Time Spy or other GFX benches for hours, which it can do with ease and no crashes.

PS: I am no longer running procexp for days (sadly). I saw it mention when I took a look at the dumps with WinDBG and now starting TaskManager instead, which is annoying because procexp offers a lot more info on what's going on in the PC. Also not been updated for ages.

 

[cwsink]

The destiny2.exe process dumps are virtually identical which suggests the problem it is encountering is consistent. A prefix for a string that gets sent for error reports is [FONT=Verdana,Arial,Tahoma,Calibri,Geneva,sans-serif]APPLICATION_FAULT_NULL_CLASS_PTR_WRITE_INVALID_POINTER_WRITE_ which suggests to me a pointer to a C++ class object is invalid but the program tried to write to it, regardless. So whatever class it is it's not expected to fail when creating an object, apparently.

[/FONT]Hopefully Bungie can say something like "our code was expecting a reference to such and such object but the reference is invalid" and determine (for example) a DirectX call was expected to create this object but for some reason it didn't. WinDbg did try to load symbols for a file named [FONT=Verdana,Arial,Tahoma,Calibri,Geneva,sans-serif]nvwgf2umx.dll but that could just be a coincidence.[/FONT]

 

[undon3]

The destiny2.exe process dumps are virtually identical which suggests the problem it is encountering is consistent. A prefix for a string that gets sent for error reports is APPLICATION_FAULT_NULL_CLASS_PTR_WRITE_INVALID_POINTER_WRITE_ which suggests to me a pointer to a C++ class object is invalid but the program tried to write to it, regardless. So whatever class it is it's not expected to fail when creating an object, apparently.

Hopefully Bungie can say something like "our code was expecting a reference to such and such object but the reference is invalid" and determine (for example) a DirectX call was expected to create this object but for some reason it didn't. WinDbg did try to load symbols for a file named nvwgf2umx.dll but that could just be a coincidence.

Thanks again!

The game tries to "skip" the usual dmp creation, it has its own folder in TEMP where it creates some sort of post mortem report, with screenshots of where it happened and other info, like specs and type of activity, IPs etc., zips it and sends it to Bungie. The dumps I was able to link are more of an unusual occurrence, I believe they are made when the game fails to generate its own report, maybe crashing too fast/too severe for the post mortem scripts to do their job. Last CTD didn't generate a dump, Event Viewer entry or anything in Reliability History for example.

This means Bungie should receive countless such reports, and in their forums/reddit crashes are quite often encountered, many with the same "RUNTIME ERROR: EXCEPTION_ACCESS_VIOLATION at 00007FFBF4219CA8" type of crash. I assume a lot of them are just unstable PCs, as I know from my decades of PC journey that most PCs are pretty messy and instability is not something rare. I hope it gives Bungie some insight into issues, but I am not really optimistic about fixes, after all we live in an era where developing new cosmetic content for micro-transactions can be far more important than game not crashing on specific configurations.

I will zip and attach a Destiny 2 crash folder if you're curious. It's the one that happened yesterday (only one, miraculously).

 

[cwsink]

I use ProcDump to capture process dumps on my own system. They can get quite large, though, depending on the settings. The command line I use to set it up is:

procdump -i -ma

which I run from an elevated command prompt in the folder in which I want the dumps to appear. It basically sets itself up as the default debugger, grabs a dump, and then passes then continues the normal Windows Error Reporting sequence. You'd need to put the procdump executable into the target folder as well to run the command as I wrote it above.

It might be worth a try but I'll have a look at the dumps you provided above. They might be basically the same thing.

edit: Not the same thing at all, apparently. I think it's data for Bungie's own tools. ProcDump might allow you to get process dumps more reliably. Don't be surprised at how many processes are crashing without having informed you about it previously, though.

 

[undon3]

Does it inject any code or such? Bungie bans very easily, they banned people for using monitoring overlays like Riva Tuner Statistics Server. There's also no appeal, just ban. Kinda fearful of losing 1yr worth of investment, time and money. I assume that captures the memory at the time a crash occurs. Bungie might think I'm trying to reverse engineer or something, they're really atrocious at it.

 

[cwsink]

My understanding is that it changes a registry setting about what "debugger" to launch when a process crashes. For example, if Visual Studio is installed it changes the same registry setting to make itself the default debugger so that if a process crashes it gets first dibs at debugging the program. The normal processing of a process crash continues so that Windows Error Reporting will also send data to Microsoft about the crash.

With the command I specified it will give ProcDump first dibs, create a process dump in the specified folder, and then allow Windows Error Reporting to do its thing. There should be no code injection but if Bungie uses the same registry setting for its process dumps I could see it being prevented from doing so because it would be overwritten. I doubt they use that registry setting, though.

The registry keys are:

[FONT=Verdana]Reset to:
  HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug
    (REG_SZ) Auto     = <deleted>
    (REG_SZ) Debugger = <deleted>[/FONT]
[FONT=Verdana]ProcDump's backup key is missing. Defaulting to value deletion.
  HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug\ProcDump\[/FONT]
[FONT=Verdana]Reset to:
  HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug
    (REG_SZ) Auto     = <deleted>
    (REG_SZ) Debugger = <deleted>[/FONT]

and by default, the Auto and Debugger REG_SZ keys don't exist.

After running the command my keys look like this:

[FONT=Verdana]Set to:
  HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug
    (REG_SZ) Auto     = 1
    (REG_SZ) Debugger = "C:\Program Files (x86)\Sysinternals\procdump.exe" -accepteula -ma -j "D:\Dumps" %ld %ld %p[/FONT]
[FONT=Verdana]Set to:
  HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug
    (REG_SZ) Auto     = 1
    (REG_SZ) Debugger = "C:\Program Files (x86)\Sysinternals\procdump.exe" -accepteula -ma -j "D:\Dumps" %ld %ld %p[/FONT]
[FONT=Verdana]ProcDump is now set as the Just-in-time (AeDebug) debugger.[/FONT]

I keep the Sysinternals tools in my path which is why it's launching from C:\Program Files (x86)\Sysinternals but yours would be D:\dumps or whatever directory you create to store the dumps and run ProcDump from following my instructions above.

 

[undon3]

I think it would be polite to report back now that I am 99% sure I solved instability (10 days without BSODs, but more importantly, no Destiny 2 crashes at all).

It was the motherboard and how it implemented XMP. After playing with voltages (VCCSA, VCCIO, and even VDIMM) I found a combo that's "stable" (for now). My main mistake was believing what some dude told me in the past in other forums about VDIMM, tht appears as 1.36V in HWinfo64, and it should be 1.35V as specified by the XMP. I was told that's a cosmetic "mistake". However, manually entering 1.35V would decrease the voltage to 1.344V, so it's not insignificant.

In the past I also had to decrease both VCCSA and VCCIO as they were crazily overvolted by the motherboard - 1.32v and 1.25V. That's well above Intel's specs, but then again, folks in other forums told me it's necessary so the XMP is stable. Well in my case, it had the opposite effect. Anything above 1.26V on SA and 1.15V on IO would make Blend/prime95 fail, reliably and somewhat fast. I found Blend to be the only reliable way to test, all other memory tests would be useless as they always come up good. Sadly it also means you need to leave the PC Blending for very long amount of time, 24hrs+, as I had it failing as late as 13hrs in, but that would typically indicate I'm on the good path with voltages, as it can also fail in 10-15 mins if the voltages were default/too high.

The combo that works now is: SA 1.25V, IO 1.12V, VDIMM 1.35V (translating to that 1.344V in HWinfo64)

IMO XMP 2.0 is a pretty big scam and should be reworked to actually be reliable. I wonder how many other instability instances are caused by XMP, which is advertised as "just working" with a push of a button, and RAM manufacturers are allowed to sell RAM at whatever they rate it as if that's the actual speed. It's like Intel/AMD would present sell their CPUs with the speed being that of turbo boost or XFR, not the base clocks, Or Nvidia selling RTX that is specced 2000MHz, turbo instead of base.

Can't understand why this is allowed when it's pretty clear XMP is just a rough OC with pretty bad settings and it's also very hard to troubleshoot. I don't imagine the average user ever getting through 24hrs of Blend and manually playing with BIOS voltages and/or timings.

But more importantly, I hope this might help others that come with similar issues and point them in the right direction of how to solve them.

Many thanks for all the assistance and help! Appreciate it.

 

[cwsink]

Thank you for the update and letting us the details of how you fixed the problem. :thumbsup2: