0xF4 - Applications crashing sporadically

[WhitePhoenix]

I own a custom-built machine that a friend and I put together because the old pre-built ones my family owned had less-than desirable specs and were bogged down with bloatware. I figured it was high-time for an upgrade, so I built my own machine for a change.

After having it for a couple months, it's having a occasional quirks with regards to recognizing the secondary hard drive, and more troubling: had a couple Blue Screens of Death. One of the more recent ones happened when bringing Adobe Photoshop CS5, Chrome, and Skype after booting up the machine.

System specs are available on my profile. If anyone could take a look at the minidump information and figure out what the issue is, I would greatly appreciate it.

 

[YoYo155]

Hello and welcome to SF WhitePhoenix .

BugCheck Code 0xF4 are more often than not storage issues, being the disk itself or the storage subsystem
(i.e. SATA ports / SATA cables (Data & Power) / the Chipset).

CRITICAL_OBJECT_TERMINATION (f4)
A process or thread crucial to system operation has unexpectedly exited or been
terminated.
Several processes and threads are necessary for the operation of the
system; when they are terminated (for any reason), the system can no
longer function.
Arguments:
Arg1: 0000000000000003, Process
Arg2: fffffa800df01560, Terminating object
Arg3: fffffa800df01840, Process image file name
Arg4: fffff80002fd37b0, Explanatory message (ascii)

EXCEPTION_CODE: (NTSTATUS) 0xc0000006 - The instruction at 0x%p referenced memory at 0x%p. The required data was not placed into memory because of an I/O error status of 0x%x.

BUGCHECK_STR:  0xF4_IOERR

Are all of the parts used to build the system new?
Please test the HDD.

   Warning

The Following Method Should NOT Be Performed On An SSD!

​

:ar: Testing the HDD:

1. Perform a Disk Check | Disk Check- Scroll down to OPTION TWO of the tutorial and use the /R switch in the CHKDSK command | chkdsk C: /R.
2. Then Post the Disk Check results following | This Tutorial.
3. Once back in Windows, download Crystal Disk Info and post a screenshot (multiple shots if you have more than one drive).
4. Download SeaTools for DOS if you don't want to use a CD to test the HDD you can use YUMI – Multiboot USB Creator to create a bootable USB (instructions are found at the bottom of both pages).
5. If SeaTools for DOS is unable to recognize your HDD:
6. Visit HDDdiag and follow the instructions | Or follow the instructions below.

If SeaTools For DOS does not recognize the drive;
Boot into the BIOS using the *Fx key.
Look for an entry called SATA Mode (or something similar), it should be set to IDE / AHCI.
It's probably set to AHCI which is why SeaTools doesn't recognize them in the DOS environment.
Set it to IDE then save and exit usually by pressing the F10 key.
Now boot into SeaTools and it should detect the drives.
Start the Long Test and let it run.
Upon completion don't try to boot into Windows as it will only result in a BSOD, go back into the BIOS
and change the SATA setting back to what it was in the first place.

• *Popular BIOS access keys.

Re-seat the sata and power.

Let us know the results.

 

[WhitePhoenix]

Thanks for the advice, YoYo. I've got the CHKDSK and CrystalDiskInfo (HHD on the right) results you asked for.

All the parts of the machine are new, and for the most part are working beautifully. I made a boot CD with SeaTools and ran one of the long tests on my HDD. I couldn't track down the results log to show you afterward, but it did say the HDD passed.
As a final measure, I did re-seat the SATA and power cables. I didn't notice any obvious problems with them, but it is always a good thing to be sure.

It is worth noting that mere minutes after I finished the CHKDSK operation, Windows crashed and I got another blue screen (0x7A). The only application running was Chrome; I was re-checking the instructions page on posting the checkdisk results when it struck. I uploaded an updated folder with the new minidump in it. Hopefully it will help us get to the bottom of this.

If anything else happens, I'll keep you posted.

 

[YoYo155]

Hi again .

No new dumps are present in the file uploaded but good job on catching the BugCheck Code at least.

STOP 0x0000007A: KERNEL_DATA_INPAGE_ERROR
Usual causes:
Memory, Paging file corruption, File system, Hard drive, Cabling, Virus infection,
Improperly seated cards, BIOS, Bad motherboard, Missing Service Pack.

Do you by any chance remember the value of the 2nd parameter?

The system event log is filled with these errors:

Event[28177]:
  Log Name: System
  Source: atapi
  Date: 2014-01-31T10:12:19.093
  Event ID: 11
  Task: N/A
  Level: Error
  Opcode: N/A
  Keyword: Classic
  User: N/A
  User Name: N/A
  Computer: WhitePhoenix
  Description: 
The driver detected a controller error on \Device\Ide\IdePort1.

Event[28178]:
  Log Name: System
  Source: Disk
  Date: 2014-01-31T10:12:19.093
  Event ID: 15
  Task: N/A
  Level: Error
  Opcode: N/A
  Keyword: Classic
  User: N/A
  User Name: N/A
  Computer: WhitePhoenix
  Description: 
The device, \Device\Harddisk1\DR1, is not ready for access yet.

Event[28179]:
  Log Name: System
  Source: Disk
  Date: 2014-01-31T10:12:19.093
  Event ID: 51
  Task: N/A
  Level: Warning
  Opcode: N/A
  Keyword: Classic
  User: N/A
  User Name: N/A
  Computer: WhitePhoenix
  Description: 
An error was detected on device \Device\Harddisk1\DR1 during a paging operation.

Harddisk1 is your HDD;

Model    WDC WD2002FAEX-007BA0 ATA Device
Partition    Disk #1, Partition #0

Reset your Page File:

1. rb:Start Menu> Run >type control.exe system
and press the Enter key.
A windows will open and on the Left hand side you will see Advanced system settings, click it.



2. Next click on the Advanced tab and Settings which correspond to the Performance section;



3. Then the Advanced tab once more and click on the Change button;



4. Untick the checkbox next to Automatically manage paging file size for all drives;

Select No paging file and Click on the Set button;


5. Confirm all the windows.

6. Restart the PC.

7. Reverse the procedure, by following steps 1-3, only this time select System managed size
and click the Set button;



8. Recheck the box next to Automatically manage paging file size for all drives
and exit the windows by clicking the OK button;



9. Confirm all of the remaining windows by click the OK button
and restart the PC once again to take affect.


:ar: Please scan for possible infection and file corruption:

• Download TDSS-Killer and scan for rootkits.
• Download Kaspersky Rescue CD and scan for other types of infections. (a how-to tutorial)
• Download Malwarebytes and DON'T activate the trail (uncheck the box at the end of the installation)
• Follow this tutorial on how to use the SFC/ SCANNOW tool in Windows.

(*Kaspersky Rescue CD from a USB thumbdrive)


:ar: Also try to completely replace the SATA Data & Power on both drives.

 

[WhitePhoenix]

Hmm, I just assumed the minidump would be saved after each BSOD, but it would seem there's no new entry in the minidump folder for the crash.
Oh well.

I made an interesting discovery, in that the HDD's Paging File Size was set to "none". That could be the problem. I set it to system managed and restarted the machine.
After that, I did the infection/corruption sweeps you asked me to do. They all came up clean.

Thanks again for your help, YoYo. I hope we identified the problem.
I'll keep an eye out for additional issues. If I see any, I'll post about them. If not, I'll mark it solved!

 

[YoYo155]

Let us know how it handles .

 

[WhitePhoenix]

System was handling fine; no problems recognizing the hard drive. However, I just got another 0xF4 error while watching a Youtube video in Chrome.

I made a point to write down the codes in case no minidump was present this time.

0xF4
0x0000000000000003
0xFFFFFA800DE11B30
0xFFFFFA800DE11E10
0xFFFFF80002F7A7B0

After I booted up Windows, I checked the minidump folder. Unfortunately, no new logs were present. I went into the advanced system settings and then to recovery settings to see what was going on. Apparently the machine has been doing full kernel dumps, and I'm not sure how to track those down for you.

I specified Minidumps and made sure the folder directory was C:\Windows\Minidump. Next time, I'll have the information you need.

 

[YoYo155]

Darn, well sometimes it fails to create a minidump but manages to dump the Kernel dump.
You can look for them (Well it as it overwrites the older one) in C:\Windows\
there should be a file named MEMORY.DMP .

You won't be able to upload it here due to the size restriction.

Please upload the Kernel dump file using Dropbox or Skydrive, the file is located in the Windows directory
and is usually a few hundred Megabytes in size.

C:\Windows\MEMORY.dmp

 

[WhitePhoenix]

I uploaded the full kernel dump to Dropbox, but the odd part is it says it's been last updated on the 8th of January.

Even if it is a month old, I figured it could still be of some use in figuring this out.
https://www.dropbox.com/s/jr3olsece7qwyn4/MEMORY.DMP