• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Issue with Samsung 840 Pro (China) SSD's?

faxanadu

Junior Member
For the past month I have been dealing with the most perplexing BSOD at work. I think I have boiled it down to this model of hard disk having a flaw in the way it writes and frees up HDD space.

Basically, we have machines that come in that are mostly identical that we reimage. I developed a Windows 7 image for these machines. The machines I am having an issue with have two 840 Pro's in mirrored RAID. Below causes a BSOD on every machine so far:

1. Boot using our version of Ultimate Boot CD for Windows.
2. Image with Ghost32 11.5.1 using the -IB switch.
3. Reboot the machine.
4. Do the OOBE.
5. Activate Windows 7
6. Run latest updates (since October).
7. Reboot.
8. BSOD.

Here is the most interesting part:

If i repeat the exact same steps. It does not blue screen on the 2nd/3rd/4th... etc. reimage. It only does it the first time.

I spent a few weeks finding a quick fix to the BSOD. We are running Windows 7 x64 and one of the catalog files was getting corrupt/unsigned. This same file is the issue each and every time with these drives following the above steps.

*If i repeat the process above but swap to intel drives i have no problems.
*If i zero the drives before imaging i have no problems.
*If i secure erase the drives before imaging i have no problems.

I finally did a raw copy of a set of drives (with the OEM load) before tinkering with the issue so i would have a baseline to work with. I somewhat expected not to see a blue screen if i did a raw copy back to drives i already used (i guess i assumed the drive wont be written to the same way twice). However, sure enough, if i applied a raw copy to an already used drive and then followed the steps above the machine would BSOD.

At this point my logic says it is most likely the drive itself. Yet, i considered it could be Ghost or some strange two variable problem.

My coworker thinks it is at least partly due to my image. If i understand his logic, he believes that it is improbable to think that an image being applied the exact same way each time, and across multiple sets of drives would have the exact same issue unless the image itself was corrupt.

I can find no other logical explanation. Therefore, i think that the opposite is true. The image is being written the same way each time and therefore is corrupting the same way each time. After spending hours learning about SSD... they operate completely different than spindle drives. So i think it is likely that it is corrupting the same way each time.

I know the EVO's had issues. Is it possible these do as well? Thoughts? Theories?
 
Last edited:
Very Interesting - Indeed:

I use a single 840 Pro 256MB as a Boot Drive on the MB SATA controller set RAID Mode NOT as a Member of a an Array - Therefore in ACHI Mode.

I have the 840 Pro Partitioned as follows Active Primary DOS 1GB FAT32 for the D : Boot Drive and the rest of the SSD volume as Extended DOS with 2 Logical Partitions as a 60GB NTFS C: Drive for Win7 64-Bit and the remainder as a 177GB NTFS F: GAMES Drive. E: Drive is a RAMDisk to alleviate writes to the SSD and handle App Buffering.

Using GHOST SERVER v8 Corp_Bld 8.0.0.984, I DOS Boot and do all my Imaging and Dumping using DOS GHOST.EXE which I copy from the installation directory to a Dos Bootable 32GB FAT32 Disk (say on a USB Flash stick) where I store Split 700Mb Images (ghost.exe -split=701 a habit I've carried over from the CD days) to Over-Write the Partitions on the 840 Pro and have NOT had BSOD's on the ReBoot even after Updating. I only use Ghost32.exe to Verify my GHO Images.

I assume your Image has the Intel SATA RAID Driver on board and can't see why Updating, unless for a bad MS Update, would cause a SATA Driver Issue when the procedure works on the 2nd attempt.

Have you attempted to dump an Image originally Copied from the 840 Pro MIRRORED RAID. I have dumped GHOST Images originally copied from HDD's to SSD and visa verse and have you attempted a SYS-Prep Image onto the 840 Pro's in RAID Mirror? I know it would take somewhat longer as the Image would run thru the Windows Installation SetUp upon Booting but would be guaranteed to boot on about any hardware.

I imagine your on a Network and use Ghost Server to Migrate Images.

Samsung Magician is about useless on their SSD's when mounted on a SATA Controller enable as RAID and know the TRIM does work as long as the SSD is not part of an ARRAY - Verified by running "trimcheck-0.4.exe". I wonder if TRIM is working on them 840 Pro's Mirrored RAID - If not - It may possibly be an issue?

Like you, I also suspect it has something to do with how Samsung designs their SSD Controller 's for being a Member of an RAID Array and requires a Firmware Update.

Something very strange there - I don't know if you would get any answers from Samsung Support.

PS: I know this really does not solve the issue but have you tried shutting down and pulling the plug on the PSU before rebooting the Image or after Updating.
 
Last edited:
I have not tried applying the image with a standalone drive. Although that would be a good test to narrow down whether TRIM doesn't work in RAID 1 on samsung SSD's...and... if that is infact the problem.

Right now i am applying a raw image copy "ghost32.exe -IR" to a RAID 1 set that i will transfer to a different computer (different hardware) to see if my steps cause a blue screen on that machine. If it does, then it surely has to be the way the samsung drives garbage collect/trim/evenly wear the drive.

Another thing to point out. I think it is sheer coincidence that i noticed this problem. Windows 7 x64 will not boot when it believes its core driver files are unsigned (hence my BSOD). I think it is just by chance that the drive is corrupting a file that windows needs. I think 99/100 times it would just be some random useless file that isn't so dependent. You could say, i just got unlucky... or lucky enough to see a problem.

One thing im really curious about is. If the SSD prefers writing to clean flash memory blocks then, it is likely when im imaging on top of the factory image... large chunks of that factory image remain on the drive. Add to the fact that the samsungs in RAID 1 may not be able to TRIM... how then does the SSD know which blocks to keep/clean? Especially, if the factory image is also windows 7 x64 pre OOBE (out of box experience)? Is it possibly thinking some old blocks (on the factory image) are part of my image?
 
I've done 2 Win7 installs lately and both of them BSOD'ed the same way during/after Windows Updates. I'm pretty sure it was one of the updates that did it as there have been 0 issues since. Maybe you are hitting the same thing somehow.
 
I've done 2 Win7 installs lately and both of them BSOD'ed the same way during/after Windows Updates. I'm pretty sure it was one of the updates that did it as there have been 0 issues since. Maybe you are hitting the same thing somehow.

Maybe. But if i reimage the machine and follow the exact same steps... the updates the second time dont cause a blue screen. I've done this dozens of times. It only happens the first time i image the drive when the factory load is on it.
 
There is positive evidence that MS Update KB3004394 dated Dec 10th which has been removed from their Update Site can cause BSOD issues but mostly related to GPU Driver installations. I take it you assign the STD VGA Driver in your Image for safety.

I still think it's a Samsung 840 Pro firmware issue when the SSD's are mounted in SATA RAID Mode and a Member of an Array.
 
There is positive evidence that MS Update KB3004394 dated Dec 10th which has been removed from their Update Site can cause BSOD issues but mostly related to GPU Driver installations. I take it you assign the STD VGA Driver in your Image for safety.

I still think it's a Samsung 840 Pro firmware issue when the SSD's are mounted in SATA RAID Mode and a Member of an Array.

My blue screen was happening before december updates.

Can you elaborate on the STD VGA driver?
 
From the the OP's description of the problem, I still believe it's either a Samsung vNand Controller or Firmware issue when their SSD's are mounted in SATA Raid and a member of an array.

I gave the OP further Tests but I believe he/she has done their homework and should present it to Samsung and TRIM may have a lot to do with it.

If someone is willing to give me another Samsung 840 256MB Pro SSD - I'll play with and report - LOL
 
Last edited:
I'm trying my test on a completely different machine right now. It has the same RAID controller. Curious to see if it blue screens.

After that i will try my image on a drive without RAID 1 and see what happens. I think this will say a lot if it doesn't blue screen outside a RAID setup.

Is there any program that can take a bit-by-bit snap shot of a flash drive and compare it with another? That would be very useful in determining if data is being written the same way to each NAND block.
 
Your thoughts on this. If the zeros below represent the factory image (20GB):

00000000

Then i add my image(20GB) shown in ones:

00000000 111111111

And the twos represent the left over drive space (200+ GB drive):

00000000 111111111 222222222222222222222222222222222222

How does garbage collection know that the factory image is now useless information? That image was never booted so no TRIM commands were sent for any of the files.

Furthermore, since SSD's don't overwrite like spindle drives is my representation correct? If there is free space wont the SSD will just write my information to space after instead of freeing up the factory image space and writing there first?

Is there any documentation on this processes?
 
Once you add your new image with a new file allocation table, the 0's would also be 2's and the drive would proceed with however it normally would.
 
What BSOD are you getting?

Eg. 0x0000007e

Regarding the 840 PRO, I've installed approximately 20-30 of them, no weird problems. Please note that I'm not saying "therefore it cannot be at fault" or anything stupid like that, just that I think the drives themselves are decent. I haven't set any up in RAID, but TBH I can't see why setting them up in RAID would make any difference for how the host talks to them.
 
Last edited:
Once you add your new image with a new file allocation table, the 0's would also be 2's and the drive would proceed with however it normally would.

So you're saying that a new allocation table should signal to the SSD to erase all the 0's (NAND flash blocks) from the previous image?
 
What BSOD are you getting?

Eg. 0x0000007e

Regarding the 840 PRO, I've installed approximately 20-30 of them, no weird problems. Please note that I'm not saying "therefore it cannot be at fault" or anything stupid like that, just that I think the drives themselves are decent. I haven't set any up in RAID, but TBH I can't see why setting them up in RAID would make any difference for how the host talks to them.

STOP: c000021a {Fatal System Error}

Verification of a KnownDLL failed.

0xc0000428 (0x002f9960 0x00000000)


At the beginning of the issue i tried countless times to get a memory dump. It would never do it. That's why it took me forever to figure out what file was getting corrupt.
 
UPDATE:

I tried my steps on a completely different computer system. Only components that are specifically the same are the SSD's, matrox video cards, and what looks to be the intel rapid storage controller.

Sure enough the blue screen happened.


Next i'm going to try a single drive with no RAID.


In reference to the post above. Up until recently drives support TRIM except in a RAID setup. I think, intel now has firmware to let their SSD's support TRIM in RAID 1 (don't quote me on that - however it might explain why i have no issue with intel drives thus far). I'm guessing the samsung SSD's do not support TRIM in a RAID 1 setup yet.


So my next test without RAID.... the back of my mind thinks that i wont see a BSOD.
 
So you're saying that a new allocation table should signal to the SSD to erase all the 0's (NAND flash blocks) from the previous image?

That would depend on what the controller does on the drive. It's not a TRIM command because you aren't deleting the files, but you are effectively marking them as "not used" blocks.

BTW yes TRIM works in RAID at least with the latest RST drivers that I'm using.
 
I'm guessing the samsung SSD's do not support TRIM in a RAID 1 setup yet.
Don't Quote me = Firmware?

Is it a Table Allocation or just a Fuckup with our Images.

I can't say because I don't run Samsung 840 Pro's in Raid.

Just a theory from my experiences and hope my input helps.
 
Last edited:
Back
Top