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.
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?
@Ariuc It's some sort of Intel microcode bug. RMA won't do anything.
I did some tests last night. I actually *disabled* loadline calibration completely (leaving it on the standard value of 1.6 mOhms of vdroop) and used Auto vcore, letting the Internal VR AC loadline do the work (which Intel specifies as 1.6 mOhms maximum also). This worked out fine (5 ghz) but idle voltages were much too high (1.40v) and low to medium load voltages were also too high, but Apex had no problems. 15k small FFT AVX prime95 ran fine here at 1.240v (VCC_Sense voltage) and 184 amps, and 96C max temps after 6 minutes, so this was ok but again not what I suggest. The reasaon I disabled Loadline Calibration and let the AC Loadlines do the work, is this improves transient response massively and stops excessive unmeasured voltage dips and spikes (Important for something like Prime95 on very high amps load).
I then enabled SVID offset, which kept idle voltages the same, and raised small FFT avx disabled prime95 by 30mv, but this raised AVX enabled prime95 small FFT by *90mv!*...leading to 212 amps, and 105C temps in FIVE seconds! Ouch....uh....
So SVID offset seems to boost certain load voltages.
Ok so I kept SVID offset enabled but set AC loadline to 1.0 mOhms (I kept DC loadline at 1.60 mOhms to match the CPU Vcore loadline calibration standard preset setting of 1.6 mOhms also). This reduced idle voltages significantly--down to 1.30 to 1.32v. Tested 0.9 and 1.0 mOhms for AC loadline were both rock stable in the harshest stress test on the planet (15K small FFT AVX prime95), with VR VOUT vcc_sense voltage reported at 1.230v (0.9 mOhms) and 1.250v (1.0 mOhms), and everything on the planet ran fine.
Except Apex Legends.
0.9 mOhms of AC loadline with SVID offset enabled caused random CPU parity errors. 1.0 mOhms didn't (most likely would have eventually; just didn't play long enough) but the game crashed anyway after awhile (with that typical "execute code before its ready" hexadecimal code crash). Probably 1.05 or 1.1 mOhms would be enough here but the idle voltage is getting too much for me to like.
I did these tests to take 'transient response' issues that occur when using CPU Vcore Loadline Calibration (aka VRM loadline) out of the picture. Since 15K AVX small FFT passed at very high amps, the transients were splendid. But the problem is, at a certain load voltage that would have no problem passing prime95, Apex Legends runs into this strange timing bug.
On my own system, it seems like, at 5 ghz, this "bug" happens if the CPU on-die sense voltage drops below 1.270v.
So far, going back to "manual" voltages and tweaking the usual CPU Vcore loadline calibration (instead of auto or SVID offset enabled and messing with the AC loadline value), I found the following settings so far, seem to make Apex Legends stable:
5 ghz: 1.290v, Loadline Calibration=Extreme.
5 ghz: 1.310v, Loadline Calibration=Turbo
5.1 ghz: 1.360v, Loadline Calibration=Turbo.
Hopefully @OrioStorm manages to code a fix in for this issue soon, and someone at Intel makes a microcode update that fixes this permanently (If Oriostorm can convince the right people at Intel that this is an internal processor bug).
EA Staff (Retired)@RascabuchesCH, the patch is working its way through the release pipeline. Hopefully it won't be much longer.
@OrioStorm I just got the weirdest error ever.
Check this one out (an "execute" error).
It said something like the CPU memory controller didn't want to execute one address while the CPU wanted (or didnt want) to execute another.
EA Staff (Retired)@Falkentyne, that's another bug that tended to happen in the same function. The crash referenced these two memory addresses:
0x00007FF79DD561B3 -- this is the memory address of the next instruction to execute
0x00007FF78CD061B3 -- this is the memory address that it claimed it did not have permission to execute
You'll notice that those numbers are very similar, except some of the lower 32 bits that are set in the top number are clear in the bottom number. For example, look at the first place the two numbers differ. 9D in hex is 1001_1101 in binary. 8C in hex is 1000_1100 in binary. The least significant bit goes from 1 to 0 in each of those digits. Later, 5 becomes 0, which goes from 0101 to 0000 in binary. (You can put your Windows Calculator into Programmer mode and let it do the conversions between decimal / hex / binary for you if you want to see for yourself.)
So, this is another example of a CPU not behaving properly. The instruction that the CPU wants to execute is the instruction at RIP, by definition. (RIP = Instruction Pointer Register. In 16-bit days it was just IP, then in 32-bit days it became EIP for Extended Instruction Pointer, and in 64-bit days it's RIP.) But it crashed saying it didn't have permission to execute an instruction NOT at RIP, which is a memory location it shouldn't have wanted to execute in the first place.
EA Staff (Retired)The patch that includes the work around for the Intel CPU crashes went live at 10 AM Pacific time today. It is version 1.1.3.
I'd be very interested in learning whether this fixes the crashes for everybody, even without lowering CPU speed.
had a crash on every game played since the release of the patch, first was a freeze with no crash report, second the program closed itself after a match, third generated a crash report, 2 other reports enclosed taken from today, have re-installed countless times, re-installed windows as well as other work arounds. hopefully get fixed soon.
EA Staff (Retired)@Ruon-21, the first two crashes are from the previous patch.
The first crash is in our loading code; it is populating memory, but the OS says it doesn't have permission to write to that memory. I don't know why it would crash this one time and work every other time; I'll have to see if there are any further clues in the crash info.
The second crash from the prior patch is inside the Windows OS called from inside DX11 called from when Apex was freeing a texture that it no longer needed in memory. Unfortunately, I can't really figure out anything more from this crash since it happened so deep inside 3rd party code.
The last one is from 1.1.3, but it is in an unknown DLL. Basically, we asked Windows what the DLL name was, and it said "I don't know". I can tell that this is not a thread that Apex creates, because there are no entries in "R5apex" at the bottom between "KERNEL32" and "module@...". The "KERNEL32" line is when the OS creates the thread that crashed, and the "module@..." line is the entry point in whatever 3rd party DLL it was that crashed for you. Unfortunately, if Windows can't tell us the name of the DLL that crashed, we can't tell you how to avoid the crash.
Thank you for the feedback.
That crash I mentioned the other day that you commented on happened at 5.1 ghz @ 1.360v bios setting (loadline calibration =Turbo, so load voltage was probably about 1.340v).
I did another run after that crash at the same voltage that day (same windows session) and got an "CPU Internal Parity Error" (WHEA Correctable).
Not 100% sure this is the exact timestamp of that error, but this happened *after* the crash I had posted.
A corrected hardware error has occurred.
Reported by component: Processor Core
Error Source: Corrected Machine Check
Error Type: Internal parity error
Processor APIC ID: 10
The details view of this entry contains further information.
so whatever Intel bug that was being generated was changing bits somewhere, and if it was "corrected", the game would continue playing and a WHEA would be logged. If it wasn't corrected, then you get one of those two 2F2DA breakpoints or something like as you mentioned.
With the new patch out:
I *REDUCED* the cpu core voltage at 5.1 ghz from 1.360v to 1.335v.
Been playing 1 hour 40 minutes.
ZERO crashes so far.
ZERO WHEA "Internal Parity Errors" generated.
So far it's been an improvement but I've seen "long sessions" in the past without WHEA parity correctable errors, then suddenly the game crashed when I got my hopes up.
But this is an improvement. I'll keep playing and keep testing the results. But preliminary answer is: "Good so far!"
Is Intel acknowledging this bug in their firmware? I know how stubborn Intel can be...
I know how to get new microcode ahead of time (before it's put into bioses), that's easy: Just download VMWare microcode updater and the microcodes as discussed here:
https://www.win-raid.com/t3355f47-Intel-AMD-amp-VIA-CPU-Microcode-Repositories-Discussion.html
and then the DAT to bin converter over here:
https://onedrive.live.com/?authkey=!AE_9xt1wnaLT5lk&id=11F4002E1134F403!617750&cid=11F4002E1134F403
Then you can download the microcode patcher itself (that has a current DAT file conversion already) from here:
https://mega.nz/#!gZBzBIib!wNZwqhegXl1FME7h5HLhsfAT55Xk_EyTN6QNBo7l6Qo
For new microcodes that are not in "Microcode.dat", you can convert the bin files from the archives to a new DAT file, then patch it with the mega microcode vmrware updater, after you rename your new dat file to "microcode.dat" and copy it into the cpucodeupdater folder manually.
Anyway tl;dr: it's a definite improvement *so far*. I'll keep playing all day until I find how stable it is.
@OrioStormthanks for the super fast reply man, kudos! ill post any more crash reports I get, have since repaired the game and not had a crash since, but its so unpredictable I'm sure more will occur
A crash... Again.....
EA Staff (Retired)@POF_Wyjakx, the CPU reported an illegal instruction at an address that has a legal instruction. This is in code that runs every single frame, where the instructions aren't changing. This shouldn't be possible if everything is working right, so the most likely causes are hardware issues, such as overclocking or memory that's slowly dying.
Are you overclocking your CPU by chance?
Hello,
I recently bougth myself a new pc with a ryzen 5 3600 and a rx5700. Most of the time if I start a match, before I choose my character i get a crash with the error "Apex crashed in atidxx64". My sytem is not overclocked or anything like that and I have fhe newest Drivers and updates installed! Here is an example for the crash:
crash:
{
atidxx64: 0000000000961F24
EXCEPTION_ACCESS_VIOLATION(read): 00000286E03D0000
}
cpu: "AMD Ryzen 5 3600 6-Core Processor "
callstack:
{
KERNELBASE: 00000000000FF67A
ntdll: 00000000000A4AF2
ntdll: 000000000008C6D6
ntdll: 00000000000A11FF
ntdll: 000000000006A289
ntdll: 000000000009FE6E
atidxx64: 0000000000961F24
atidxx64: 000000000009194F
atidxx64: 0000000000091545
atidxx64: 0000000000091CDF
atidxx64: 000000000002A4C0
atidxx64: 00000000000298ED
atidxx64: 000000000000A4E1
atidxx64: 00000000007A054C
atidxx64: 00000000007CFCBB
atidxx64: 000000000001BFA0
atiuxp64: 000000000000D37D
d3d11: 0000000000025BC5
d3d11: 0000000000025FF3
d3d11: 000000000007CDE3
d3d11: 000000000001E869
d3d11: 000000000002AF09
d3d11: 000000000002AF90
d3d11: 000000000002B398
d3d11: 000000000002B950
d3d11: 0000000000031174
d3d11: 0000000000030C47
R5Apex: 00000000003E998E
R5Apex: 00000000003E9CD5
KERNEL32: 0000000000017BD4
ntdll: 000000000006CED1
}
registers:
{
rax = 72
rbx = 0
rcx = 0x000002866148DFB0
rdx = 0x7EF42050
rsp = 0x000000B90B2CE498
rbp = 0
rsi = 1024 // 0x00000400
rdi = 0x00000286E03B0050
r8 = 112
r9 = 5
r10 = 0x00000286E03C2050
r11 = 0x0000028661480000
r12 = 1024 // 0x00000400
r13 = 0x00000286E03B0050
r14 = 1024 // 0x00000400
r15 = 0
rip = 0x00007FF96BF61F24
xmm0 = [ [1.5414283e-44, 0, 1.5414283e-44, 0], [11, 0, 11, 0] ]
xmm1 = [ [-5.0440096e+17, 9.0523881e-43, 1.4012985e-45, 0], [0xDCDFFFC0, 0x00000286, 0x00000001, 0x00000000] ]
xmm2 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm3 = [ [-0.5, 0, 0, 0], [0xBF000000, 0x00000000, 0x00000000, 0x00000000] ]
xmm4 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm5 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm6 = [ [7.1746481e-43, 7.1746481e-43, 1.4012985e-44, 1.4012985e-45], [512, 512, 10, 1] ]
xmm7 = [ [1.0089349e-43, 1.4012985e-45, 0, 0], [72, 1, 0, 0] ]
xmm8 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm9 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm10 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm11 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm12 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm13 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm14 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm15 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
}
build_id: 1567806032
I hope someone can help me soon, becasuse it is very annoying!
Hello, I have a game crash in Apex Legends, here the txt file Please fix it, I bought a battlepass and can't play the game! crash txt
Here we go again ☹️
No overclock. Trying the AVX - 2 quick-fix now.
This is the error I get. Nothing fixes it. I have tried everything and it had gone away and now it came back again!!!
