Apex Legends Crash no error - PC (apex_crash.txt)

The one I posted is the crashed after I get killed, and I have to kill the program myself.

The one that I killed someone and I have to terminate the program doesn't gives out any crash log. 

I fixed the problem with whea internal parity error.  This is a possible fix for all of you, but this works for me.

Specs: 9900k clocked at 5ghz 0 avx 1.3 volt LLC 8 Fully stable and i don't have to downclock my cpu. Nor does it crash in any shape or form anymore. All the tutorials with lowering settings, downclocking is not a smart idea unless they have tried to increase the LLC and first of all made sure the vcore is stable. if you have  a stable 4,9 ghz stable oc at 1.285 volt, make sure the llc is increased or lowered to match your desired voltage, if you get like 1.285 and above for example 1.290 or little more it doesn't hurt. But when you drop in voltage during a game, that is where you would strangle the instructions to compile i believe from 1.284 and below. I don't pretend to know how the cpu utilize and work in a game, this is my theory.

Before i got many whea internal parity error in the event viewer while using Load line calibration in the bios set to 7-6 (ASUS LVL 1-8) and below. The voltage dropped  with llc 6 and 7 from 1.3v in bios, and during game in windows i got 1.288 which caused the errors.  But with LLC 8 i set it to 1.3v, in windows i have 1.305 volt idle and during game, which is fine.

I suspect that Apex legends shows the potential errors that  no other stress test can most likely reveal in all cases.

I want to highlight this in my case and some people crashes during stock settings, it is because the motherboard and cpus act differently, some are badly optimized at default and 

What do you think, and hopefully you can understand my informal text.

@Ariuc 

This is absolutely **NOT** a good idea!

This works in Apex Legends because Apex Legends does not put a high amp load on the VRM's, which limits guardband penalty and transient response is not affected as much.  LLC8 (aka Ultra Extreme loadline calibration on Gigabyte boards and Mode 1 LLC on MSI and Asrock) use a 0 mOhm loadline, which in theory prevents load voltage from dropping below idle.  (the way vdroop works is this formula:  I * R = vdroop, where I=current in amps and R=resistance (mOhms).  So for example 150 amps * 0= 0mv vdroop.  (It's actually 0.01 mOhms) but there is a very serious problem.

VRM's do not respond to 0 mOhms loadline gracefully, because MOSFETS cannot charge and discharge their capacitors fast enough to change power (wattage) loads the CPU is requiring as the CPU responds MUCH MUCH faster than VRM's (we already know how fast CPU's can respond, while VRM's usually operate at 500 khz switching frequency).  And its not just the voltage the VRMs must adjust down from +12v, there's the *current* (which leads to watts, as watts=volts * amps) also that has to be released by the mosfets too!  These are designed to operate with a loadline (vdroop), so that when the CPU goes from an idle state to a load state, or a load state to an idle state, the VRMs and caps are given time to charge and discharge, to adjust the current to what the CPU is needing.  

When you have a 0 mOhm loadline, there is *no* time at all for the VRM's to respond to a change in CPU load (to adjust the current it's supplying to the CPU, which the CPU burns up as watts).  This causes problems.  For example:  If a CPU is operating at a heavy load, let's say 150 amps, shall we?  E.g. running Prime95 with AVX small FFT (29.8 build 3), and running at 5 ghz, 1.30v, with Level 8 LLC, Ultra Extreme, whatever.  Then that load stops (change in iteration, super fast calculation load change, etc or even stopping the test).  The CPU responds instantly.  The load is stopped.  But the VRM's?  The VRM's can respond nowhere NEAR that close.  So that means, for around something like 45 *Microseconds* or so, the VRM's are still supplying 150 amps of current to the CPU!  But the CPU is not using those amps anymore.  Power cannot be created nor destroyed  It cant be released as heat since heat is a byproduct of watts.  So what happens?   The voltage spikes up *hard*.  It's so fast that a digital multimeter can't pick it up.  You need an oscilloscope to see it.  But these spikes, at heavier loads, can exceed *200mv* on cheaper motherboards that have bad transient response!  So that 1.3v becomes 1.5v.  This is worst case scenario (full load to no load), so load balancing from normal heavy sustained loads (though no load is 100% balanced) will have smaller, but repeated oscillations, probably reaching 1.4v often.  These can and will very slowly degrade your processor.

The opposite also happens, when going from no load to heavy load or a lighter load to a heavier load.  CPU requires amps, VRM's can't supply the amps fast enough as there is no vdroop cushion to give them time to do so, so the CPU voltage drops as much as 200mv (worst case!).  So that 1.3v can become 1.1v for a few microseconds.  What happens when this occurs?  BSOD or crash.

Again that is worst case scenario.  Apex Legends won't do this as it doesn't put a 150 amp load on you.  However OTHER programs, like Realbench or Prime95 or Cinebench R20 can.

So you would not only find yourself possibly crashing/BSOD'ing when trying to run Realbench 2.56 or Cinebench R20 (and especially prime95 !!) at a bios voltage set to your normal minimum load voltage you need to be stable, but using Loadline Calibration level 8, but you would slowly degrade your chips from the spikes also.

Here is what worst case 0 mOhms loadline looks like on a scope:

Elmor did some tests with comparing the VMIN (minimum voltage required for stability) with LLC6 and LLC8, using a multimeter, to find the voltage that LLC6 was stable at under worst case scenario (FMA3 small FFT prime95) at LLC6 with vdroop, then setting the bios to that exact voltage and using LLC8 to match it at idle and load.  The transients ruined his stability with LLC8.

----------

I fired up the my Maximus XI Gene + 9900K to see if I could replicate your behavior.

Core = 4.7G
Cache = 4.4G

P95 29.1 FMA3 Small FFTs 15K

LLC=6, Vcore set = 1.130V, Vcore read = 1.066V: 1 thread failed after 6 minutes
LLC=6, Vcore set = 1.140V, Vcore read = 1.074V: pass 20m+

LLC=8, Vcore set = 1.075V, Vcore read = 1.074V: 1 thread failed after 2 minutes
LLC=8, Vcore set = 1.085V, Vcore read = 1.083V: 1 thread failed after 4 minutes
LLC=8, Vcore set = 1.095V, Vcore read = 1.092V: 1 thread failed after 2 minutes
LLC=8, Vcore set = 1.105V, Vcore read = 1.101V: 1 thread failed after 9 minutes
LLC=8, Vcore set = 1.115V, Vcore read = 1.110V: 1 thread failed after 6 minutes
LLC=8, Vcore set = 1.125V, Vcore read = 1.119V: 1 thread failed after 2 minutes
LLC=8, Vcore set = 1.135V, Vcore read = 1.137V: pass 1h+

I repeated it again with LLC=6, Vcore set = 1.140V, Vcore read = 1.074V and 1 thread failed after 14 minutes. Probably 10-20mV extra would pass for 1h+.

--------------------------

Basically, with LLC8, the transient dips ruined any benefit of using LLC8 with a lower bios voltage, compared to LLC6 with a higher bios voltage!  So your load voltage (1.137v) was thus MUCH MUCH higher and thus much hotter (1.135v set, 1.137v read) than setting LLC6 wit 1.145v set and 1.080v read.  But again this is 150 amps worst case load here.

Ok the point?
While your LLC8 is working in Apex Legends, you are putting your hardware at risk, long term.  I would MUCH rather and would suggest that instead of using 1.30v LLC8, that you use 1.325v-1.35v LLC6.  It's much safer for your CPU, and you will have lower temps than LLC8+1.30v and lower VRM temps also.

So far I fix it by repairing the game. The end. 

Hi, i was trying to reply to @Falkentyne  but ended up replying to the thread. I am not used to these forums. I have provided some information in hw64 pictures of how my pc acts during load, this was done in cinebench r20, and would like to know if the numbers are abnormal. This is what i get when i stress test for hours, but in the picture it was within minutes so this is not a stress test. I get maxium 95 c for a small period of time and this goes for all LLCS and 95 c is okay for a short period of time and it recovers fastly to 89c and 90 c. One thing i was wrong in, i noticed that the voltage drop here aswell, to 1.288, thats odd for a LLC 8, but maybe it is a little less drop and the hw info number is within margin of errors. Focus mainly on the maximum numbers we can see there are no flags or thermal throttling or any hazard.

@Ariuc Looks like you've done your homework.

I just want to make sure that other users who are not using higher tier hardware like you are, and who are not well versed on what loadline calibration actually does, don't just rush into pushing the 0 mOhms Loadline calibration (LLC level 8, Ultra Extreme, etc) into their CPU's and think "wow this is the best thing ever, why don't they all come like this?"

Raja, one of the engineers at Asus (when their forums still allowed private messages) taught me what the AC and DC loadlines (not to be confused with Loadline calibration, or LLC (also known as VRM loadline or just "Vcore Loadline Calibrationi)) did on auto/offset voltages, and he also explained the dangers of removing too much vdroop.  Asus and other ODM's allowed such high levels of vdroop removal because "people kept begging them for it", so they gave the community what they wanted, even though they knew most end users had no idea how loadlines actually work (who here on this thread understood that Loadline Calibration is in mOhms (the same resistance value as the AC and DC loadlines?) and what the actual "levels" really meant?  See?

For Gigabyte Z390 boards using 8 core processors, here are the resistance values for each level of Loadline Calibration:

Standard / Auto / Normal: 1.6 mOhms

Low: 1.3 mOhms

Medium: 1.0 mOhms

High: 0.8 mOhms

Turbo: 0.4 mOhms

Extreme: 0.2 mOhms

Ultra Extreme: 0.01 mOhms.

Vdroop = Amps * Resistance.  Gigabyte boards have amps monitoring via the IR 35201 voltage controller (or the Intersil controllers) in HWINFO64 (Asus does not, sadly, even the eVGA Z390 dark doesn't seem to), so if you see your amps in IR 35201, multiply that by your LLC resistance, and then subtract that from your bios set voltage in millivolts.  Example:

1.30v=1300mv, turbo LLC=0.4 mOhms.  100 amps load: 0.4 * 100 = 40.  40mv drop.  1300-40=1260mv=1.260v.  Your VR VOUT should read 1.260v.  That's your load voltage with 100 amps.  Ignore the ITE 8688E sensor (Super I/O chip) and 8792E sensor (more accurate but won't show accurate vdroop).

It's also not Asus or Gigabyte's or other ODM's fault that transient spikes and drops happen.  Asus doesn't make the VRM's.  The companies like DrMos, Osemi(?), International Rectifier, Renesas (Intersil), etc, make them.  You have the voltage controller itself and then the actual power mosfets.  But these VRM's are not spec'd to run with a 0 mOhm loadline at all.  Even the official datasheets show the loadline information and none have a 0 mOhm loadline as part of the specifications.  So that's something worth noting.

I assume since you're a gamer, you probably have discord.  You can add me if you wish with the tag at the of my exact same username: #6092

One way you can test for transient spikes is to use the hardest stress test possible, in this case, Prime95 with FMA3 or AVX (I like testing 15K in place fixed AVX or 21K or 22K fixed, or even FMA3), and find the VMIN first, which takes a lot of work (basically, to save time, the absolute minimum voltage you can set in bios, *WITH* LLC5 or LLC6 vdroop), to not crash a prime thread at load in 15 minutes.

https://mersenneforum.org/showthread.php?t=24094

This version of prime95 allows you to enable or disable AVX and FMA3 right in the stress test without editing TXT files (recommend anyone who enjoys torturing their CPU's grab it), but yeah, for exammple, do a prime test with FMA3 enabled, 15K fixed in place FFT (custom, min and max range 15K), with let's say, 1.30v and LLC6 and start there.  If you INSTANTLY reach 100C and BSOD, disable AVX2 (FMA3) and just do AVX instead.  If you pass 15 minutes, reduce voltage 10mv, reboot and try again until it crashes.  Then record the **LOAD** VOLTAGE (not bios voltage!) that it took to pass.  Your motherboard has a good bios which reads CPU voltage properly at load, as does Gigabyte Z390 boards (VR VOUT sensor in HWinfo, for anyone reading this!) and some MSI boards have VR VOUT.  For non Asus WS / Maximus Z390 boards, if you have VR VOUT access in HWInfo64, use that for load voltage, guys.

Anyway record this voltage.  So in your case if you set 1.30v in bios, LLC6, it might be 1.225v at full load on your Asus WS.  If that's your stable prime 15K AVX FFT (29.8 builid 3) test, now switch to Ultra Extreme.

And set your bios voltage to 1.230v.  LLC8 or Gigabyte Ultra Extreme.  Yes, 1.230v.  Because that was your load voltage remember? (usually controllers go in 5mv steps so im giving a cushion for accuracy).

Then run LLC8 + 1.230v.  Do prime95 AVX 15K in place fixed FFT (custom).--min and max range 15K.

Your system won't last long. (If 1.230v were your actual load VMIN).  You will either BSOD or a thread will crash in the first 5 minutes.  That's because of transient drops.  Even though it looks like Prime95 is putting a constant full even load on your CPU, the load actually changes very often, too fast to register, thus transient drop=crash.

Feel free to message me on discord (remember, my username with #6092 at the end, Falkentyne) if you want to mess with this XD

And now that I derailed this thread talking about VRM's....back to your standard programming!

Still no ETA on patches? 😢

I received yet another crash with no error, and with error´including whea internal parity error. So i went back to LLC 6 from 8 at 4.9 ghz, 1.3 volt. Started from 1.2v and worked upwards. My load lines did not cause any heat issues or instability. Maybe a developer could explain if its a coding issue or cpu i would be glad. If this continues i might RMA my cpu and motherboard. Spectre and meltdown mitigation has been disabled, could this be a factor that brings up the error in event viewer, and coreparking disabled?