Oliver Song

New Member
Joined
Dec 22, 2011
Messages
2
Hi guys,

I recently got a Kensington HyperX SH100S3B/120G SSD. I've been getting these stange BSODs. It doesn't happen during any particular kind of activity, usually it's just browsing the web or writing documents or something.

Every time the BSODs happen, for some reason the boot order switches from the SSD to my backup drive, and I have to go into the bios and change it. But other than that, my hard drive seems to be perfectly fine functioning afterwards...what's causing this??

Attached dump file. Any clues as to what's going on?

All my components are pretty new, so I don't think hardware failure is very likely here. I've thought maybe I should update my bios? But I'm not sure honestly. My mobo is [FONT=Verdana, Helvetica, sans-serif]H67MA-E35-B3 LGA 1155 H67 mATX Intel Motherboard.[/FONT]

Thanks so much for your time.

Link Removed
 


Solution
You may be bitten with the Sandforce BSOD bug. Your drive, A Kingston (not Kensington) HyperX SSD uses a Sandforce SF2281 controller with a known problem that can cause your PC to BSOD, after which the boot drive (the SSD has to be the boot drive for this error) becomes inaccessible until you power cycle the box.

I've had the same problem since I built my new box in September. Just upgraded the firmware in my drives yesterday and am now watching to see how long I go before another BSOD (like, hopefully, never).

See this article that talks about it:
Link Removed

Go to Kingston's support page to look for a firmware upgrade. It needs to be version 3.3.2 (or newer). Also note that if your SATA controller is in IDE mode (as...
Hello and welcome to the forums.
I've been getting these stange BSODs
Plural denotes more than one, yet you have only attached a single dump file that is over a week old.
DUMP:
Code:
.......
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1A, {41201, fffff680000327f0, f07000003a539867, fffffa800b3488f0}

Probably caused by : ntkrnlmp.exe ( nt! ?? ::FNODOBFM::`string'+14382 )

Followup: MachineOwner
---------

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************
MEMORY_MANAGEMENT (1a)
    # Any other values for parameter 1 must be individually examined.
Arguments:
Arg1: 0000000000041201, The subtype of the bugcheck.
Arg2: fffff680000327f0
Arg3: f07000003a539867
Arg4: fffffa800b3488f0
Debugging Details:
------------------
BUGCHECK_STR:  0x1a_41201
CUSTOMER_CRASH_COUNT:  1
DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT
PROCESS_NAME:  chrome.exe
CURRENT_IRQL:  0
LAST_CONTROL_TRANSFER:  from fffff800033352de to fffff800032d8c40
STACK_TEXT:  
fffff880`0aaa4878 fffff800`033352de : 00000000`0000001a 00000000`00041201 fffff680`000327f0 f0700000`3a539867 : nt!KeBugCheckEx
fffff880`0aaa4880 fffff800`032a4831 : 00000000`00000000 00000000`00000000 00000000`00000000 f0700000`3a539867 : nt! ?? ::FNODOBFM::`string'+0x14382
fffff880`0aaa48c0 fffff800`032a44ca : fffffa80`0b3488f0 fffffa80`0b4e5b30 fffffa80`0b4e5b30 00000000`064fe000 : nt!MiQueryAddressState+0x2b1
fffff880`0aaa4910 fffff800`035b3724 : fffff880`00000004 00000000`064ff000 fffffa80`0b3488f0 00000000`00000001 : nt!MiQueryAddressSpan+0xaa
fffff880`0aaa4980 fffff800`032d7ed3 : ffffffff`ffffffff fffffa80`09734b60 00000000`747e2450 00000000`0024de68 : nt!NtQueryVirtualMemory+0x382
fffff880`0aaa4a70 00000000`7703154a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0024de48 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7703154a
STACK_COMMAND:  kb
FOLLOWUP_IP: 
nt! ?? ::FNODOBFM::`string'+14382
fffff800`033352de cc              int     3
SYMBOL_STACK_INDEX:  1
SYMBOL_NAME:  nt! ?? ::FNODOBFM::`string'+14382
FOLLOWUP_NAME:  MachineOwner
MODULE_NAME: nt
IMAGE_NAME:  ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP:  4e02aaa3
FAILURE_BUCKET_ID:  X64_0x1a_41201_nt!_??_::FNODOBFM::_string_+14382
BUCKET_ID:  X64_0x1a_41201_nt!_??_::FNODOBFM::_string_+14382
Followup: MachineOwner
Not very informative, there is a mention of Virtual Memory in the stack trace and this type of BSOD might suggest some issues with your hard drive. I'm no SSD expert but I do know that there are a few pre and post tweaks that are generally accepted as best practice regarding a Windows 7 installed hosted on an SSD drive. You might try Google or perhaps someone else may have some tips to contribute.
You do have a couple pre-Windows7 RTM drivers which you should probably take care of
LHidFilt.Sys 4/11/2007 and LMouFilt.Sys 4/11/2007 Both associated with Logitech Human Interface Devices. Check here Link Removed
GEARAspiWDM.sys 5/18/2009 update from here Driver updates - GEAR Software
Additionally;
Please read the first post in this sticky thread here Link Removed
Do your best to accumulate the data required.
Run the SF Diagnostic tool (download and right click the executable and choose run as administrator)
Download and run CPUz. Use the Windows snipping tool to gather images from all tabs including all slots populated with memory under the SPD tab.
Likewise RAMMon. Export the html report, put everything into a desktop folder that you've created for this purpose, zip it up and attach it to your next post (right click it and choose send to, compressed (zipped) folder.
Good luck
Randy
 


You may be bitten with the Sandforce BSOD bug. Your drive, A Kingston (not Kensington) HyperX SSD uses a Sandforce SF2281 controller with a known problem that can cause your PC to BSOD, after which the boot drive (the SSD has to be the boot drive for this error) becomes inaccessible until you power cycle the box.

I've had the same problem since I built my new box in September. Just upgraded the firmware in my drives yesterday and am now watching to see how long I go before another BSOD (like, hopefully, never).

See this article that talks about it:
Link Removed

Go to Kingston's support page to look for a firmware upgrade. It needs to be version 3.3.2 (or newer). Also note that if your SATA controller is in IDE mode (as opposed to AHCI mode), the firmware updater might fool you into believing it has updated the firmware, but have actually done nothing. If after firmware upgrade, you do a subsequent drive discovery with the tool, and the firmware version it shows for your SSD hasn't changed to the new version, bang - you should check your BIOS settings to see if your SATA controller is in IDE mode.

Note: I was unable to get my PC to boot after changing from IDE mode to AHCI mode. On another forum, a wise sage told me that there is a fix for this too, and referred me to this article: Error message when you start a Windows 7 or Windows Vista-based computer after you change the SATA mode of the boot drive: "STOP 0x0000007B INACCESSABLE_BOOT_DEVICE"

Good luck!
 


Solution
Back
Top