BSOD problem avoids solution even after 8 months (26/01/2014 new update!)

with error like that it can be a bad stick of ram,a bad bios code in the mb causing a timing issues with the cpu/ram. the ram voltage to low with four sticks or ram or your using ram that untested on that mb and it wont fail memtest but the mb having issues. the cpu could have spot of bad cache that showns up when loaded. the power supply not holding within atx spec when loaded. start with updating the bios on the mb and check that your running the newest firmware on the ssd. in the bios set your ram to 1333 stock speed and set dram voltage to 1.65v to rule out low ram voltage.
if the system bsod cut the ram to 16g. if the system still bsod take out one gpu see if it a power issue. if it a virus that still on your system did you on the ssd ever do a secure erase to make sure the drive was blank??

As said above if you have done a clean reinstall then it has nothing at all to do with the registry doubt it ever did. You have some faulty hardware somewhere in the mix.

anyone run cpu-z check that the mb set the ram speed right??? have you tried running the ram at 1333 speed at 9-9-9-9 timing to see if it was a timing issues?? run gpu-z to see if the pci video slots are reading the gpu right?? if you can on your mb see if you can disable the cpu cache see if the onboard cache is bad. did any of the tech's use a volt meter and see if the input and vrm voltage were holding??

notice two things i dont know if it your cpu or mb. but why is the cpu speed so low??
http://www.guru3d.com/articles_pages/amd_fx_8350_processor_review,6.html
if the cpu is running right the cpu core should be 21x and close to 4.2g unless the cpu is power saving itself and cpu-z did not pick that bug up.
the other is you have 1600 gsill aires ram the default speed is 9-9-9-9-24 at 1.5v. your not running it close to it defaulkt setting in cpu-z main page,
573 at 7-7-7-20-27.

Can I ask you, how long has the SSD been in the system and how long has the system been operating for previous to five months ago?

Can I ask you, how long has the SSD been in the system and how long has the system been operating for previous to five months ago?

Wouldn't you be better just setting the defaults for clocks and RAM.

If you can get the computer to run reliably at all, it would go a long way toward vindicating the hardware outside the CPU/RAM/Mobo inner sanctum.

But I would be surprised, given that we are in an age of individually clockable cores that there should be timing issues with reset CMOS settings.

.To be honest, the stats you gave on your apps suggests to me that the SSD may be 'dropping the ball' somewhat.

Is the rendering being done on the SSD?

Have you tried a traditional SATA drive in rhe system?

If you can install an operating system onto another HDD, then you might be able to rule the SSD out.

I'm thinking that there could be 'weak sectors' on the drive and although those bits can pass a read/write test, they may be susceptible to the fields that read/write other bits in their region.

Anyway, I'm carping on again - did you ever test a configuration of your computer without the SSD?

Day to day stuff like rendering, or installing software?

Playing a game?

The OP did indicate that he was testing with one stick of RAM and also indicated that he tried substituting the processor on his machine too.

The only device that hasn't been tested is the SSD.

How can you rule out the possibility that the SSD causes the error when it is under a load?

Especially if there is only one month's warranty on it.

I'm thinking of the situation where one process is writing to the SSD and another process is reading a different part of the drive.

Imagine that a block of data is being written by the renderer, to a disk that is being requested by another application.

The system is trying to manage a queue of requests and performance considerations demand that there should be as little idle time as possible for devices that are in a request queue.

So, data is being written and there is another application that is chomping at the bit for access to the same drive.

The system allows the renderer to finish the buffer it is writing and as soon as the renderer lets the device go, the other application is permitted access.

Assuming that the hardware controllers are the ultimate arbiters of system resources, i.e., that the motherboard drive controllers mediate and manage read/write requests between and on behalf of the apps and hardware that request them and the controller that is built into the SSD, then the following scenario is plausible.

The renderer sends a constant stream of requests to commit the buffers it is compiling in RAM to the disk.

And in the absence of any other requests, the SSD would have virtually no idle time until the renderer is finished.

Also, because there are so many of them, the requests submitted by the renderer are allocated a medium priority rating.

However, a system request might have a higher priority.

Now, suppose the user wants to install a program and let's assume that the program is on a DVD disk in order that we may minimise the list of SSD requests.

And let's not consider the extra requests that would occur because the installer will unpack onto and read files from the SSD. That way we can keep the model minimal.

So, the installer begin to run from RAM, let's say, and begins to send a stream of requests to the hardware controller, HC, which has to manage these additional requests for an already busy drive.

Now we have the situation where two streams of requests by two applications are being managed by the HC and it can allocate access to the drive in such a way as to prevent bottlenecks appearing in any part of the system.

Now suppose that the installer requests are prioritised higher than the renderer's and that the installer requests can 'muscle' their way down the queue.

Now the renderer has become the secondary task and the HC is effectively interrupting the installer process in order to service the renderer.

Okay?

It is time to consider the operation of the storage device which in a broad sense can be thought of as two discrete components; the drive controller and the memory.

The Controller.

The controller knows nothing about the system or its politics and is a fully-paid-up-union member who goes to church on Sunday. It has a job to do and it conducts its affairs with the consistency of a chain-store manager who has a schedule to keep.

Not great fun at a party.

It takes data in one door and puts data out of the same door and it is not the responsibility of the controller to ensure that the right device reads/writes the correct data.

When data comes in it is written as requested and what goes out is read as requested although the controller does deign to let the system know whether or not it is busy or ready for service.

As you can see, there is very little to go wrong here.

The Memory.

It is useful to think of memory as a vast array of identical boxes that are uniquely numbered and arranged on a 'table'.

Each box can hold one ball, a black one and a white one, a 'one' or a 'zero'.

(I was explaining this once and I was asked, 'Which one is the black one?')

There is a 'ball dispenser' of course and each time the controller sends a write signal it must specify a colour too and the dispenser will 'drop the ball of the requested colour. It is the controller's responsibility to make sure that the 'right box receives the right ball' and signals that it completed the task. And another signal reports whether or not the write was successful by reading the written bit.

In order to ensure that the data is being written to the right place, the controller must move the table about beneath the nozzle of the dispenser but must take into account the amount of time it takes for a ball to drop.

And that is why it takes longer to write data as it does to read data.

When only the renderer is writing to the disk, the table is in constant and smooth motion, balls being dropped along straight rows and columns and data is successfully written.

But when the installer pipes up, the controller has to flip the tables between two geographically separated regions, interrupting one write process to continue a different one, returning to the first one and continuing the write process, and so on.

There is one final consideration.

When the table is viewed from above, it forms a grid of squares with identical area, like boxes with the same footprint. However, the boxes vary to some extent in height. Because of this if the table is viewed along its plane, then it has the characteristic of a slightly undulating landscape.

This means that the distance between the end of the nozzle of the dispenser and the boxes is not constant. Electronically, this would equate to a slight variation in the minimum charge time for each cell.

When just the renderer is writing, the 'write_check_signal that verifies a successful write provides a reference for the timing of the drop and it is this flag that is affected by the distance of the drop. The system is governed by how long it takes for the check to complete and the controller either has to wait or generate a time out error.

Suppose that the renderer is writing to a 'low-lying region' when it is interrupted to go and write to a region located on a higher plane. If the distance of the drop changes 'drastically' then it is possible that the ball will fall into the wrong box because the timing mechanism didn't have time to compensate.

If the check for successful write is negative then the system knows that there is a fifty percent chance that a bit of data was corrupted and generates an error.

And this error would always occur at the beginning of a block-write; it would be the very first attempt to write the first bit of the block and the subsequent 'write_fail' that would cause the error.

In short, I am saying that the problem that the OP has described is in my view due to the topological properties of the memorising material of the SSD at a quantum level.

And I've waited so long to say that.

That's where I got the idea that a substitute CPU had be used in your system.

And sorry for the long post but I was actually talking to smorizio. And come on, it must make you feel quite important to think you may have a quantum topology problem. But then again, don't we all?

I had already stated it simply to you, try a SATA drive as your boot disk. Although I must say that I don't think there is anything difficult about the concept of balls being dropped into boxes. Plus, it gives one an idea of the weaknesses in a system.

By the way, I would advise you to set the output folder on your renderer to be on the SATA rather than the SSD.

Especially if you do a lot of rendering.

Oh, and being a girl does not present a handicap when interchanging computer parts.

Some girls can even drive cars.

There should be an option to set 'Safe defaults' in BIOS. Have a look at the 'key navigation guide' at the bottom of the BIOS screen.

What does F9 do? Or F11?

About the drives; I was differentiating between an SSD drive connected to the SATA bus and the traditional non-SSD SATA drive and what I was suggesting is to take out the SSD and install an operating system on a non-SSD drive.

If the problem persists then the SSD can be ruled out as the problem.

About the CPU; was that tested in another machine? (Apology accepted by the way. )

And have you tried using the O/S without the Service Pack 1 update?

Do you have USB 3.0 devices on your system? It might be worth updating their drivers. Some versions of Intel's USB 3 drivers have been known to cause problems.

Computer Drivers and updates are current and up to date.

I can't glean very much from those pictures except that they do appear to be the default settings.

When you exit BIOS, don't you get a choice to 'load defaults and exit'?

Or something similarly worded or with a similar meaning?

Also, BIOS defaults can be reset by removing the CMOS battery and, in some cases, there is a jumper on the motherboard that resets BIOS too.

Do you know if BIOS is at its defaults? If not then reset CMOS.

As far as updated drivers are concerned, that is all well and good but that does not guarantee that system buses don't get over-crowded.

Something I might experiment with is going to Device Manager and disabling unused devices to see if that helps.

I would disable the USB ports and see if that changes anything.

I would go as far as disabling audio at this stage too. Modems, Network adapters, I'd even go so far as to disable all SATA channels too, except for Channel 0.

I would try to reduce the load on the system as far as I can.

And I'm wondering: do you have any IDE devices connected? Why is SATA Mode set to IDE Mode? Is AHCI not available?

Like I say, I'd disable and remove all the bells and whistles/unnecessary devices (for the purpose of troubleshooting) and then bring them back on-line one at a time to see which one is causing the problem.

Just a suggestion.

Do you have USB 3.0 devices on your system? It might be worth updating their drivers. Some versions of Intel's USB 3 drivers have been known to cause problems.

Some operating systems, notably Windows Vista and Windows 7, do not configure themselves to load the AHCI driver upon boot if the SATA-drive controller was not in AHCI mode at the time of installation. This can cause failure to boot, with an error message, if the SATA controller is later switched to AHCI mode. For this reason, Intel recommends changing the drive controller to AHCI or RAID before installing an operating system.[1] (It may also be necessary to load chipset-specific AHCI or RAID drivers — from a USB flash drive, for example — at installation time.) [/quoemsg] I read this on Wikipedia but I'm not sure if that applies in this case or not.

The SD card reader is needed as I have to supply power to the whole bay in order to power the SSD as the only other mounting bracket I have is too small for the computer. There's 2 CD/DVD bays. The only other thing that could be considered a "Bell and whistle" is a small LED Kit that ISN'T connected to the Motherboard. It screws into the case at the back and plugs right into the PSU. A low of the 6 case fans plug into the PS directly.

I would go as far as disabling audio at this stage too. Modems, Network adapters, I'd even go so far as to disable all SATA channels too, except for Channel 0

Click to expand...

There's NO independent sound card. The audio is related to my video driver/ GPU. The Modem is in another room. even with the network adapted disabled the issue persists. Even without the driver, the issue persists. If I disable the SATA channels, then I can't boot my computer from my SSD. IDK what drives are associated with what channels.