KERNEL_DATA_INPAGE_ERROR ntoskrnl.exe 0x0000007a

Monday, December 2, 2019





Bleeping Computer



Hi. . .

No work for me here as you know the problem already.

From the dumps -
[code]DISK_HARDWARE_ERROR: There was error with disk hardware[/code]

Run SeaTools for DOS, LONG test -

Regards. . .

jcgriff2

Always getting BSOD when hibernate

Always getting BSOD when hibernate


https://www.sysnative.com/forums/threads/always-getting-bsod-when-hibernate.29995/

Sysnative Forums






Hi. . .

Also for now, remove FrontEnd security from Fortinet, Inc - uninstall it.

Rich (BB code):
0: kd> !irp fffffa80`1ee14160
Irp is active with 3 stacks 2 is current (= 0xfffffa801ee14278)
 No Mdl: No System Buffer: Thread 00000000:  Irp stack trace.  
     cmd  flg cl Device   File     Completion-Context
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000    

            Args: 00000000 00000000 00000000 00000000
>[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
            0 e1 fffffa801f02f050 00000000 00000000-00000000    pending
           \Driver\ftsvnic
            Args: 00015500 00000001 00000004 00000003
 [N/A(0), N/A(0)]
Code:
ftsvnic.sys  Wed Feb 20 09:21:32 2019 (5C6D8C9C)
Regards. . .

jcgriff2

Stopcode system Service Exception

Sunday, December 1, 2019

Stopcode system Service Exception


Marvell Yukon SATA driver

Posted Today, 04:13 PM
Eddavid, on 01 Dec 2019 - 2:04 PM, said:
it crashes to a blue  screen with the information that the exception is mvs91**.sys 

That is likely your Marvell SATA controller driver begging to be updated.


Please provide the info that MrPepka requested as we do need it.

I just know this Marvell driver from years of dealing with it.

Regards. . .

jcgriff2


Stop (System Service Exception) Exception Error BSOD

Saturday, November 30, 2019


Stop (System Service Exception) Exception Error BSOD



https://www.bleepingcomputer.com/forums/t/708825/stop-exception-error-bsod/



Bleeping Computer



Hi. . .

When you place a system into hibernation, the contents of RAM (physical memory at the time) is written to the file c:\hiberfil.sys, which on a Windows 10 system is about 75% of the size of physical installed RAM (maximum file size).

RAM as reported by the Windows app systeminfo also found in the Sysnative zip file -
Total Physical Memory:     8,107 MB (8 GB rounded)


So, I would expect the hiberfil.sys to be about 6.8 GB in size. (Not really important here; just noting this as we get towards the point that I'm trying to make).

BSOD mini kernel memory dump files (found in \windows\minidump) contain the date of the BSOD in the filename.

Inside of your Sysnative zip file that you attached to your post (THANK YOU!), I found a tiny (in size) corrupted BSOD dump file named [b]082419-37468-01.dmp[/b] - which means that a BSOD occurred on 24 August 2019. Based on other system data in the Sysnative file, you may not have even known that a BSOD occurred that day.

The only information that the dump gave me (because of its corruption and 2 byte total size) was an NT STATUS/Exception error code of:
[CODE]0xC000011E
STATUS_MAPPED_FILE_SIZE_ZERO    An attempt was made to map a file of size zero with the maximum size specified as zero.[/CODE]

... which as you can probably guess means - An file was mapped with a total file size = 0 bytes and the maximum size  was specified as zero, which does not make much sense to me. Why map a file then write to the file if you are not going to write any data/info to it? The exception error code written in hex is where the 2 byte file size comes from.

I only bring all of this up because of your current complaint/issue/problem involving the hard drive. The 0xc000011e exception error code could have been a precursor of things to come involving the hard drive; not sure as I am only making a guess here based on the logical information at hand.

You reported a "Stop Exception Error BSOD", which could actually be a "System Service Exception Error BSOD, Bugceck 0x3b with the exception error code = 0xc000011e; not 100% sure on this, but it is the closest BSOD title that I could find. It basically means that a system service threw an exception, the exception being the 0xc11e error code.


It is a hard drive diagnostic test that runs under the DOS operating system, so Windows does not load, so no BSODs will occur.

Regards. . .

jcgriff2




BSOD crashing seems to be related to AMD and Intel driver

Friday, November 22, 2019

Bleeping Computer -



Likely a bad video card





I processed the five (5) dumps found in the Sysnative zipped folder.

I experienced symbol errors on several of the dumps. Basically, each Microsoft driver is looked up at a Microsoft symbol site and some of your Windows drivers are not recognizable to the Microsoft symbol site. Some reasons this can happen -
- the driver is corrupted and the file characteristics have changed
- there is a problem with the Microsoft symbol site
- a new version of the Microsoft driver was released; you updated it via Windows Updates, but the new driver has not yet been placed on the symbol server.

All of that is good to know  (I guess), but what it comes down to is that I was unable to accurately process most of your dumps due to bad symbols.

The bugcheck and probable causes from your 5 dumps -
BugCheck 100000EA, {ffffb00aef0cb1c0, 0, 0, 0}
Probably caused by : dxgkrnl.sys ( dxgkrnl!TdrTimedOperationBugcheckOnTimeout+45 )
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
BugCheck 133, {1, 1e00, fffff80611d73358, 0}
Probably caused by : condrv.sys ( condrv!CdpCreateProcess+14f )
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
BugCheck 100000EA, {ffffac843b48e300, 0, 0, 0}
Probably caused by : dxgkrnl.sys ( dxgkrnl!TdrTimedOperationBugcheckOnTimeout+45 )
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
BugCheck 100000EA, {ffff9085fcf4a540, 0, 0, 0}
Probably caused by : dxgkrnl.sys ( dxgkrnl!TdrTimedOperationBugcheckOnTimeout+45 )
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
BugCheck 100000EA, {ffff828ad52a4040, 0, 0, 0}
Probably caused by : dxgkrnl.sys ( dxgkrnl!TdrTimedOperationBugcheckOnTimeout+45 )
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``

0xea  - This is the bugcheck that you described as "thread stuck in driver".  Here is additional information on it --  indicates that a thread in a device driver is endlessly spinning. The likely cause - A device driver is spinning in an infinite loop, most likely waiting for hardware to become idle. This usually indicates problem with the hardware itself, or with the device driver programming the hardware incorrectly. Frequently, this is the result of a bad video card or a bad display driver.

0x133 - DPC Watchdog Violation - indicates that the DPC watchdog executed, either because it detected a single long-running deferred procedure call (DPC), or because the system spent a prolonged time at an interrupt request level (IRQL) of DISPATCH_LEVEL or above. The value of Parameter 1 indicates whether a single DPC exceeded a timeout, or whether the system cumulatively spent an extended period of time at IRQL DISPATCH_LEVEL or above.

Usually in Windows, the word "WATCHDOG" refers in some manner to video.

The probable causes -
dxgkrnl.sys - Microsoft DirectX Graphics kernel driver
condrv.sys - simply listed as a "console driver"


Also, each dump named your ATI video drivers -

atikmdag.sys Mon Jun 18 09:29:42 2018 (5B27DDF6)
atikmpag.sys Mon Jun 18 09:01:46 2018 (5B27D76A)

I don't see these particular drivers at the Dell driver site, so go to ATI to update them. I'm positive that they have newer drivers than those two June 2018 drivers that you have in your system -


First, however, it is extremely important for you to create a Windows system restore point so that you can easily un-do the driver updates if you need to -


After the restore point is created, then go ahead and update the ATI drivers.

That is it for now.

Regards. . .

jcgriff2
244x90_BC_04-04-2019.png

New PC randomly blue screening, usually when idle

New PC randomly blue screening, usually when idle



Bleeping Computer - https://www.bleepingcomputer.com/forums/t/708364/new-pc-randomly-blue-screening-usually-when-idle/





I processed the 5 kernel memory dumps in your Sysnative zip file and believe the BSODs to be caused by unknown hardware failure.

The bugchecks -
BugCheck 1E, {ffffffffc0000005, fffff805537c4795, 0, ffffffffffffffff}
Probably caused by : ntkrnlmp.exe ( nt!KiIsrLinkage+2f4 )
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
BugCheck 1A, {41792, ffffa98000042ec0, 200000000000, 0}
Probably caused by : memory_corruption ( ONE_BIT )
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
BugCheck 3B, {c0000005, ffffcbd5be074e4c, ffff918441813fe0, 0}
Probably caused by : win32kfull.sys ( win32kfull!NtUserBuildHwndList+58c )
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
BugCheck 1A, {61941, 296936564b0, d, ffffca8940d40b00}
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
BugCheck 1A, {61941, 6753cadc, d, fffffe0f444d8b00}
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
0x1a = severe memory management error
0x1e (0xc0000005,,,) = kernel threw an exception; the excp = 0xc5 = memory access violation
0x3b (0xc0000005,,,) = system service threw an exception; excp = 0xc5 = memory access violation

You can see in the above code boxes the various "Probably caused by" notations -
- ntkrnlmp.exe = the Windows kernel & Executive -- it cannot be a cause. It is likely listed as a default because the real cause could not be determined
memory_corruption - self explanatory
Unknown_Image - this should be a driver name. Seeing Unknown Image tells me that memory corruption occurred

Test RAM one stick at a time and alternate the slots - https://www.sysnative.com/forums/threads/test-ram-with-passmark-memtest86.24300/

I see that you have 3 internal hard drives. Test each with SeaTools for DOS, LONG test - https://www.sysnative.com/forums/threads/hard-drive-hdd-diagnostics-sea-tools-for-dos-ssd-test.4072/

If any of the drives are SSDs, go to the drive manufacturer's support site and check for a firmware upgrade. *** VERY IMPORTANT ***

Also, please follow the suggestions of others that have posted in this thread.

hamluis for example is an absolute master of Windows Internals and knows a great deal more about the inner workings of Windows than I do. So, please follow his and the other's instructions. THANK YOU.

Are these the very first BSODs that you have encountered on this new 2 month old new system?

Do you recall installing any new apps/programs prior to the start of the BSODs?

Any hardware changes since building and finishing the system two months ago?

These types of BSODs are tough to solve because they are more than likely [unknown] hardware related. Unfortunately, dump files and Windbg (the kernel debugger) were invented to assist app and driver developers (software developers) debug their source code; not to aid in troubleshooting hardware failure. The dumps are incapable of telling us the exact piece of hardware that has failed. The closest it will bring us is what it has reported to us here - e.g., the "memory  management" error; the clue that Unknown Modules are caused by memory corruption (that just comes with my 12+ years of experience processing over 1 million BSOD dumps since 2007); and other things that I have picked up over the last 12+ years.

So, sorry that I could not be more helpful to you here.

Perhaps more dumps will yield clues.

Before the RAM and SeaTools diagnostic tests, run Driver Verifier - https://www.bleepingcomputer.com/forums/t/576333/driver-verifier-bsod-related-windows-10-81-8-7-vista/

It must run for at least 24 ours in the background. You can continue to use your system, but may notice some system slowness as D/V is very resource intensive.

If a BSOD does occur, go to \windows\minidumps and copy out the latest dump (the filenames contain the date) to Documents or Desktop; then zip the dump file and attach it to your next post. Windows will not allow you to zip up the dump file in place (\windows\minidumps) due to permission settings.

That should be enough to get you started/.

Good luck to you.

Regards. . .

jcgriff2

On a side note which really  has nothing to do with your BSOD epidemic, I noticed in Speccy that you have your screen saver disabled -
Screen saver:  Disabled
I have mine turned on as I usually fall asleep at night with a video playing.

no disk space

Wednesday, November 20, 2019

no disk space


Bleeping Computer - https://www.bleepingcomputer.com/forums/t/708047/no-disk-space/?p=4906212




Posted Today, 12:00 PM
Also, I suggest that you install TreeSize free edition and look for large pockets of used space, especially under your user profile folder (c:\users\<yourUserName>\) as certain apps are infamous for writing out every piece of data, especially error reports and user-mode memory dumps that are transmitted back to the app's manufacturer (usually without your knowledge).

I recently found over 3 GB of space being used by memory dumps that an app had created, located under my user profile, \appdata directory (folder). I had no idea the app was creating these memory dumps nor did I know that the user-mode dumps were kept in a folder that the app had set up under my user profile, apparently to be kept in perpetuity as I saw no setting for the app to auto delete old dumps. Simply disgraceful, in my opinion.


I would also highly recommend deleting all data found in the WER folders (Windows Error Reporting, a/k/a Windows Problem Reports and Solutions) as the WER folders can be sizable due to the fact that they many contain user-mode memory dumps. 

There is no reason whatsoever to hold on to/keep this crash data, except for historical purposes, which makes no sense in this case.

WER folders are kept in two places - under your user profile folder and also the \ProgramData folder.

To delete the WER entries, run these RD (Remove Directory) commands one at a time, waiting for the first to complete before running the second.

Open an elevated Admin CMD Prompt screen; copy/paste (preferred method) or type the following into the CMD screen; press Enter -
rd /s /q "%userprofile%\AppData\Local\Microsoft\Windows\WER"
 
rd /s /%programdata%\Microsoft\Windows\WER
One of the sub-directories (sub-folder) in my \ProgramData..\WER folder contained over 250 MB of WER error reports and dumps until I deleted it this morning. That may seem to be a small amount of space in the grand scheme of things, but this Windows 10 installation is less than 8 months old, so I would expect the WER space used numbers to increase dramatically over the next few years - perhaps to several gigabytes (GB).

I would suggest running the two commands to delete all of the WER data as it serves no purpose to keep the crash data. Also, it will of course free up some additional space and at this point, every little bit of space freed is helpful.

Regards. . .

jcgriff2

Edited by jcgriff2, Today, 12:04 PM.

Memory corruption BSODs but passing tests

Sunday, November 17, 2019

Bleeping Computer - https://www.bleepingcomputer.com/forums/t/708022/memory-corruption-bsods-but-passing-tests/



Memory corruption BSODs but passing tests



Hi. . .
 
The bugchecks on the 3 dumps -
(1) 0x1000007e (0xc0000005,,,) = system thread threw an exception; the exception = 0xc5 = memory access violation
(2) 0x12b (0xc00002c4,,,) = FAULTY_HARDWARE_CORRUPTED_PAGE (12b)
This bugcheck indicates that a single bit error was found in this page.  This is a hardware memory error.
 
The exception error code (1st number inside the parenthesis) -

Quote

0xC00002C4
STATUS_CORRUPT_SYSTEM_FILE The system file %1 has become corrupt and has been replaced.
 
Return the system if at all possible. Either the RAM is bad or there is an unknown underlying catalyst causing RAM to fail, i.e., not to be able to properly hold kernel code such as PSU, motherboard, excessive heat, cables, wiring, etc...
 
BSOD dumps are incapable of telling us the exact piece of hardware that is failing as dumps grew out of the need to aid software developers (driver developers too) to "debug" their code. Dumps were not invented for or intended to diagnose hardware problems, so the dump telling us that a "hardware memory error" exists is as close as we'll get to an answer from the dumps.
 
The other possible culprit is your samsung mzvlw256hehp-000h1 SSD drive. SSDs act more like RAM than they do traditional HDDs and therefore a problematic SSD can give off memory related bugchecks. 
 
Also, notice how the word "memory" is used vs. "RAM". There are two types of memory - (1) installed physical RAM and (2) virtual memory - the hard drive's page file which is used in lieu of RAM  when either RAM is exhausted (no more RAM available) or an app writes directly to virtual memory (like Notepad does; same with Sysinternals Process Monitor).
 
So, the reference to "memory" here could mean either RAM (or other underlying unknown hardware failure that is affecting RAM negatively) or possibly the SSD.
 
NT STATUS/Exception error code 0xc00002c4 then may possibly be referring to the SSD and virtual memory; not sure.
 
Check Samsung for a firmware update for your samsung mzvlw256hehp-000h1 SSD - https://www.samsung.com/semiconductor/minisite/ssd/product/consumer/magician/
 
It may be a long shot, but still worthwhile to try.
 
However, with problems like these on a brand new system -- I advise that you do everything possible to obtain a new system from HP. Who knows exactly how deep the problems lay and you could end up with a super problematic system that you'll end up troubleshooting odd problems than you will using the system for work, school or other legitimate use.
 
My apologies that I could not be more definitive.
 
Regards. . .
 
jcgriff2

Recurring BSOD Trouble - Bleeping Computer

Thursday, November 14, 2019



OP started testing hardware while waiting for a BSOD analyst to respond and claims that memtest indicated some type of CPU error.



My reply:



Hi. . .

I don't know why a RAM test would indicate an error with the CPU.

Re-test RAM with memtest86+ one stick at a time; alternate the slots - https://www.sysnative.com/forums/threads/test-ram-with-memtest-org-memtest86.24316/


Regards. . .

jcgriff2

p.s. Since processing BSODs and answering threads at these online tech forums for over 12 years now, I don't ever remember anyone getting RAM to fail the Windows built-in memory (RAM) test.

By the way - Great Troubleshooting efforts on your part!

Windows 10 - Computer blue screens about a minute after being in sleep mode

Tuesday, November 5, 2019

Windows 10 - Computer blue screens about a minute after being in sleep mode



Bugcheck 0x9f (0x3,,,)



Hi. . .

The scanning and updating drivers in Device Manager really does not work properly for 3rd party drivers. If you think about it, how would Device Manager (Windows) know exactly where to go to obtain an updated 3rd party driver -- like your HP drivers for example? Why did not Device Manager pick those up?

You've got to update that xbox driver.

4 of the 5 dumps processed mentioned this Virtual USB Host Controller driver but did not tell me how or if it is involved in the BSODs -
nvvhci.sys   Thu Aug 16 13:01:22 2018 (5B75D812)
It should be updated but the update comes from Windows Update, so there is nothing for you to do except to make sure that ALL Windows Updates (both Important and Optional) are installed. It is possible that the xbox driver (xusb22.sys) is hiding under nvvhci.sys - as Microsoft drivers very rarely ever cause BSODs.
https://www.sysnative.com/drivers/driver.php?id=nvvhci.sys

I also processed all 5 dumps and all blamed the Xbox driver as the primary cause of the BSODs.

Look for xusb22.sys (xbox driver) in the following summary of your dumps - (it is listed in every dump) -
BugCheck 9F, {3, ffffb40dc7b4cc70, fffffc8b8b45f7b0, ffffb40dcd36d9a0}
Probably caused by : xusb22.sys ( xusb22!XenonBusInformation::OnD0Entry+3f )
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
BugCheck 9F, {3, ffffab87b97c59f0, fffff8047aa0b7b0, ffffab87b97ca9e0}
Probably caused by : xusb22.sys
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
BugCheck 9F, {3, ffffbb892f06ecb0, ffffba0798a7f7b0, ffffbb892de84be0}
Probably caused by : xusb22.sys ( xusb22!XenonBusInformation::OnD0Entry+3f )
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
BugCheck 9F, {3, ffffc48523cd7cd0, fffff8034b80b7b0, ffffc48526deb330}
Probably caused by : xusb22.sys ( xusb22!XenonBusInformation::OnD0Entry+3f )
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
BugCheck 9F, {3, ffffa1077dc5ca10, fffffd8bb2e5f7b0, ffffa1078cac7850}
Probably caused by : xusb22.sys ( xusb22!XenonBusInformation::OnD0Entry+3f )
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
I don't know what else to tell you about your BSODs except that the current xbox driver will likely continue the BSOD epidemic.

Regards. . .

jcgriff2

p.s. A more comprehensive summary of your dumps - (look for nvvhci.sys in the summaries - mentioned in the dumps as I said earlier -
Loading Dump File [C:\Users\PalmDesert\_jcgriff2_\dbug\__Kernel__\110419-8250-01.dmp]
Built by: 18362.1.amd64fre.19h1_release.190318-1202
Debug session time: Mon Nov  4 16:44:48.512 2019 (UTC - 5:00)
System Uptime: 0 days 0:10:11.266
*** WARNING: Unable to verify timestamp for nvvhci.sys
*** ERROR: Module load completed but symbols could not be loaded for nvvhci.sys
*** WARNING: Unable to verify timestamp for win32k.sys
*** ERROR: Module load completed but symbols could not be loaded for win32k.sys
Probably caused by : xusb22.sys ( xusb22!XenonBusInformation::OnD0Entry+3f )
DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT
BUGCHECK_STR:  0x9F
PROCESS_NAME:  System
FAILURE_BUCKET_ID:  0x9F_3_xusb22!XenonBusInformation::OnD0Entry
Bugcheck code 0000009F
Arguments 00000000`00000003 ffffb40d`c7b4cc70 fffffc8b`8b45f7b0 ffffb40d`cd36d9a0
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
Loading Dump File [C:\Users\PalmDesert\_jcgriff2_\dbug\__Kernel__\110419-8406-01.dmp]
Built by: 18362.1.amd64fre.19h1_release.190318-1202
Debug session time: Mon Nov  4 16:34:11.425 2019 (UTC - 5:00)
System Uptime: 0 days 0:09:08.179
*** WARNING: Unable to verify timestamp for win32k.sys
*** ERROR: Module load completed but symbols could not be loaded for win32k.sys
Probably caused by : xusb22.sys
DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT
BUGCHECK_STR:  0x9F
PROCESS_NAME:  System
FAILURE_BUCKET_ID:  0x9F_3_IMAGE_xusb22.sys
Bugcheck code 0000009F
Arguments 00000000`00000003 ffffab87`b97c59f0 fffff804`7aa0b7b0 ffffab87`b97ca9e0
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
Loading Dump File [C:\Users\PalmDesert\_jcgriff2_\dbug\__Kernel__\110419-8906-01.dmp]
Built by: 18362.1.amd64fre.19h1_release.190318-1202
Debug session time: Mon Nov  4 16:24:41.306 2019 (UTC - 5:00)
System Uptime: 0 days 0:03:03.060
*** WARNING: Unable to verify timestamp for nvvhci.sys
*** ERROR: Module load completed but symbols could not be loaded for nvvhci.sys
*** WARNING: Unable to verify timestamp for win32k.sys
*** ERROR: Module load completed but symbols could not be loaded for win32k.sys
Probably caused by : xusb22.sys ( xusb22!XenonBusInformation::OnD0Entry+3f )
DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT
BUGCHECK_STR:  0x9F
PROCESS_NAME:  System
FAILURE_BUCKET_ID:  0x9F_3_xusb22!XenonBusInformation::OnD0Entry
Bugcheck code 0000009F
Arguments 00000000`00000003 ffffbb89`2f06ecb0 ffffba07`98a7f7b0 ffffbb89`2de84be0
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
Loading Dump File [C:\Users\PalmDesert\_jcgriff2_\dbug\__Kernel__\110519-8625-01.dmp]
Built by: 18362.1.amd64fre.19h1_release.190318-1202
Debug session time: Tue Nov  5 00:15:54.481 2019 (UTC - 5:00)
System Uptime: 0 days 0:13:09.235
*** WARNING: Unable to verify timestamp for nvvhci.sys
*** ERROR: Module load completed but symbols could not be loaded for nvvhci.sys
*** WARNING: Unable to verify timestamp for win32k.sys
*** ERROR: Module load completed but symbols could not be loaded for win32k.sys
Probably caused by : xusb22.sys ( xusb22!XenonBusInformation::OnD0Entry+3f )
DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT
BUGCHECK_STR:  0x9F
PROCESS_NAME:  System
FAILURE_BUCKET_ID:  0x9F_3_xusb22!XenonBusInformation::OnD0Entry
Bugcheck code 0000009F
Arguments 00000000`00000003 ffffc485`23cd7cd0 fffff803`4b80b7b0 ffffc485`26deb330
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
Loading Dump File [C:\Users\PalmDesert\_jcgriff2_\dbug\__Kernel__\110419-10734-01.dmp]
Built by: 18362.1.amd64fre.19h1_release.190318-1202
Debug session time: Mon Nov  4 15:41:49.654 2019 (UTC - 5:00)
System Uptime: 0 days 16:50:25.408
*** WARNING: Unable to verify timestamp for nvvhci.sys
*** ERROR: Module load completed but symbols could not be loaded for nvvhci.sys
*** WARNING: Unable to verify timestamp for win32k.sys
*** ERROR: Module load completed but symbols could not be loaded for win32k.sys
Probably caused by : xusb22.sys ( xusb22!XenonBusInformation::OnD0Entry+3f )
DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT
BUGCHECK_STR:  0x9F
PROCESS_NAME:  System
FAILURE_BUCKET_ID:  0x9F_3_xusb22!XenonBusInformation::OnD0Entry
Bugcheck code 0000009F
Arguments 00000000`00000003 ffffa107`7dc5ca10 fffffd8b`b2e5f7b0 ffffa107`8cac7850
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
EDIT: I am not a hardware expert and really don't know what to make of the screen/video issue at this time.

After the BSOD epidemic is over, you can post in our Hardware forum for help with that issue as I do not believe that the BSODs are responsible for the image contained on your screen in the screenshot.

JC



Occasional BSOD usually after sleep mode

Monday, October 28, 2019

 
Bleeping Computer
 
Hi. . .

You've had 18 BSODs since 30 August 2019 - just under 2 months now.

I firmly believe the cause to be a faulty hard drive.  I'm just not sure which drive is the problem though. Windows and Windbg won't tell us that. We're lucky it even told us about the disk.

BSOD kernel memory dumps were invented to assist software programmers/coders in debugging their code; not for the purpose of identifying failing hardware - with the exception of one piece of hardware - hard drives. Windows is capable of detecting I/O errors and therefore can detect a failing hard drive.

Several of your BSODs contain this "Probably caused by:" statement - 
Probably caused by : hardware_disk

Others included this failure bucket ID -
FAILURE_BUCKET_ID:  X64_0xF4_csrss.exe_BUGCHECK_CRITICAL_PROCESS_8585060_IMAGE_hardware_disk

I can't highlight inside a codebox here, but as you read the line you'll notice an "F4" (referring to bugcgeck 0xf4) plus at the end - "hardware_disk"

Your BSOD bugchecks (STOP errors) include -
0xf4 - Critical Object Termination - a process (an app or program) suddenly, without warning or prompting, simply died (terminated). This is well known to me as an indicator of a faulty hard drive

0x7a - Kernel Data Inpage Error -  indicates that the requested page of kernel data from the paging file could not be read into memory -- again, Windows is telling us that the hard drive had a problem here while trying to read data from it and loading it into RAM

The system reports in the zip file that you provided (thank you, by the way) indicate that you have 2 hard drives. One SSD and one HDD.
SSD = Samsung SSD 850 PRO 256 GB ATA Device
HDD = 500 GB WDC WD5002AALX-00J37A0 ATA Device
First thing to do is to check for a firmware update for your SSD. Outdated firmware can cause the SSD to fail.


If you do find a firmware update, update it and test the system for a few days and see if the BSODs continue.

If so, or if no firmware update, run SeaTools for DOS, LONG test - on BOTH drives.


This version of SeaTools runs under DOS OS, so Windows does not load, so there will definitely be no BSODs during these tests.

Check for the firmware update; run the SeaTools tests on both drives. One of them is failing.

Regards. . .

jcgriff2

Text

Powered by Blogger.

Follow by Email

Search This Blog

Popular Posts