Maximus V Extreme Possible 1501 BIOS conflict with AIDA64 EE monitoring in background

[feniks]

Thanks to Raja@ASUS, StackOverflow13, BillyRay520 and others for input, suggestions and support.

Symptoms:
Some ASUS motherboard users (me included) started observing an odd phenomenon when leaving AIDA64 EE sensor monitoring program turned on and running for more than 1 hour at idle, the system could unexpectedly shut down forcefully (like someone held a power button) or suddenly restart (like someone pressed reset button), no BSOD is produced in both scenarios.
This may happen at stock system or overclocked. Furthermore, when system unexpectedly shuts down during such incident the user will notice that power button becomes unresponsive and there is no way to power the system up again until the power is cut to Power Supply.

How to replicate this:

1. Utilizing ASUS motherboard (confirmed on P8Z77 V PRO series and Maximus V series) with BIOS updated to revision containing some newer Windows 8 stability improvements (above 704 on MVE).

2. Ai Suite (versions up to V2.01.01) was installed including the Fan Xpert 2 module at some point in time, application might have been completely uninstalled at later time or left installed and not running, doesn't matter.

3. Running AIDA64 EE (tested up to beta 2.70.2260 with active ATKEX sensor polling) with Sensor Monitoring tab opened and sensor polling left active.

4. After e.g. 1-2 hours of idle the system will encounter a problem on electrical level causing an instant restart or shutdown (with further inability to power up until power is cut to the Power Supply). No BSOD is produced when this happens. It is confirmed at stock BIOS settings (tested personally with 1501 & 1604 MVE BIOS) straight from Clear CMOS or Loading Optimized Defaults, observed on both Windows 7 x64 Pro SP1 and Windows 8 x64 Pro, also reported by others to happen on any BIOS revision above 704 for MVE, and others similar for different models (e.g. MVF, P8Z77 V Pro running 1805, etc.).

Cause:

After severe testing performed in this thread, it was found that the culprit is within the service called "ASUS HM COM" which gets installed together with Ai Suite. Nothing will go wrong if Fan Xpert 2 module was never installed, then this service stays harmless.
However after installation of Fan Xpert 2 module, this service and possibly two other ASUS services called ASUS COM Service & ASUS System Control Service start conflicting with AIDA64 and eventually it causes the unexpected system behavior leading to result looking like a near hardware failure (e.g. faulty Power Supply or damaged processor or bad motherboard).

Scenarios and workarounds:

1) On a system never allow to install Fan Xpert module (you can use Ai Suite's other components) or avoid the whole Ai Suite in general

2) if Fan Xpert module was ever installed then your system stays affected even after complete uninstallation of whole Ai Suite! Please follow the below outlines to fix the problem without re-installation of OS.

The reason is that the service ASUS HM COM stays left behind and running on your system even after complete uninstallation of Ai Suite (nice touch, isn't it?), you can either manually disable this service (e.g. via Computer Management) or remove it all together. Installation of Fan Xpert does something to those ASUS Service(s) and that's when the problem appears for the first time (and stays even after Ai Suite uninstall, because those services are left behind).

To remove the ASUS services manually after Ai Suite uninstallation:
1) open the elevated Command Prompt with admin rights
2) type below commands and hit enter after each one:

NET STOP ASHMCOMSVC
SC DELETE ASHMCOMSVC
NET STOP ASCOMSVC
SC DELETE ASCOMSVC
NET STOP ASSYSCTRLSERVICE
SC DELETE ASSYSCTRLSERVICE

NOTE: removing all 3 services will disable ROG OC Key and possibly also other ASUS software (ROG Connect, etc.), the software for it will need to be re-installed or should be uninstalled before applying the fix.
NOTE2: You can download a batch file with above commands from here
After download, use it by r-clicking and selecting Run As Administrator and follow simple instructions on screen to continue.

Alternatively you can use automated tool to do this for you:
unofficial Ai Suite cleaner tool (thanks to BillyRay520's post, link to tool here - signup required)

3) If you plan on ever installing any components of AI Suite again on affected system you NEED to uninstall all traces of it before re-installation or the problem will come back. Also I suggest uninstalling ROG OC Key at this point too (uses 2 out of 3 ASUS services) as outlined above (full uninstall and removal of services).

if for any reason normal uninstallation of Ai Suite fails, then you can run REVO Uninstaller Pro (get it for free here) and let it scan system for all traces of Ai Suite and remove them from everywhere (files, registry, everywhere)

... then install the desired components of Ai Suite (except for Fan Xpert!!!), restart your system and pray to digital gods the problem is gone 😉

*4) There seems to be slight in difference in how this bug manifests itself on non-UEFI booted systems vs UEFI booted systems (it's confirmed on 2 different MVE boards and different components):

a) non-UEFI/Legacy Boot: most of the time system will perform an unexpected shutdown (no BSOD) on its own at idle and won't be able to power up agan, the power button will become unresponsive, the PSU needs to get cycled to restore working condition.

b) UEFI Boot: system will perform an unexpected shutdown (no BSOD) on its own at idle and shortly after it will power up again on its own like nothing happened.

This problem was reported to AIDA64 developer Fiery, hopefully they can compensate in their software code for this odd behavior.
here's the Bug Report in AIDA forums:
http://forums.aida64.com/index.php?/topic/1155-asus-maximus-v-extreme-aida64-unexpected-restartsshut...

This problem was also reported to ASUS VIP technical support, case ID RWTM201301161127303846-391.

It would be also nice if ASUS pulled their things together and more thoroughly tested what they release to public, nobody likes dirty uninstallers that leave lots of potentially harmful stuff behind. Ignoring the problem won't help solving the issue and will leave plenty of unsatisfied customers running affected systems.


*** Original post as it was initially ***

At first a little rant on recent BIOSes for MVE.

I can't say I like recent MVE BIOSes after introduction of ROG Exchange (1309, 1408, 1501) - all of them seem to have occasional issues with corrupted multiplier settings after a while (Clear CMOS fixes it for some time until crashed/bad OC and then problems start growing until another Clear CMOS).

also some other settings sometimes get reverted to default during restart (e.g. most annoying Internal PLL gets disabled, some CPU Power settings reverted to auto, memory Ai reverted to auto, Digi+ reverted to default), that happens mostly after failed overclocking, but I have seen that also at high clocks on 3770K when running 5.1 and 5.2GHz for no real reason. sometimes the multiplier just doesn't kick in and stays where it was the last time.

Lastly, all of those BIOSes (especially after a crashed OC) cause some CMOS settings corruption when Load Defaults (F5) is used. generally some junk settings get loaded and no matter what I set in BIOS, the BIOS shows one thing and does other thing at boot up - easy to double check when Windows boots up actually and you can see voltages and CPU multiplier in there). E.g. I set 5.0GHz (50x multi) with known good offset and discover my system running at 3.9GHz with quite another voltage (neither a stock setting). again, clearing CMOS fixes it (for some time).

/end rant

However, this post is about potential BIOS conflict with the latest version of AIDA64 EE software running in background and BIOS 1501 (issue replicated a few times). Whatever you read below, please note it does NOT happen on BIOS 704.

So, I am running my daily OC on 3770K @ 4.9GHz, running 75% LLC and 0.185 offset (by the way BIOS 704 can do same stable with 0.175 offset while 1501 can't), everything perfectly stable, my system runs 24/7 for 2 weeks. Then I decided to run AIDA64 in background for sensor monitoring and leave my computer over night (as always) turned on.

In morning I find it shut down, so I press the power button and nothing happens. After I cycled the PSU off and after a few secs to on position I can use the Power Button to boot up as normal (all works), with aida64 in background. Then I use the computer for several hours gaming, browsing net, watching movies, listening to music, etc and leave it as always on. again after a while it shuts down on its own and can't power up (until I cycle the rocker switch on PSU). once it shut down at idle (in same manner) while I left it alone for only 15 minutes, literally shortly after the monitor went to sleep (standby) and of course again the Power Button was unresponsive until the PSU rocker switch was cycled.

I have seen this behavior half a dozen times until I found out that it was running AIDA64 in background what triggers it. But going further I noticed that running BIOS 704 (and AIDA64 in background) causes no issues what so ever. what gives ... bugged BIOS 1501 (and potentially 1309 & 1408)?

Can anybody else replicate this?

[Raja]

Hi,


A few things that stand out:

1) Chances are the higher OCs you state are not 100% stable. During POST the IMC performs over 1000 read and writes to train the DIMMs. If there is any instability during that process the board will not POST.

Power down~power on will perform more aggressive training. Warm resets perform a less aggressive memory training routine to account for any thermal drift. The microcode is updated in some UEFI versions - these often have changes to memory training parameters and will suit some DIMMs more than others. Not much we can do about that. Bottom line is just to peg back the OC until the board is 100% stable (remember any stress test just means the system is stable doing that one thing and possibly a few others - does not mean unconditional stability in every scenario).

If the system is very unstable, then UEFI may reset during POST. To debug this revert to stock, then apply very mild overclocks to the system over a period of a few days and see how the system responds. Be conservative during this period so you can get an idea which of the system clocks is a larger contributor.

If the multiplier becomes unchangeable no matter what you do, it usually means the ME is corrupt. The fact your system reverts to being usable after CMOS clear points at instability, however.

2) Sounds like AIDA is interfering with AI suite monitoring and tripping a board failsafe. Are you using Ai Suite at the same time as AIDA? Doing so results in polling errors. Fix is to turn off related failsafes (where possible) or to use only one polling tool - so either use AI suite, or AIDA, not both.

-Raja

[zalbard]

Raja@ASUS wrote:
If the system is very unstable, then UEFI may reset during POST. To debug this revert to stock, then apply very mild overclocks to the system over a period of a few days and see how the system responds. Be conservative during this period so you can get an idea which of the system clocks is a larger contributor.

Thanks for the info!

Can it do a partial reset?

I sometimes find that my system resets -some- UEFI settings back to stock (for example, PLL overvoltaging). While some others stay intact (say, CPU vCore). I was not able to find a reason for such behaviour yet.

Can I actually disable any automatic UEFI resetting?

[feniks]

Raja, thanks for chiming in, but with all do respect man ... you are totally wrong on this one, you misread my post entirely and assumed things that are not the case here being the essence of this entire post sadly.

as per 1) it could be the case at 5.1GHz or 5.2GHz (1.57V vcore on fixed setting and nearly 1.7V for the other respectively) as I mentioned other problems in latest revisions of BIOS in initial part of post. I also wrote, that to get to those stable values one has to go through some crashes to find the stable vcore. I test for vcore stability with Cinebench 11.5 x64 (CPU) runs, and if I can do a few of them without any WHEA warnings in Windows 7 Event Logs then I assume the vcore is stable and later confirm it with Intel Burn Test 2.54 in Max Mode (e.g. 10-20 rounds) if there is thermal headroom to do so (I run water cooling setup, I am slave to room ambient temps) and my temperatures allow me to do that up to 5.1GHz with cold enough ambient room.

However all of this is meaningless, because my problem as described after initial rant (unexpected system shutdown with inability to power up again when using BIOS 1501 AND AIDA64) happens at fully stable daily clock of 4.9GHz (running with actual 1.38v vcore under load) which normally runs for weeks with heavy use (gaming, stress testing), daily tasks (whatever) and lots of idling in between, never a single crash, nor a single WHEA warning in Event Logs, nor ANY kind of ANY problem at all. System has been confirmed stable for hours under Intel Burn Test running in maximum memory mode, I have ran MemTest86+ 4.20 for over 14 passes on it without a single slightest error, I have run Prime95, gamed for hours, and had never seen a single indication of instability at this daily clock.

The problem is the moment I leave computer idling for long AND latest AIDA64 (2.70 Extreme Edition) runs in background AND this MVE board runs BIOS 1501, then it WILL unexpectedly shutdown on its own (like someone held the Power Button for 4 seconds) eventually sooner or later AND the Power Button WILL NOT be responsive after that UNTIL I cycle the rocker switch on power supply.

Now, that being said, above statement does NOT hold true for BIOS revision 704 and I can again run system indefinitely at my daily 4.9Ghz without any problems AND while using AIDA64 in background.
Logically speaking the only difference between both scenarios is the BIOS revision, no? so the root cause of problem is a bugged BIOS, since I can't find a logical answer to the fact that a piece of monitoring software *causes* a near hardware failure, but I can understand that it can trigger some software bug lurking in BIOS (hence why it happens on 1501 revision but it does not happen on 704 revision).

as per 2) I do not use Ai Suite at all, only AIDA64.

what gives? a BIOS problem, especially in scope of issues I observe across all BIOSes since ROG Exchange was introduced (1309, 1408, 1501) and mind that I mean issues that I never observed prior to that (tested only 704).

I hope it clears it up.

If you want me to replicate the problem (unexpected shutdown with AIDA64 running on bIOS 1501) on some milder CPU clock ensuring firmer stability, then give me that desired clock speed of CPU & memory speed/timings and I will run those settings and let you know if same problem persists.

I can propose 4.7GHz CPU speed (calling for 1.21v vcore under load) with RAM running XMP settings (2000MHz CL9 @ 1.65V) or RAM running 1600MHz CL9 with 1.50V, would that do?
I do not run slower CPU clocks than 4.7GHz and never even bothered stabilizing them.

[feniks]

also, to rule out my PSU as the culprit I did actual voltage measurements with multimeter on running system at idle and under load (CPU running linpack and GPUs in SLI running Graphical test in OCCT).

ATX 2.2 tolerances
http://www.formfactors.org/developer%5Cspecs%5Catx2_2.pdf
page 22

+5VDC +/- 5% = 4.75 ~ 5.25V
-5VDC +/- 10%
+12VDC +/- 5% = 11.40V ~ 12.60V
-12VDC +/- 10% = 10.80V ~ 13.20V
+3.3VDC +/- 5% = 3.135V ~ 3.465V
+5VSB +/- 5%

System:
3770K @ 4.9GHz with 75% LLC, offset 0.175 (1.366v actual vcore - BIOS 704), 350KHz CPU Voltage frequncy, Extreme CPU Phase control, C1E enabled, C3/C6/C-state disabled, EIST enabled.
Mushkin 996990 2x4GB RAM running 2400MHz 10-12-11-28 2T (Loose Hynix preset) @ 1.70V
VCCIO 1.15v
VCCSA 1.15v
CPU PLL 1.60v
2x evga 670 2GB in SLI (8x/8x) overclocked to 1267Mhz core 7012MHz memory
SATA6_0 240GB Mushkin Chronos SSD (fw 5.0.4)
SATA6_1 2TB Hitachi 5k300 hdd
sata3 devices: 1.5TB WD Caviar Green, Sony Optiarc DVD-RW
System is water cooled with following parts:
-CPU block XSPC Raystorm
-GPU full cover blocks: 2x XSPC Razor 670 with backplates
-XSPC RX240 radiator (push-pull fans) + XSPC EX360 radiator (push-pull fans)
-Koolance PMP-450S (D5 Strong) water pump @ 24V off voltage controller

Thermaltake TPG-1050M 1050W PSU testing w/ DMM
a) at idle
+12V (molex 4-pin) 12.27v
+5V (molex 4-pin) 4.99v
+3.3 (24-pin) 3.38v
+12V (24-pin) 12.28v
+5V (24-pin) 5.03v
+12V (EPS 8-pin) 12.27v
+12V (PCIe) 12.27v

b) under load (OCCT PSU Stablity Test)
+12V (molex 4-pin) 12.23v
+5V (molex 4-pin) 4.98v
+3.3 (24-pin) 3.37v
+12V (24-pin) 12.27v
+5V (24-pin) 5.02v
+12V (EPS 8-pin) 12.04v
+12V (PCIe) 12.03v

During OCCT PSU Stability Test, the peak load observed on APC UPS was 800W, minus the 24'' LCD which is also plugged in to it, equaling the maximum peak wattage of system under full load at around 730W (PSU rated for 1050W, lots of headroom).

I also measured vcore, vccio and vccsa using ProbeIt and EZ readout point on motherboard at above system configuration under load (intel Burn Test 2.54):
a) vcore 1.366v
b) vccio 1.146v
c) vccsa 1.147v

Everything seems in order, no crashes what so ever, no WHEA warnings in Windows 7 Event Logs under either BIOS 1501 or 704 and yet when running AIDA64 2.70 with MVE running BIOS 1501 the system will unexpectedly shutdown forcefully AT IDLE on its own (no BSOD, just power down) and won't be able to power up until PSU gets cycled off & on. Again, this issue does not happen with BIOS 704.

Haven't tried to replicate the problem on BIOS 1501 at lower CPU/MEM clocks yet, not sure if I should or not. waiting for a reply.

[Raja]

As I said, POST stability and OS stability are two different things. The IMC can be subject to drift at times - some CPUs struggle with training on first attempt (especially when pushed hard, varies from CPU to CPU and the parts used) and the system then reverts to SAFE MODE or you can corrupt the ME. Result will be that the multipliers appear not to take, or some of the settings can revert upon POST. This still stands in answer to your opening rant on high clocks/overclocks. Now, if that offends, all I can say is, sorry and calm down please. All I did was give you the reason for why it can manifest, even when or if the system appears stable in the OS with all manner of tests.


As for number two. I did ask if you were running the tools. As I have seen misreports of polled values a lot, I don't think I did anything wrong by posing the question and supposition. Again, sorry if that offends.


So back to what you want help with: Revert the processor to stock operating frequency (Use a memory speed of ddr3-1333 if you want to take that out of the equation also) and see if you still get shutdowns in AIDA and if the start-up issues are still present. That way you don't have to work out Vcore provided your CPU has not deteriorated (this is not to say it has, it's just some do after being pushed). If you still get crashes, then it might be an idea to ask the AIDA developers also - they might ask you for a log which can help pinpoint the issue. Might be the quickest way of working out the cause - and that's why I feel stock frequency is best to eliminate any weird OC variables (regardless of your stress testing).

Once you can pinpoint it, I can fire something at HQ for replication. Just need you to go through the basics first so we don't end up on a goose chase or looking for a needle in a haystack.

Deep breath, all is normal again. We'll get to the bottom of it. 🙂

-Raja

[feniks]

nah, not feeling offended at all LOL! sorry if I sounded a bit too defensive (or even offensive on my part LOL!), but I am just really not fond of latest BIOSes for this board ... was just merely showing that certain trouble started for me with all newer BIOSes like 1309/1408/1501, I mean POST weirdness or clocks misreported in Windows that I have never seen before on old good 704 at exactly same settings.

I understand what you are saying, thanks for more info on POST routines and how safe mode may kick in sometimes. yet, only on 1501 (or 1309/1408), and never on BIOS 704 at same settings. that's my point regarding that initial rant of mine 😉

on 1309/1408/1501 BIOS, the clocks that mostly "do not kick in" sometimes at POST are only the ones above 47-48x multiplier (while they always work perfectly fine always on 704 BIOS).

I am unsure if that is a Safe Mode of BIOS manifesting itself this way, but all looks normal in BIOS regarding actual CPU speed and Target speed after Save+exit+restart and yet in Windows the reported clock is from the former OC (before upping it and save+exit), e.g. reporting max 47x instead 49-52x.
it all depends on what the last clock was before the change to higher clocks. it doesn't happen always either, and always a CMOS CLR helps to make it run normally again with exactly same settings and problems seems gone for many later restarts .. until it just returns when changing multipliers again to higher ones at some point in near future again. That's what I really dislike about those BIOSes, 704 doesn't show such behavior at all when moving between multipliers, nor it defaults most of settings at all (at least not when I use known good ones).

as per some more testing regarding the unexpected shutdown on 1501 with AIDA64 running in background, it seems it happens only at 4.9GHz+ speeds on this BIOS as so far it haven't occurred in over 12 hours with system at 4.7GHz with RAM running XMP (2000MHz) while on BIOS 1501. certainly it won't happen at stock clocks, so I think there is no point in testing it at stock speeds.

The real question stays, why it does happen when running BIOS 1501 and not when running 704 at exact same settings ... I believe both issues I mentioned (initial rant and unexpected shutdown with aida64) are related to each other. what do you think?

in summary:
1. on BIOS 704:

a) I can POST always with my known good settings at all multipliers up to 52x (thermally limited for me, can't stabilize it anymore)

b) unexpected shutdown problem with aida64 never happens at 4.9GHz

2. on BIOS 1501 - and possibly also on 1309 and 1408 but I haven't checked per b):

a) I can POST always with my known good settings, values reported in BIOS look good, but in Windows clocks often max out at former value e.g. 39x (if it was stock before) or 47-48x multiplier (since I use them often) until I clear Cmos and then it's all good again;
once in Windows I noticed it maxed out at 3.9GHz while in BIOS I entered settings for 4.9GHz (and they were applied successfully and applied, system POSTed I entered BIOS and it confirmed the actual values at 49x multiplier, yet after booting to Windows it reported 3.9GHz max and voltage just like it would be for 4.9GHz;
sometimes some (and only some, never all) values in BIOS get reverted to default during a simple restart.
sometimes using option to Load Defaults (F5) in BIOS loads junk settings and then only Clear CMOS can fix the problems with stability and actual effective values.

b) when running aida64 at 4.9GHz I get unexpected shut downs at idle and can't power up after that until PSU gets cycled.

I think I will just go back to 704 and call it a day LOL ... that BIOS worked very well ... can't say that about any newer one unfortunately ...

Raja@ASUS wrote:
As I said, POST stability and OS stability are two different things. The IMC can be subject to drift at times - some CPUs struggle with training on first attempt (especially when pushed hard, varies from CPU to CPU and the parts used) and the system then reverts to SAFE MODE or you can corrupt the ME. Result will be that the multipliers appear not to take, or some of the settings can revert upon POST. This still stands in answer to your opening rant on high clocks/overclocks. Now, if that offends, all I can say is, sorry and calm down please. All I did was give you the reason for why it can manifest, even when or if the system appears stable in the OS with all manner of tests.


As for number two. I did ask if you were running the tools. As I have seen misreports of polled values a lot, I don't think I did anything wrong by posing the question and supposition. Again, sorry if that offends.


So back to what you want help with: Revert the processor to stock operating frequency (Use a memory speed of ddr3-1333 if you want to take that out of the equation also) and see if you still get shutdowns in AIDA and if the start-up issues are still present. That way you don't have to work out Vcore provided your CPU has not deteriorated (this is not to say it has, it's just some do after being pushed). If you still get crashes, then it might be an idea to ask the AIDA developers also - they might ask you for a log which can help pinpoint the issue. Might be the quickest way of working out the cause - and that's why I feel stock frequency is best to eliminate any weird OC variables (regardless of your stress testing).

Once you can pinpoint it, I can fire something at HQ for replication. Just need you to go through the basics first so we don't end up on a goose chase or looking for a needle in a haystack.

Deep breath, all is normal again. We'll get to the bottom of it. 🙂

-Raja

[Raja]

feniks wrote:
nah, not feeling offended at all LOL! sorry if I sounded a bit too defensive (or even offensive on my part LOL!), but I am just really not fond of latest BIOSes for this board ... was just merely showing that certain trouble started for me with all newer BIOSes like 1309/1408/1501, I mean POST weirdness or clocks misreported in Windows that I have never seen before on old good 704 at exactly same settings.

I understand what you are saying, thanks for more info on POST routines and how safe mode may kick in sometimes. yet, only on 1501 (or 1309/1408), and never on BIOS 704 at same settings. that's my point regarding that initial rant of mine 😉

on 1309/1408/1501 BIOS, the clocks that mostly "do not kick in" sometimes at POST are only the ones above 47-48x multiplier (while they always work perfectly fine always on 704 BIOS).

I am unsure if that is a Safe Mode of BIOS manifesting itself this way, but all looks normal in BIOS regarding actual CPU speed and Target speed after Save+exit+restart and yet in Windows the reported clock is from the former OC (before upping it and save+exit), e.g. reporting max 47x instead 49-52x.
it all depends on what the last clock was before the change to higher clocks. it doesn't happen always either, and always a CMOS CLR helps to make it run normally again with exactly same settings and problems seems gone for many later restarts .. until it just returns when changing multipliers again to higher ones at some point in near future again. That's what I really dislike about those BIOSes, 704 doesn't show such behavior at all when moving between multipliers, nor it defaults most of settings at all (at least not when I use known good ones).

as per some more testing regarding the unexpected shutdown on 1501 with AIDA64 running in background, it seems it happens only at 4.9GHz+ speeds on this BIOS as so far it haven't occurred in over 12 hours with system at 4.7GHz with RAM running XMP (2000MHz) while on BIOS 1501. certainly it won't happen at stock clocks, so I think there is no point in testing it at stock speeds.

The real question stays, why it does happen when running BIOS 1501 and not when running 704 at exact same settings ... I believe both issues I mentioned (initial rant and unexpected shutdown with aida64) are related to each other. what do you think?

in summary:
1. on BIOS 704:

a) I can POST always with my known good settings at all multipliers up to 52x (thermally limited for me, can't stabilize it anymore)

b) unexpected shutdown problem with aida64 never happens at 4.9GHz

2. on BIOS 1501 - and possibly also on 1309 and 1408 but I haven't checked per b):

a) I can POST always with my known good settings, values reported in BIOS look good, but in Windows clocks often max out at former value e.g. 39x (if it was stock before) or 47-48x multiplier (since I use them often) until I clear Cmos and then it's all good again;
once in Windows I noticed it maxed out at 3.9GHz while in BIOS I entered settings for 4.9GHz (and they were applied successfully and applied, system POSTed I entered BIOS and it confirmed the actual values at 49x multiplier, yet after booting to Windows it reported 3.9GHz max and voltage just like it would be for 4.9GHz;
sometimes some (and only some, never all) values in BIOS get reverted to default during a simple restart.
sometimes using option to Load Defaults (F5) in BIOS loads junk settings and then only Clear CMOS can fix the problems with stability and actual effective values.

b) when running aida64 at 4.9GHz I get unexpected shut downs at idle and can't power up after that until PSU gets cycled.

I think I will just go back to 704 and call it a day LOL ... that BIOS worked very well ... can't say that about any newer one unfortunately ...

1) Could be down to a microcode change (between UEFI versions) or a change of our start up routines. Intel's changes to DRAM training can cause issues with some CPUs. I did say this earlier, that MRC updates can cause issues on some systems simply due to Intel changing some of the DRAM training rules. If that's the case, there is not much we can do about it moving forwards. That's why some BIOSes are better for some CPU/memory combinations than others. Looking at the change-logs, there has definitely been a microcode update between these UEFI revisions.


2) Let me know how it goes on stock. Also contact the AIDA guys and see if they know what it is - those guys are good and usually know if there is a conflict.


-Raja

[feniks]

known good (on 704 BIOS) clock of 4.7GHz with XMP RAM failed unexpectedly with AIDA64 running in background after around 6 hours of idle. I missed it, because it simply restarted without BSOD and was waiting on logon screen while I in morning only took a glance at computer if it was running (it was LOL) ... so going to try failing it on stock clocks and 1333MHz ram now.

I dislike BIOS 1501 more and more with every day ...

[feniks]

It did it again at stock 3770K clocks and 2x4GB ram running 1333MHz (9-9-9-24 @ 1.50V). In morning i found the computer shutdown and it was unresponsive to the power button until I cycled the psu (same behavior as at my daily 4.9GHz with ram running 2400MHz).

Definitely there is some screw up in bios 1501. I guess those microcode updates do not work well for everybody ...

I am going back to 704, it's the last MVE BIOS that worked perfectly fine for me on 5 different 3770K chips and does not have any trouble with aida64 monitoring in background.

Raja@ASUS wrote:
1) Could be down to a microcode change (between UEFI versions) or a change of our start up routines. Intel's changes to DRAM training can cause issues with some CPUs. I did say this earlier, that MRC updates can cause issues on some systems simply due to Intel changing some of the DRAM training rules. If that's the case, there is not much we can do about it moving forwards. That's why some BIOSes are better for some CPU/memory combinations than others. Looking at the change-logs, there has definitely been a microcode update between these UEFI revisions.


2) Let me know how it goes on stock. Also contact the AIDA guys and see if they know what it is - those guys are good and usually know if there is a conflict.


-Raja