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

Author: jcgriff2 at 14:10 0 comments  

Just updated from 7 to 10 and getting 0x109 BSODs - asacpi.sys -- sptd.sys

Saturday, October 19, 2019

Just updated from Windows 7 to Windows 10 and getting 0x109 BSODs - asacpi.sys -- sptd.sys



Sysnative - https://www.sysnative.com/forums/threads/just-updated-from-7-to-10-and-getting-random-0x00000109-blue-screens.29659/#post-275558



_________________________________________________________________



asacpi.sys (and also asio.sys s/b updated and/or removed as well)



Hi. . .

All 4 dumps were nearly identical with bugcheck 0x109 - CRITICAL_STRUCTURE_CORRUPTION

This bugcheck appears when when the kernel detects that critical kernel code or
data have been corrupted.

There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
or data. See Windows Hardware Dev Center
2) A developer attempted to set a normal kernel breakpoint using a kernel
debugger ..... THIS DOES NOT APPLY HERE TO YOU
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data is either bad or some other underlying hardware failure occurred that affects RAMs ability to properly hold kernel code - like extreme heat; PSU failure; motherboard, etc... - any piece of hardware that could affect RAM.

#1 seems to be a possibility to me given an Asus Utility driver that I found in your loaded [into RAM] driver listing in all 4 dumps that wreaked absolute havoc during the later days of Vista/early days of Windows 7. Windows 8 and 8.1 were not immune, either. However, I have not seen much negative activity regarding this driver and Windows 10. But if ever there was a driver to attempt to modify critical kernel code, it would be this Asus ATK0110 driver.

I used to see this driver (a 2004 version) wreaking mass havoc in Vista and Windows 7 systems years ago (literally hundreds of people per day sought BSOD help and the cause turned out to be asacpi.sys - even though it was never, ever mentioned in a dump - my theory is that because it is a boot driver, something else set it off long after boot-up), but all has been quiet since 2008-2009 as many have updated it, I guess. But now I see a 2012 version of the Asus driver in your now-Windows 10 system and cannot help but wonder if it is involved in your BSODs, especially since you did not report BSODs while the system was running Windows 7.

The driver belongs to Asus - it is some form of an Asus Utility driver - it is known as "ATK0110" -

Code:
ASACPI.sys   Thu Nov  1   21:54:34   2012 (509327DA)
Find an update for it - Driver Reference Table (DRT) | ASACPI.sys

Regards. . .

jcgriff2


BSOD DUMP SUMMARY

Code:
Built by: 18362.1.amd64fre.19h1_release.190318-1202
Debug session time: Thu Oct 17 20:44:29.085 2019 (UTC - 4:00)
System Uptime: 0 days 0:17:10.803
BugCheck 109, {a39fc9e52c18d6f6, b3b6d66b7e9b0b43, ffff8a8c8f9ae530, 1c}
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
BUGCHECK_STR:  0x109
PROCESS_NAME:  System
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
Built by: 18362.1.amd64fre.19h1_release.190318-1202
Debug session time: Thu Oct 17 18:17:54.330 2019 (UTC - 4:00)
System Uptime: 0 days 0:32:02.048
BugCheck 109, {a39ff35929d027a7, b3b6ffdf7c525bf4, ffff940993ad6970, 1c}
*** WARNING: Unable to verify timestamp for win32k.sys
*** ERROR: Module load completed but symbols could not be loaded for win32k.sys
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
BUGCHECK_STR:  0x109
PROCESS_NAME:  System
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
Built by: 18362.1.amd64fre.19h1_release.190318-1202
Debug session time: Thu Oct 17 18:38:28.493 2019 (UTC - 4:00)
System Uptime: 0 days 0:19:23.212
BugCheck 109, {a39fe367bff9e59a, b3b6efee127c19b7, ffffa40f304e1970, 1c}
*** WARNING: Unable to verify timestamp for win32k.sys
*** ERROR: Module load completed but symbols could not be loaded for win32k.sys
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
BUGCHECK_STR:  0x109
PROCESS_NAME:  System
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
Built by: 18362.1.amd64fre.19h1_release.190318-1202
Debug session time: Thu Oct 17 14:19:41.836 2019 (UTC - 4:00)
System Uptime: 0 days 0:29:56.552
BugCheck 109, {a39ff35e00d2b5d2, b3b6ffe45355edff, ffffb4056e4ce7b0, 1c}
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
BUGCHECK_STR:  0x109
PROCESS_NAME:  System
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``







Author: jcgriff2 at 12:48 0 comments  

Just updated from 7 to 10 and getting random 0x00000109 blue screens

Friday, October 18, 2019

Just updated from 7 to 10 and getting random 0x00000109 blue screens



https://www.bleepingcomputer.com/forums/t/706220/just-updated-from-7-to-10-and-getting-random-0x00000109-blue-screens/



Hi. . .

All 4 dumps were nearly identical with bugcheck 0x109 - CRITICAL_STRUCTURE_CORRUPTION

This bugcheck appears when when the kernel detects that critical kernel code or
data have been corrupted.

There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
2) A developer attempted to set a normal kernel breakpoint using a kernel
 debugger ..... THIS DOES NOT APPLY HERE TO YOU
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data is either bad or some other underlying hardware failure occurred that affects RAMs ability to properly hold kernel code - like extreme heat; PSU failure; motherboard, etc... - any piece of hardware that could affect RAM.

#1 seems to be a possibility to me given an Asus Utility driver that I found in your loaded [into RAM] driver listing in all 4 dumps that wreaked absolute havoc during the later days of Vista/early days of Windows 7. Windows 8 and 8.1 were not immune, either. However, I have not seen much negative activity regarding this driver and Windows 10.  But if ever there was a driver to attempt to modify critical kernel code, it would be this Asus ATK0110 driver.

I used to see this driver (a 2004 version) wreaking mass havoc in Vista and Windows 7 systems years ago (literally hundreds of people per day sought BSOD help and the cause turned out to be asacpi.sys - even though it was never, ever mentioned in a dump - my theory is that because it is a boot driver, something else set it off long after boot-up), but all has been quiet since 2008-2009 as many have updated it, I guess. But now I see a 2012 version of the Asus driver in your now-Windows 10 system and cannot help but wonder if it is involved in your BSODs, especially since you did not report BSODs while the system was running Windows 7. 

The driver belongs to Asus - it is some form of an Asus Utility driver -
ASACPI.sys   Thu Nov  1   21:54:34   2012 (509327DA)


Regards. . .

jcgriff2


BSOD DUMP SUMMARY
Built by: 18362.1.amd64fre.19h1_release.190318-1202
Debug session time: Thu Oct 17 20:44:29.085 2019 (UTC - 4:00)
System Uptime: 0 days 0:17:10.803
BugCheck 109, {a39fc9e52c18d6f6, b3b6d66b7e9b0b43, ffff8a8c8f9ae530, 1c}
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
BUGCHECK_STR:  0x109
PROCESS_NAME:  System
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
Built by: 18362.1.amd64fre.19h1_release.190318-1202
Debug session time: Thu Oct 17 18:17:54.330 2019 (UTC - 4:00)
System Uptime: 0 days 0:32:02.048
BugCheck 109, {a39ff35929d027a7, b3b6ffdf7c525bf4, ffff940993ad6970, 1c}
*** WARNING: Unable to verify timestamp for win32k.sys
*** ERROR: Module load completed but symbols could not be loaded for win32k.sys
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
BUGCHECK_STR:  0x109
PROCESS_NAME:  System
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
Built by: 18362.1.amd64fre.19h1_release.190318-1202
Debug session time: Thu Oct 17 18:38:28.493 2019 (UTC - 4:00)
System Uptime: 0 days 0:19:23.212
BugCheck 109, {a39fe367bff9e59a, b3b6efee127c19b7, ffffa40f304e1970, 1c}
*** WARNING: Unable to verify timestamp for win32k.sys
*** ERROR: Module load completed but symbols could not be loaded for win32k.sys
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
BUGCHECK_STR:  0x109
PROCESS_NAME:  System
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
Built by: 18362.1.amd64fre.19h1_release.190318-1202
Debug session time: Thu Oct 17 14:19:41.836 2019 (UTC - 4:00)
System Uptime: 0 days 0:29:56.552
BugCheck 109, {a39ff35e00d2b5d2, b3b6ffe45355edff, ffffb4056e4ce7b0, 1c}
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
BUGCHECK_STR:  0x109
PROCESS_NAME:  System
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
  
 

Author: jcgriff2 at 11:42 0 comments  

Windows 10 BSOD

Saturday, October 12, 2019

https://forums.tomshardware.com/threads/bsod-while-in-games.3533249/#post-21344600



Hi. . .

I processed your 5 mini kernel dumps.

There were 3 different bugchecks; no 3rd party driver was named; "Unknown_Image" and "Unknown_Module" were littered throughout the dumps (in place of driver names). All of these items are indicative of unknown hardware failure being the cause.

The bugchecks and listed causes:
Code:
BugCheck 1E, {ffffffffc0000005, 0, 8, 0}
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
BugCheck A, {10, 2, 1, fffff8064b0c20a4}
Probably caused by : USBPORT.SYS ( USBPORT!USBPORT_Core_iMapTransfer+45e )
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
BugCheck A, {ffff848889c21d5d, 2, 1, fffff80543cbcca0}
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
BugCheck 7F, {8, ffff96011174ff90, 0, fffff800306c6617}
Probably caused by : memory_corruption
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
BugCheck A, {30, 5, 0, fffff80245402b65}
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
Also, "NT" (the Windows Kernel) could not be found in most of the dumps.

Code:
***** Debugger could not find nt in module list,
module list might be corrupt
The fact that "Unknown_Module" was listed in the place of driver names tells me that memory corruption occurred.

Basically, for an app or driver to run, it must be loaded into RAM from the hard drive. When it is no longer needed, the object is unloaded from RAM to make room for other objects that need RAM to run.

Something appears to be affecting your RAM. It could be that RAM itself is bad or it could be an underlying piece of hardware like the PSU, motherboard, excessive heat (is your system internally clean?), etc... that is affecting RAMs ability to properly hold kernel code.

Run hardware diagnostics -
Regards. . .

jcgriff2

SUMMARY
Code:
Loading Dump File [C:\Users\PalmDesert\_jcgriff2_\dbug\__Kernel__\100919-6406-01.dmp]
*** WARNING: Unable to verify timestamp for Unknown_Module_00000000`00000000
Debug session time: Wed Oct  9 10:37:25.056 2019 (UTC - 4:00)
System Uptime: 0 days 0:16:46.822
*** WARNING: Unable to verify timestamp for Unknown_Module_00000000`00000000
*** WARNING: Unable to verify timestamp for Unknown_Module_00000000`00000000
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
DEFAULT_BUCKET_ID:  CORRUPT_MODULELIST_0x1E
BUGCHECK_STR:  0x1E
FAILURE_BUCKET_ID:  CORRUPT_MODULELIST_0x1E
Bugcheck code 0000001E
Arguments ffffffff`c0000005 00000000`00000000 00000000`00000008 00000000`00000000
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
Loading Dump File [C:\Users\PalmDesert\_jcgriff2_\dbug\__Kernel__\100719-6265-01.dmp]
Built by: 18362.1.amd64fre.19h1_release.190318-1202
Debug session time: Mon Oct  7 15:05:09.957 2019 (UTC - 4:00)
System Uptime: 0 days 0:31:10.723
Probably caused by : USBPORT.SYS ( USBPORT!USBPORT_Core_iMapTransfer+45e )
DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT
BUGCHECK_STR:  AV
PROCESS_NAME:  destiny2.exe
FAILURE_BUCKET_ID:  AV_USBPORT!USBPORT_Core_iMapTransfer
Bugcheck code 0000000A
Arguments 00000000`00000010 00000000`00000002 00000000`00000001 fffff806`4b0c20a4
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
Loading Dump File [C:\Users\PalmDesert\_jcgriff2_\dbug\__Kernel__\100719-5515-01.dmp]
*** WARNING: Unable to verify timestamp for Unknown_Module_00000000`00000000
Debug session time: Mon Oct  7 12:48:10.080 2019 (UTC - 4:00)
System Uptime: 0 days 0:46:48.845
*** WARNING: Unable to verify timestamp for Unknown_Module_00000000`00000000
*** WARNING: Unable to verify timestamp for Unknown_Module_00000000`00000000
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
DEFAULT_BUCKET_ID:  CORRUPT_MODULELIST_AV
BUGCHECK_STR:  AV
FAILURE_BUCKET_ID:  CORRUPT_MODULELIST_AV
Bugcheck code 0000000A
Arguments ffff8488`89c21d5d 00000000`00000002 00000000`00000001 fffff805`43cbcca0
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
Loading Dump File [C:\Users\PalmDesert\_jcgriff2_\dbug\__Kernel__\100719-5437-01.dmp]
Built by: 18362.1.amd64fre.19h1_release.190318-1202
Debug session time: Mon Oct  7 12:00:50.286 2019 (UTC - 4:00)
System Uptime: 0 days 1:02:31.051
*** WARNING: Unable to verify timestamp for win32k.sys
*** ERROR: Module load completed but symbols could not be loaded for win32k.sys
Probably caused by : memory_corruption
BUGCHECK_STR:  0x7f_8
DEFAULT_BUCKET_ID:  CODE_CORRUPTION
PROCESS_NAME:  System
FAILURE_BUCKET_ID:  MEMORY_CORRUPTION_STRIDE
Bugcheck code 0000007F
Arguments 00000000`00000008 ffff9601`1174ff90 00000000`00000000 fffff800`306c6617
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
Loading Dump File [C:\Users\PalmDesert\_jcgriff2_\dbug\__Kernel__\100719-5453-01.dmp]
*** WARNING: Unable to verify timestamp for Unknown_Module_2b75d79f`aebb2302
*** ERROR: Module load completed but symbols could not be loaded for Unknown_Module_2b75d79f`aebb2302
Debug session time: Mon Oct  7 10:39:32.454 2019 (UTC - 4:00)
System Uptime: 2 days 5:13:06.651
*** WARNING: Unable to verify timestamp for Unknown_Module_2b75d79f`aebb2302
*** ERROR: Module load completed but symbols could not be loaded for Unknown_Module_2b75d79f`aebb2302
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
DEFAULT_BUCKET_ID:  CORRUPT_MODULELIST_AV
BUGCHECK_STR:  AV
FAILURE_BUCKET_ID:  CORRUPT_MODULELIST_AV
Bugcheck code 0000000A
Arguments 00000000`00000030 00000000`00000005 00000000`00000000 fffff802`45402b65
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
Last edited: 

Author: jcgriff2 at 10:59 0 comments  

BSOD while in games

Thursday, October 10, 2019

https://forums.tomshardware.com/threads/bsod-while-in-games.3533249/#post-21345647

BSOD while in games



Memory Corruption



unknown_module

Author: jcgriff2 at 11:34 0 comments  

Problem with battleye >< (Never happen to me but after I formatted my laptop)

Saturday, October 5, 2019

Battle-eye anti-cheat driver 




BEDaisy.sys  Thu Mar 21 02:57:59 2019 (5C936027)
https://www.sysnative.com/drivers/driver.php?id=BEDaisy.sys 

Author: jcgriff2 at 08:21 0 comments  

Subscribe to: Posts (Atom)

Text

Powered by Blogger.

Search This Blog

Popular Posts