Stock system fails stress test

[PetrolHead]

To begin with, here are my system specs:

CPU: AMD Phenom II X6 1090T BE
GPU: NVidia GTX 650
MB: ASRock 970M Pro3
RAM: 2 x 8 GB Kinston HyperX Fury Black DDR3 (official numbers 1600 MHz CL10, stock values 1333 MHz CL9 due to Phenom II)
PSU: Cooler Master V650S
HDD: Samsung 850 EVO SSD 250 GB
Case: BitFenix Prodigy M
CPU Cooler: Arctic Cooling Freezer A11
Fans: 2 x BitFenix Spectre 120 mm
OS: Windows 8.1 64-bit & Linux Mint 17.2 Cinnamon 64-bit

I was taking a swing at overclocking my current system and had ended up with what I thought was
a pretty stable overclock. I could run Prime 95 with all of my six cores for 8 hours without any errors
and I also cleared 4 hours of Prime95 with a single worker while testing the stability of my OC'd Turbo
Core mode. Socket temp maxed out at the recommended 70 C limit and CPU temp maxed out around
54 C. I ran different benchmarks (GeekBench 3.3, PerfomanceTest 8.0, Cinebench R15, Unigine Heaven,
3DMark11, 3DMark, CPU-Z, SuperPi mod1.5 XS, SiSoftware Sandra Lite 2015.SP3) and encountered
no issues with any of them. Even RealBench benchmarked without a glitch. However, while running the
RealBench stress test (set for 16 GB and 2 hours) I got nine result mismatches in the first 90 minutes or
so (I was afk, so couldn't stop the test before). I know that passing Prime95 or having low temps do not
guarantee stability, but I was still surprised to run into an issue. Naturally, I started to lower my already
very mild OC and running the stress test again. Then I reached stock values and I still get a result
mismatch withing the first 700 seconds of the test.

So far I have tried relaxing my RAM timings a bit and even running it with as 1066 MHz CL7 (SPD values
for this clock speed), but to no avail. I've been looking at the log files, trying to find any and all error
messages, and I found this at the beginning of the log file:

Handbrake: x264 [warning]: --psnr used with psy on: results will be invalid!
x264 [warning]: --tune psnr should be used if attempting to benchmark psnr!

It seems that it takes the stress test about 700 seconds to finish one cycle. Now, if the above error message
means what it sounds like, I will always get an error message when the cycle finishes, no matter what I do.
Could this be the reason the test fails even when the system is running at stock values? The benchmark
itself I've run 10 times in a row without any stability issues with a stock system. I would welcome any tips
and possible explanations.

P.S. It should be noted that the RAM modules aren't officially supported for my motherboard. Kingston's
memory search suggests these for the ASRock 970 Pro3 R2.0, which is essentially the ATX-sized version of
my mATX motherboard. ASRock just hasn't tested this kit on the motherboard, so can't really guarantee
compatibility. This is why I've concentrated on trying to find a stable timing for the RAM, but then again
I've had zero issues with my stock system before running RealBench stress test. If the RAM was really
incompatible, I wouldn't expect it to be as stable as it has been.

P.P.S I am at the moment running Prime95 with custom settings so that it uses all of the 16 GB of RAM I
have. It has been running for a bit over an hour now without any issues.

Edit: I forgot to mention that I'm running RealBench 2.41and I've also tried running the stress test using
8 GB of RAM, but the result is the same.

[PetrolHead]

Since MemTest86 revealed a possible multiprocessing issue with my UEFI version, I decided to test whether this could
be linked to the issue I'm having with RealBench stress test. I used Core Control to disable five of my six cores and set
the stress test to run for four hours with 16 GB of RAM. I had a lightly OC'd Turbo Core -mode, CPU-NB/HT Link and
OC'd RAM at this point, but since having a stock system had not helped previously and the OC has been stable in an 8
hour, 16 GB Prime95 blend test, I just assumed I could leave it as is for now. Now, I didn't stick around for the whole 4
hours and since the program gives no clue as to when it noticed an error and you'd have to manually go through the
log file to get an idea of how many cycles the test may have finished, I don't know where the mismatch came. I only
know that during those four hours there was one result mismatch. The only conclusion I can make is that a
multiprocessing issue is not enough to explain the stress test's behaviour. It's likely not a memory issue either, since
26 hours (4 full passes) of Windows Memory Diagnostic Tool's extended test revealed no errors and single-threaded
MemTest86 run also showed no errors (although I didn't run it for as long as the WMDT).

Looking at the logfile of the stress test does at the very least reveal that RealBench is still very much a work in progress
(as does the GUI, but I'll get to that later in some other thread). These are the sort of error messages that can be found
in the logfile:

error opening C:/.../RealBench_v2.41/RealBench/Video/DVD/BDMV/BACKUP/index.bdmv
nav_get_title_list(C:/.../RealBench_v2.41/RealBench/Video/DVD) failed

libdvdread: Encrypted DVD support unavailable.
libdvdread: Device (null) inaccessible, CSS authentication not available.
NAME OPEN FAILED
libdvdnav: Unable to find home directorylibdvdnav: DVD disk reports itself with Region mask 0x00000000.
Regions: 1 2 3 4 5 6 7 8
libdvdread: Encrypted DVD support unavailable.
libdvdread: Device (null) inaccessible, CSS authentication not available.

libdvdnav: Language 'en' not found, using '��' instead
libdvdnav: Menu Languages available: ��

Handbrake: x264 [warning]: --psnr used with psy on: results will be invalid!
x264 [warning]: --tune psnr should be used if attempting to benchmark psnr!

Blender:BLF_lang_init: 'locale' data path for translations not found, continuing

Some of these are clearly non-issues; the program just tries to first do something that it can't and then moves on.
However, I'm still wondering about that Handbrake warning... In any case, narrowing the problem down would be
easier if the test would let the user know when the mismatch occurs, and what the mismatch is. Take Prime95 for
example: If there is an error, the user can easily see which worker encountered the error, which test caused the
error and what the error was. Now I'll just have to keep on taking shots in the dark...

[Morgan1952]

The first thing I noticed is that you listed that you have 16 G total Ram and set your preset to 16G. Read the last 3 lines.
In the Real bench notes it states the following.
Please Note: At least 3GB of space should be available in the drive you have extracted RealBench to. Running the Stress Test without a Pagefile is not
advised if you select a preset that is close to the amount of your physical RAM. This will cause system errors.
Your preset for ram may be to high.
I may be wrong too.

[PetrolHead]

Ah yes, I forgot to mention that I have a 16 GB pagefile and 20+ GB of space on top of that, so at least these two things
shouldn't be a problem. However, I did mention at the end of my first post that running the test with 8 GB of RAM makes
no difference. I might try running it with just 4 GB of RAM at some point, but I wouldn't expect it to make a difference.
To recap how I see this:

Prime95 stable with 16 GB of RAM -> Not a heat or a voltage issue, as Prime95 is more demanding than RealBench.
Prime95 16 GB + Unigine Heaven stable -> Stressing GPU, CPU and RAM at the same time not an issue as such.
Windows Memory Diagnostic Tool, MemTest86 report no memory errors -> Unlikely a memory module related issue.
y-cruncher multi-threaded, 2.5 billion decimal places (10.8 GB of RAM) and no errors -> Should not be an issue related to
RAM and multiprocessing.
SuperPi 32M no errors -> Single-threaded performance should be stable (or, at the very least, not consistently unstable).
A number of benchmarks - including RealBench - run without issues -> The whole system very much benchmark stable.

In my opinion this only leaves two easy alternatives: A software issue or an issue with the GPU. AFAIK GPUs can produce
artefacts well before they result in graphical glitches, so maybe the stress test is asking something of my (used) GPU that
it has trouble with. But would these artefacts be so consistent at stock speeds that every cycle fails like clockwork? A
software glitch would seem more likely, especially since the version is already a year old and the GUI clearly hasn't
been tested on a Win 8.1 64-bit and a resolution of 1080p.

[Nodens]

Ok let me shed some light here:

a) This:

Handbrake: x264 [warning]: --psnr used with psy on: results will be invalid!
x264 [warning]: --tune psnr should be used if attempting to benchmark psnr!

Is harmless and entirely unrelated to your issue. It has to do with the handbrake settings I'm using and they're image quality related. Forget all about it as it's a warning for a specific reason that's entirely irrelevant.

b) This:

error opening C:/.../RealBench_v2.41/RealBench/Video/DVD/BDMV/BACKUP/index.bdmv
nav_get_title_list(C:/.../RealBench_v2.41/RealBench/Video/DVD) failed

libdvdread: Encrypted DVD support unavailable.
libdvdread: Device (null) inaccessible, CSS authentication not available.
NAME OPEN FAILED
libdvdnav: Unable to find home directorylibdvdnav: DVD disk reports itself with Region mask 0x00000000.
Regions: 1 2 3 4 5 6 7 8
libdvdread: Encrypted DVD support unavailable.
libdvdread: Device (null) inaccessible, CSS authentication not available.

libdvdnav: Language 'en' not found, using '��' instead
libdvdnav: Menu Languages available: ��

Is also entirely unrelated and harmless. It's just the default behaviour of handrake that checks if the input is a dvd. It's not.


Now to your actual issue:
My bet would be on your power supply. RB's stress test is very different from the rest. It overloads ALL subsystems, CPU/Cache/GPU (all of them)/RAM, Drive subsystems(I/O)/Bus. This means that while running the stress test the power consumption of your system is through the roof and EVERY component is very stressed. Since this happens on stock it's for sure a hardware failure. As I said my bet is on the PSU not supplying enough juice or not supplying clean juice. The error in itself, means that a certain file that is being written on every pass does not contain the data it should. Meaning there is data corruption on your system FOR SURE, while the ST is running. If it's not the PSU that's causing this it can be any number of things with the CPU and board being the main suspects. It is quite possible that the issue manifests only on when the PCIe bus is stressed so much.. or whatever. It's really hard to diagnose without testing replacement parts that you know they work properly.
Make no mistake though, there is an issue. The file gets corrupted for sure.

PS Also Windows memory diagnostic is largely useless. Use only Memtest86+ for RAM.

[PetrolHead]

Thank you for the clarifications, Nodens!

My bet would be on your power supply. RB's stress test is very different from the rest. It overloads ALL
subsystems, CPU/Cache/GPU (all of them)/RAM, Drive subsystems(I/O)/Bus. This means that while running the
stress test the power consumption of your system is through the roof and EVERY component is very stressed.
Since this happens on stock it's for sure a hardware failure. As I said my bet is on the PSU not supplying enough
juice or not supplying clean juice.

My PSU is a 650W unit, so it's nowehere near it's limits with my hardware. Basically a good quality 400W PSU
should be enough to run all components at full load, so I should have more than enough headroom to run
anything I can think of. Also, Tom's Hardware lists the CM VS Series as a "Tier 2", which means that unless it's
broken there shouldn't be any issues with the cleanliness of juice either. I'm not ruling the PSU out totally, but
it's probably one of the better components in my system. Maybe it's just that the VRM's on the motherboard are
not up to the task when running hot? After all, this board has only a 4+1 power phase design. Running the
stress test again once I get a top-down cooler for the CPU might provide some answers...

The error in itself, means that a certain file that is being written on every pass does not contain the
data it should. Meaning there is data corruption on your system FOR SURE, while the ST is running. If it's not
the PSU that's causing this it can be any number of things with the CPU and board being the main suspects.
It is quite possible that the issue manifests only on when the PCIe bus is stressed so much.. or whatever. It's
really hard to diagnose without testing replacement parts that you know they work properly. Make no mistake
though, there is an issue. The file gets corrupted for sure.

I'm not doubting there's a mismatch. I'm only suspecting that it might be a software/firmware issue. There's
no way this software has been tested on all possible hardware and software combinations to ensure there are
no compatibility issues with the code.

In any case, I'll try to see whether I can use a combination of other stress tests to simulate your description
of what RB ST does.

PS Also Windows memory diagnostic is largely useless. Use only Memtest86+ for RAM.

MemTest86+ is not UEFI compatible and is basically obsolete software, as it's not really updated at the moment.
I've run a couple of passes of MemTest86 and it hasn't encountered any errors so far, but I've yet to do four
passes (or more), so there's still a chance it might.

[Nodens]

My PSU is a 650W unit, so it's nowehere near it's limits with my hardware. Basically a good quality 400W PSU
should be enough to run all components at full load, so I should have more than enough headroom to run
anything I can think of. Also, Tom's Hardware lists the CM VS Series as a "Tier 2", which means that unless it's
broken there shouldn't be any issues with the cleanliness of juice either. I'm not ruling the PSU out totally, but
it's probably one of the better components in my system. Maybe it's just that the VRM's on the motherboard are
not up to the task when running hot? After all, this board has only a 4+1 power phase design. Running the
stress test again once I get a top-down cooler for the CPU might provide some answers...

No a 400W would not be able to handle your components at full load. During load transitions there's additional power
draw, above the spec. But even if there was not it's not a good idea to run any PSU long term above 60-70% of its output.
In any case, it doesn't matter what TM lists or whatever reviews. If they PSU is faulty then it's faulty. Also you will find
no PSU sample out there that delivers exactly the same power as the next sample of the same model. There are fluctuations.

I'm not doubting there's a mismatch. I'm only suspecting that it might be a software/firmware issue. There's
no way this software has been tested on all possible hardware and software combinations to ensure there are
no compatibility issues with the code.

No you can forget this entirely. There is no software issue for SURE. The mismatch you are getting is from Blender's
scene render. No matter how many times you render the scene the output jpeg will always be identical UNLESS,
there's corruption somewhere in the CPU,Cache,RAM, BUS or GPU. Have in mind that Blender is a software used by
millions allover the world. But in any case there is no possibility of a software issue whatsoever. It's not technically possible.
Lastly the specific CPU/MB combo has been tested already. Not that it matters, for the reasons I already explained.

In any case, I'll try to see whether I can use a combination of other stress tests to simulate your description
of what RB ST does.

You will not be able to simulate the load of RB's ST no matter what combinations of other stress test you try.

MemTest86+ is not UEFI compatible and is basically obsolete software, as it's not really updated at the moment.
I've run a couple of passes of MemTest86 and it hasn't encountered any errors so far, but I've yet to do four
passes (or more), so there's still a chance it might.

Sorry, I meant to say MemTest86.. the + version is an old habit from some time ago in this forum heh. Still UEFI has nothing to do with MemTest86/+ apart from the ability to boot the image with CSM turned off.

EDIT: You can try the AIDA64 stress test. It's the only one that comes close although still synthetic.

[PetrolHead]

No a 400W would not be able to handle your components at full load.

In theory it should be, at least according to PSU manufacturers. The estimated power consumption for my
hardware is somewhere around 350 W if I remember correctly and the suggestions I got were max 450 W.
Even assuming PSU makers were _very_ optimistic, 650 W should be more than enough - even accounting
for the variations between different units (which should not be drastic in quality PSUs).

But even if there was not it's not a good idea to run any PSU long term above 60-70% of its output.

Yet it shouldn't be run much below 50% either, since that's where PSUs are generally most efficient. This is why its
usually better to spend on a quality PSU with a 600-750 W output than go for a 1000+ W unit - unless of course the
system has something like an FX-9xxxx and two or more GPUs.

Regarding GPUs, you also mentioned that it's a possible reason for the mismatch. As graphical bugs are just about
the only bugs I've encountered, to me it seems the most likely piece of my hardware that could cause the error. It's
just hard to know whether the bugs I've seen are due to software (either game or driver related) or actual hardware
issues. I got the GPU used, so it's not like I installed it fresh from the box.

In any case, it doesn't matter what TM lists or whatever reviews. If they PSU is faulty then it's faulty.

Sure, but then again there's still little reason to assume my PSU is faulty.

Have in mind that Blender is a software used by millions allover the world. But in any case there is no
possibility of a software issue whatsoever. It's not technically possible.

I find your faith in faultless code amusing. The larger and more complicated a software is, the more likely it
will contain bugs. A list of Blender's current (known) bugs can be found at:

https://developer.blender.org/maniph...ct/2/type/Bug/

You will not be able to simulate the load of RB's ST no matter what combinations of other stress test
you try.

A very brave statement. It's not like RB's ST is a magical combination of operations that pushes the system beyond
what is possible to reach with anything else. Then again, if it was, it wouldn't really matter if as much if a system fails
a RB ST, since it could still be stable and issue-free in _everything_ else. While it is correct that it'll be hard to load
the system similarly to RB's ST, I decided to try another way of pushing the system to its limits. This is what I ran
simultaneosly:

-Prime95, 6 workers & small FFTs (stresses CPU and cache)
-y-cruncher with 6 threads and calculating 3 000 000 000 digits of Pi (stresses RAM)
-Unigine Heaven Extreme (stresses GPU)
-MSI Kombustor 3 OpenCL Julia4D (GL3) (stresses GPU)
-SiSoftware Sandra burn-in test (continuous SSD benchmark, stresses SSD)
(-HWMonitor + Task Manager + Resource Monitor for checking the system's state)
(-Firefox, Steam, anti-virus software etc.)

It took a bit more than half an hour to finish the Pi calculation. In the end the digits checked out and Prime95
didn't encounter any errors. Socket temp reached 69 C, package temp reached 53 C, SSD temp reached 41 C
and GPU temp reached 59 C. As far as temps go, this was just about the hardest use my computer has seen,
RB's ST included. Of course, if the GPU is the source of the error in RB's ST then this error could easily go
unnoticed in such a test, as not all artefacts can be seen by the naked eye.

EDIT: You can try the AIDA64 stress test. It's the only one that comes close although still synthetic.

Thanks for the tip. I have run it without the GPU stress test without issues, but I'll check the GPU box as well and see
what happens.

Btw, is there a stress test that would only test the GPU with Blender (or something similar) so that it compares the
resulting picture with a picture that is known to be correct down to every pixel? All the GPU tests I know of just rely
on instabilities leading to visible errors or worse, which is already quite far into the unstable territory.

Edit: Of course the RB's ST does this, but it also does other things, which makes it harder to isolate the issue.

[Nodens]

You are taking some of my words entirely out of context. Or you don't understand some things. Several things.

In theory it should be, at least according to PSU manufacturers. The estimated power consumption for my
hardware is somewhere around 350 W if I remember correctly and the suggestions I got were max 450 W.
Even assuming PSU makers were _very_ optimistic, 650 W should be more than enough - even accounting
for the variations between different units (which should not be drastic in quality PSUs).

a) All devices draw more power than their specification on initialization. For example a mechanical hard drive that is rated at max 10W or read/write can draw up to 35W when it gets first powered on/spins up. This is why hardware RAID controllers have a feature called staggered spin-up. What it does is spin up the drives in batches in order to not overload the PSUs. Also devices spike their power draw when they go from idle to load. This is a scientific fact. So if a system is rated for 350W, using 400W PSU is recipe for disaster. This is what I meant. I never said your 650W PSU was not enough. I was merely giving you some information regarding the 400W PSU statement.

b) When I said fluctuations, I did not mean in wattage. Each sample of PSU is different than the next even if they are of the exact same model and batch. Like each CPU sample is different from one another. You may have a unit deliver 12.05V+-0.1 on the V12 rail and another identical sample deliver 11.85V+-0.8. Without this slight undervoltage meaning that the unit is faulty. Still on extreme cases and with picky hardware it can be enough to cause issues.

Yet it shouldn't be run much below 50% either, since that's where PSUs are generally most efficient. This is why its
usually better to spend on a quality PSU with a 600-750 W output than go for a 1000+ W unit - unless of course the
system has something like an FX-9xxxx and two or more GPUs.

Actually this is wrong. You can operate a PSU lower than 50% with no issue whatsoever. It's when you get close to the specification output that things get messy for 3 main reasons:
a) The one mentioned above.
b) PSUs degrade over time and their output gets reduced. The closer you are to the output limit the more prone you are to get errors over time.
c) PSUs operating near their limit, always provide dirtier power.

Regarding GPUs, you also mentioned that it's a possible reason for the mismatch. As graphical bugs are just about the only bugs I've encountered, to me it seems the most likely piece of my hardware that could cause the error. It's just hard to know whether the bugs I've seen are due to software (either game or driver related) or actual hardware issues. I got the GPU used, so it's not like I installed it fresh from the box.

What kind of graphical bugs? You neglected to mention this. If the GPU is faulty then it could be your culprit.

Sure, but then again there's still little reason to assume my PSU is faulty.

You asked what could cause the issue. From my experience what you described points 90% to the PSU. Then again you neglected to mention you have GPU issues. With this new information I'd say it's 50/50.

I find your faith in faultless code amusing. The larger and more complicated a software is, the more likely it
will contain bugs. A list of Blender's current (known) bugs can be found at:

https://developer.blender.org/maniph...ct/2/type/Bug/

I have no faith in faultless code. And I find your statement insulting. I am a professional programmer with specialization in reverse engineering. I know exactly what software can and what it can't do. I do not have the time or the inclination to try to explain the inner workings of RB. I designed it, I know how it works. You asked for advice on what could be causing your problem and I gave it. If there was even a remote possibility of it being a software issue I would be digging in the code right now and I would have sent you a debug build already in order to produce logs for me to examine. As I have done before for cases where such a thing was technically possible.
In this case it is not. Also linking me to Blender's bugtrack, as if I am not aware of it, is childish at best.
I'm trying to help you but I can not be bothered to explain every single statement I make, specially when that explanation would take lots of pages to write and would require a certain level of technical expertise for someone to understand.

A very brave statement. It's not like RB's ST is a magical combination of operations that pushes the system beyond
what is possible to reach with anything else. Then again, if it was, it wouldn't really matter if as much if a system fails
a RB ST, since it could still be stable and issue-free in _everything_ else. While it is correct that it'll be hard to load
the system similarly to RB's ST, I decided to try another way of pushing the system to its limits. This is what I ran
simultaneosly:

-Prime95, 6 workers & small FFTs (stresses CPU and cache)
-y-cruncher with 6 threads and calculating 3 000 000 000 digits of Pi (stresses RAM)
-Unigine Heaven Extreme (stresses GPU)
-MSI Kombustor 3 OpenCL Julia4D (GL3) (stresses GPU)
-SiSoftware Sandra burn-in test (continuous SSD benchmark, stresses SSD)
(-HWMonitor + Task Manager + Resource Monitor for checking the system's state)
(-Firefox, Steam, anti-virus software etc.)

It took a bit more than half an hour to finish the Pi calculation. In the end the digits checked out and Prime95
didn't encounter any errors. Socket temp reached 69 C, package temp reached 53 C, SSD temp reached 41 C
and GPU temp reached 59 C. As far as temps go, this was just about the hardest use my computer has seen,
RB's ST included. Of course, if the GPU is the source of the error in RB's ST then this error could easily go
unnoticed in such a test, as not all artefacts can be seen by the naked eye.

It is not a brave statement. It is how it works. How it was designed to work. You running together all of the above does not even come close to what RB's ST is doing. First of all Prime95 and y-cruncher are synthetic. Meaning that they just repeat a single algorithm. It's nowhere close to a real life scenario. Not to mention that Prime95's FFT algo fits entirely into CPU cache. But it's not just that, it's also the fact that you're just running separate applications at the same time. It's not the same thing as what RB's ST is doing when things like thread counts, management and scheduling are taken into consideration and idle/load cycles happen on specific relations with everything else running in the background. There's a lot more going on that I can't explain. I can't be bothered to nor do I want to, for other reasons. Just running a bunch of benchmarks is NOT going to simulate what RB is doing nor is going to check for the 20 things that RB is checking while doing its thing.
Seriously, I am very busy. I do not have the time or inclination to try to explain any better than this.

Thanks for the tip. I have run it without the GPU stress test without issues, but I'll check the GPU box as well and see
what happens.

That test is the closest (with everything enabled) but it's still far from RB.

Btw, is there a stress test that would only test the GPU with Blender (or something similar) so that it compares the
resulting picture with a picture that is known to be correct down to every pixel? All the GPU tests I know of just rely
on instabilities leading to visible errors or worse, which is already quite far into the unstable territory.

Edit: Of course the RB's ST does this, but it also does other things, which makes it harder to isolate the issue.

Thing is that doing that solo will most likely not produce your problem. In any case if you want to try, do this:

1) Go to the blender subdirectory in RB and open a command prompt
2) Run "blender -b bmps.blend -F JPEG -o out -t 0 -f 1"
3) Once it's done you will have a out0001.jpg in that directory.
4) Open it with the hashing tool of your choice and check if the SHA-1 hash is "06170F1A3AB84B173B9A4A0CE600945A7F94B7A2"


But seriously if you want help, stop questioning my every sentence. For the last time I don't have the time or inclination to explain every statement in 5 paragraphs each over multiple posts. Either take my advice/help or don't.

[PetrolHead]

First of all, don't think I don't appreciate you taking the time to help. I do. Also, it was not my intension to insult you
in any way, so you have my apologies if you were offended. I misunderstood some of your comments and have apparently
written too short comments to be fully understood myself. So, my thanks, apologies and I'll now try to keep the
discussion more on topic.

What kind of graphical bugs? You neglected to mention this. If the GPU is faulty then it could be your
culprit.

My bad, I only remembered them when you mentioned the GPU. It's a bit hard to explain without a screenshot,
but I've encountered these bugs in DotA 2:

-Some localized flickering, for example around the Dire ancient or the Dire team logo (edit: the one that's
on the ground in front of the base. This happens only occasionally.
-A sort of opaque color spectrum triangle (or line) above the icon that shows which commentator
is speaking. These are also only occasional.

These appeared after the Reborn update, so I assumed it's software based, since the update was released unfinished.
This is why I forgot to mention them earlier. Then again, it may well be that the new engine they're using is
more sensitive to errors than the old one. Actually, last night also Firefox was (for the first time AFAIK) showing
some graphical errors on the tabs at the top of the screen. I hadn't restarted the computer after installing the
newest NVidia driver and had also been running DotA 2 in the background for a couple of hours, so I didn't
think much of it. Now it of course seems like it might have been a sign of a bigger issue.

Thing is that doing that solo will most likely not produce your problem. In any case if you want to try,
do this:

1) Go to the blender subdirectory in RB and open a command prompt
2) Run "blender -b bmps.blend -F JPEG -o out -t 0 -f 1"
3) Once it's done you will have a out0001.jpg in that directory.
4) Open it with the hashing tool of your choice and check if the SHA-1 hash is
"06170F1A3AB84B173B9A4A0CE600945A7F94B7A2"

I don't know if this is the same problem as with the RB's ST, but the above at least produced a problem. The
SHA-1 hash I get is:

"B057ABE9F6B48CA1C35316B1145064A23F8FDB13"

This is clearly not the hash it should be. I ran the test again and the resulting file had the same hash the first
one had. So, the error at least seems consistent. Would I be correct to assume that this means the GPU is most likely
the reason for my RB related issues?