Question : XP Pro SP3 on Dell Inspiron 9400 notebook with OCZ SSD: BSOD 0xF4 after resume from standby

Gentlemen,

I have just replaced the hard drive in this 3 year old Dell Inspiron 9400 notebook computer with a new and very quick OCZ SSD, manually configured the partition with a 1024 offset, freshly installed the OS, freshly downloaded all of the latest and greatest drivers from Dell, and applied all currently available OS updates from Msft.

The problem is that when the machine resumes from Standby, it will /reliably/ (4 out of 4 attempts) produce a BSOD 0xF4 after the power button is pressed to resume the machine from standby.  

Here's the sequence to recreate the problem:

0) Machine is booted normally into Windows, and log in to an account which has administrative privs.
1) Click on Start -> Shut Down -> Standby.
2) See display turn black, disk I/O light flashes then stops, then the power indicator light begins to flash on and off slowly.
3) Wait until the power light has made 2 slow flashes.
4) Press the power button.
5) See the Dell Bios splash screen, then disappear
6) Boom: See the BSOD 0xF4

The values reported after the STOP are:
(0x00000003, 0x865b3020, 0x865b3194, 0x805d2954)

Note that I've been in contact with OCZ before about this SSD+computer, because the previous BSOD that was produced was 0x77.  Their recommendation was to create the partition with an offset with a 64 interval, and to reflash the SSD with their modern firmware.  This was done, the OS was reinstalled as described, and now I'm getting a different BSOD code.  Another mention was a question whether the notebook computer uses a SATA2 controller (definitely compatible) or SATA1 (which may have troubles).

I've run Spinrite on the SSD, and there are lots of ECC errors being reported.  I've been in contact with Spinrite, and they chalk this up to the SSD being chatty (which they like), but since SSD's are new and magnetic disks are common, they want to stay focussed on magnetic disks.  

When the machine boots back up, the OS reports that a serious error has occurred, and asks that a problem report be submitted, which I do.  Then an attractive but somewhat generic page is displayed with common causes (Aging or failing hard disks, large file transfers from secondary media to local hd, loss of power to a hard drive, hard disk intensive processes (eg: antivirus scanners), recently installed hardware that might have compatibility and performance problems)

This link has an interesting description of BSOD codes in general:
http://www.aumha.org/a/stop.php
It briefly describes a CRITICAL_OBJECT_TERMINATION.
It also contains a link to a 2007 article:
http://support.microsoft.com/default.aspx?scid=kb;en-us;330100
This link describes the symptom, but mentions the PATA drive not configured as a primary.  

I also found this link in EE:
http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Windows/XP/Q_22908820.html#a20146646
Unfortunately, it recommends to "Nuke and pave" - which has already been done.

The System event log shows:
Error code 00000077, parameter1 c000000e, parameter2 c000000e, parameter3 00000000, parameter4 00fdf000.
Category (102), EventID: 1003
Note that BSOD x77 was being produced at resume from standby /before/ the partition was put onto an aligned boundary and the OS was freshly reinstalled.

Currently in the c:\windows\Minidump folder, there are 4 minidump files.

I am hoping for guidance, to at least learn more about the problem, and possibly solve it.

Thank you in advance for your help!

Answer : XP Pro SP3 on Dell Inspiron 9400 notebook with OCZ SSD: BSOD 0xF4 after resume from standby

Well, I've exchanged several trouble ticket messages with the manufacturer (OCZ), and it turns out that there can be a subtle problem with the drive when installed into an older computer.

I've talked with Dell technical support, and confirmed that the computer does indeed have a SATA1 interface.  

The drive has a SATA2 interface, which has a higher rated bandwidth than a SATA1 interface.  The SATA1 interface does not throttle the data when the bandwidth gets too high (read: saturates).  

Here's a link to more information:
http://en.wikipedia.org/wiki/Serial_ATA#SATA_Revision_1.0_.28SATA_1.5Gb.2Fs.29

I've posted two suggestions to OCZ for possible firmware improvements.  The first is to set the drive to operate at the SATA1 bandwidth (which will go far in solving incompatibility problems like this, and still retain zero seek times).  The second is to introduce a start delay, which would cause the SSD to delay the initial time it begins to produce data, to allow the SATA controller and associated drivers to become ready before the data onslaught begins to occur.

So the lesson learned is: installing a much faster SSD than what the computer originally had will not automatically work, because there are one or more corner cases where the SATA1 interface will get saturated and cause unintended results.  

So for now, I'm done.  

Either the customer is going to accept that the Standby functionality of the OS is not going to work with this drive, or the drive needs to be replaced with something slower.