BF1 crash when HWInfo is running (Ryzen 1600X + Gigabyte AB350 Gaming 3)

[alexandrebr]

Hi, guys.

I've built a Ryzen system and I've noticed that, as long as HWInfo is monitoring it, random crashes happen when I'm playing BF1. My rig is:

R5 1600X
Gigabyte AB350 Gaming 3
2x8GB FlareX (3200Mhz, CL14)
Gigabyte GTX 970 OC MIni
Intel S730 240GB
SanDisk Ultra II 960GB
Seagate HDD 1TB
Akasa PSU PT-050FG 500W 

The bios is updated to F8 and all drivers are the latest, including the ones for AMD chipset (v.17.30). Also, everything is @default and I've tested system stability using AIDA64 for almost 8 hours and OCCT Linpack for half an hour.

In a thread dedicated to the AB350 Gaming 3 someone has mentioned "faulty implementation of the second ITE SuperIO chip which will cause a crash when certain utilities try to access it's telemetry data". Also, in the Gigabyte thread it was told that there's a .INI setting that would ignore the second ITE and fix the problem. 

Well, in order to isolate the problem, I've stopped using HWInfo 3 days ago and the crashes are gone. As well, I've noticed some strange readings when HWInfo was runing while I was playing Battlefield. 

Bus clock reading issue?

I don't use Ggiabyte APP Center or the Gigabyte SIV. I've also tried the latest version of HWInfo and the system crashed randomly. So, at the moment system isn't running any monitoring software. 

Having that said, I'd like to know if there's a fix for that and if this is, indeed, an issue caused by the motherboard chip. 

Thanks in advance.

 

[Martin]

The SuperIO problem you mention is known and it should be resolved in the last version of HWiNFO (v5.56).
But to make sure if it's still this problem, try to add the following lines at the end of the HWiNFO64.INI file and restart it:
LPC1=0
LPC2=0

Note, that you will loose some sensors in this mode, but if the problem will no longer happen, it means there's still some issue with that and we will look for another solution.

 

[alexandrebr]

I'll try that and will let a feedback here as soon as possible.

 

[alexandrebr]

The SuperIO problem you mention is known and it should be resolved in the last version of HWiNFO (v5.56).
But to make sure if it's still this problem, try to add the following lines at the end of the HWiNFO64.INI file and restart it:
LPC1=0
LPC2=0

Note, that you will loose some sensors in this mode, but if the problem will no longer happen, it means there's still some issue with that and we will look for another solution.

Well... I've played for several hours and no crash has happened. I'm running the portable version and, just as before, I run only the sensors.

I'll keep it running until the weekend and will report back.

At last, as you've mentioned, some sensors aren't displayed; basically the ones Gigabyte has inserted in the board to monitor temperatures and some voltages: SoC, VRM, PCIex, system, DRAM, +3.3, +5, +12, fans, etc.

 

[Martin]

Thanks for the feedback. That would indicate there's still some problem with the SuperIO and I will need to have a look at that.
Please let me know any updates. If all goes well, then you can try to remove the first item (LPC1=0) from the INI file and test again. Problematic should be only the second SuperIO (LPC2), which will remain disabled, but at least for the first one you should then get back some sensors.

 

[alexandrebr]

Thanks for the feedback. That would indicate there's still some problem with the SuperIO and I will need to have a look at that.
Please let me know any updates. If all goes well, then you can try to remove the first item (LPC1=0) from the INI file and test again. Problematic should be only the second SuperIO (LPC2), which will remain disabled, but at least for the first one you should then get back some sensors.

Two weeks after removing LPC1=0 from the INI and HWInfo hasn't caused any crash. The only issue I have is crazy reading of base clock/ram multiplier. The misreading problem has always happened, indeed.

 

[Martin]

Thanks for the feedback. That means, there's still some problem with the secondary LPC chip on the mainboard (IT8792E).
Could you please make one more test?
Remove also the LPC2=0 from the INI file and in the sensors window of HWiNFO completely disable the IT8792E sensor - hit Del key over the sensor heading, then all sensor items should appears with a red cross. Will this also work without issues ?

 

[alexandrebr]

Thanks for the feedback. That means, there's still some problem with the secondary LPC chip on the mainboard (IT8792E).
Could you please make one more test?
Remove also the LPC2=0 from the INI file and in the sensors window of HWiNFO completely disable the IT8792E sensor - hit Del key over the sensor heading, then all sensor items should appears with a red cross. Will this also work without issues ?

Opened .INI file and...

1. LPC2=0 wasn't in the end of the list anymore; it was in the middle. I don't know if this must be pointed out but, anyway, I think it should be said.
2. After removing LPC2=0 and restarting HWInfo memory clock ratio was marked with red cross.
3. Selecting "Memory Timings" and pressing DELL made all readings/sensors in this category show a red cross.
4. Pressing INSERT made readings come back, including MEMORY CLOCK RATIO.
5. After selecting all categories (cpu, memory, system, etc.), I've pressed DELL and INSERT: all readings appeared with a red cross (DELL) and turned back to normal values (INSERT).

 

[Martin]

It doesn't matter if the LPC2=0 setting is at the end of the INI file or in the middle.
My point was to test without this setting and with completely disabled IT8792E sensor (all its items and the heading marked with a red cross).
Can you please try this ?

 

[alexandrebr]

Hitting dell/insert works without issues.

 

[Martin]

So with this combination (and LPC2=0 removed) does the system run stable ?

 

[alexandrebr]

So with this combination (and LPC2=0 removed) does the system run stable ?

I'll have to try it during the week. I'll report back in a few days.

 

[alexandrebr]

So with this combination (and LPC2=0 removed) does the system run stable ?

After one week, no issues with that combination.

 

[Martin]

Thanks for the feedback. This means there's probably one more problem with this SIO/LPC (besides the one that I already resolved).
This is most probably some instability of the chip when being periodically polled, but I'm not sure how to workaround this yet.
Problem is also that this chip is a special ITE design for GIGABYTE and neither of them is willing to disclose more information about it

 

[alexandrebr]

Thanks for the feedback. This means there's probably one more problem with this SIO/LPC (besides the one that I already resolved).
This is most probably some instability of the chip when being periodically polled, but I'm not sure how to workaround this yet.
Problem is also that this chip is a special ITE design for GIGABYTE and neither of them is willing to disclose more information about it

Thank you very much for the information. I think I'm gonna get an Asrock Taichi just because I don't really like the way Gigabyte has implemented Gaming 3 sensors. It seems that, although secondary ITE is ignored, monitoring softwares have misreadings (0RPM for fans, crazy BCLK swing, etc.). Another example: I have a Noctua ND15S and my 1600X has had temperature jumps from time to time; HWInfo has registered 78ºC for TDie albeit the heatsink has been installed again (my sistem is installed in a Corsair 460X, 3 120mm fans for intake and 1 outtake).