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

T

txg

Member
Joined
Mar 13, 2019
Posts
14
Title says it all, just ran the update tool to actually get my PC current. Everything is working great other than the fact I'm getting random crashes every so often now. Particularly when I walk away and leave the computer on for a little while. I don't think it's hard drive or memory related as I'd leave my computer on for weeks without a crash in Win 7.

Thank you for helping me to figure this out!

· OS - Windows 10 x64
· What was the originally installed OS on the system? Windows 7 Premium
· Is the OS an OEM version (came pre-installed on system) or full retail version (YOU purchased it from retailer)? I just ran the MS updater today.
· Age of system (hardware): 8 years
· Age of OS installation - have you re-installed the OS? 1 day

· CPU: AMD Phenom II X6 1050T
· Video Card: NVIDIA GeForce GTS 450
· MotherBoard - (if NOT a laptop): ASUSTeK Computer INC. M4A87TD/USB3 (AM3)
· Power Supply - brand & wattage (if laptop, skip this one): EVGA SuperNOVA 750 G2, 80+ GOLD 750W

· System Manufacturer: Self-built
· Exact model number (if laptop, check label on the bottom)

· Laptop or Desktop? Desktop
 

Attachments

I'll try and have a look at the log files tonight for you, but I suspect that it may due to compatibility issues. Have you ensured that you have installed the Windows 10 versions of your drivers?
 
as always, older stuff in win7:
http://forum.alcohol-soft.com/files/sptdremov.exe
remove your daemontools first, then test your system.
as your system is pretty old, the chance on asustek finding newer drivers (win10) and bios! is probably not any longer available.
Code: 
STACK_TEXT: 
fffffc05`a3067fa8 00000000`00000000 : 00000000`00000109 a39fe367`bff9e59a b3b6efee`127c19b7 ffffa40f`304e1970 : nt!KeBugCheckEx
is all the failing stack has to say.
 
I tried the sptdremov.exe utility and it says "Unable to delete sptd service key". I checked on how to manually remove it and noticed it's already disabled in the registry. I left the computer on overnight and it rebooted itself at least 3 or 4 times from what I can tell.
 
x BlueRobot said:
I'll try and have a look at the log files tonight for you, but I suspect that it may due to compatibility issues. Have you ensured that you have installed the Windows 10 versions of your drivers?
Click to expand...

I will double-check but I installed a new graphics driver but didn't go through line by line in the device manager checking. I can do that today.
 
Should I uninstall the old motherboard drivers (USB, LAN, etc.) and count on the Win10 drivers to replace those?
 
MichaelB said:
as always, older stuff in win7:
http://forum.alcohol-soft.com/files/sptdremov.exe
remove your daemontools first, then test your system.
as your system is pretty old, the chance on asustek finding newer drivers (win10) and bios! is probably not any longer available.
Code: 
STACK_TEXT:
fffffc05`a3067fa8 00000000`00000000 : 00000000`00000109 a39fe367`bff9e59a b3b6efee`127c19b7 ffffa40f`304e1970 : nt!KeBugCheckEx
is all the failing stack has to say.
Click to expand...

The call stack will almost always be empty on Stop 0x109's, best to check the entire thread stack using either !dpx (part of PDE) or using dps with the thread's address range.
 
I've managed to download and get dps / dpx. Entering !dpx tells me that there is no export dpx found. Doing a dps with the address ranges of the minidumpsm only one provides anything readable:

Code: 
ffffc489`00ee2970  fffff807`77babae0 Ntfs!NtfsFsdCreate
ffffc489`00ee2978  fffff807`7291e830 nt!IopInvalidDeviceRequest
ffffc489`00ee2980  fffff807`77bad730 Ntfs!NtfsFsdClose
ffffc489`00ee2988  fffff807`77ac3f80 Ntfs!NtfsFsdRead
ffffc489`00ee2990  fffff807`77aba060 Ntfs!NtfsFsdWrite
ffffc489`00ee2998  fffff807`77bac700 Ntfs!NtfsFsdDispatchWait
ffffc489`00ee29a0  fffff807`77b6d000 Ntfs!NtfsFsdSetInformation
ffffc489`00ee29a8  fffff807`77bac700 Ntfs!NtfsFsdDispatchWait
ffffc489`00ee29b0  fffff807`77bac700 Ntfs!NtfsFsdDispatchWait
ffffc489`00ee29b8  fffff807`77beb9c0 Ntfs!NtfsFsdFlushBuffers
ffffc489`00ee29c0  fffff807`77be77c0 Ntfs!NtfsFsdDispatch
ffffc489`00ee29c8  fffff807`77be77c0 Ntfs!NtfsFsdDispatch
ffffc489`00ee29d0  fffff807`77b93640 Ntfs!NtfsFsdDirectoryControl
ffffc489`00ee29d8  fffff807`77b74c80 Ntfs!NtfsFsdFileSystemControl
ffffc489`00ee29e0  fffff807`77be8ed0 Ntfs!NtfsFsdDeviceControl
ffffc489`00ee29e8  fffff807`7291e830 nt!IopInvalidDeviceRequest
 
Code: 
CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated 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 http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
2) A developer attempted to set a normal kernel breakpoint using a kernel
debugger that was not attached when the system was booted. Normal breakpoints,
"bp", can only be set if the debugger is attached at boot time. Hardware
breakpoints, "ba", can be set at any time.
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
Arg1: a39fe367bff9e59a, Reserved
Arg2: b3b6efee127c19b7, Reserved
Arg3: [COLOR=rgb(0, 0, 255)]ffffa40f304e1970[/COLOR], Failure type dependent information << Exception record?
Arg4: 00000000000000[COLOR=rgb(255, 0, 0)]1c[/COLOR], Type of corrupted region, can be
0 : A generic data region
1 : Modification of a function or .pdata
2 : A processor IDT
3 : A processor GDT
4 : Type 1 process list corruption
5 : Type 2 process list corruption
6 : Debug routine modification
7 : Critical MSR modification
8 : Object type
9 : A processor IVT
a : Modification of a system service function
b : A generic session data region
c : Modification of a session function or .pdata
d : Modification of an import table
e : Modification of a session import table
f : Ps Win32 callout modification
10 : Debug switch routine modification
11 : IRP allocator modification
12 : Driver call dispatcher modification
13 : IRP completion dispatcher modification
14 : IRP deallocator modification
15 : A processor control register
16 : Critical floating point control register modification
17 : Local APIC modification
18 : Kernel notification callout modification
19 : Loaded module list modification
1a : Type 3 process list corruption
1b : Type 4 process list corruption
[COLOR=rgb(255, 0, 0)]1c[/COLOR] : Driver object corruption

[...]

This bugcheck tends to be quite tricky to debug with a Minidump due to the lack of information saved, so I'll try and investigate as thoroughly as possible. The third parameter indicates the type of corruption and in this case a driver object has become corrupt which explains part of your call stack.

I initially thought the third parameter would be a driver object address, however, it seems it is in fact an exception record.

Code: 
0: kd> [COLOR=rgb(65, 168, 95)].exr ffffa40f304e1970[/COLOR]
ExceptionAddress: fffff806119ad730 (Ntfs!NtfsFsdClose)
ExceptionCode: 119abae0
ExceptionFlags: fffff806
NumberParameters: 294403968
Parameter[0]: [COLOR=rgb(255, 0, 0)]fffff806118ba060[/COLOR] << Use ln command on each one to find the nearest matching function
Parameter[1]: fffff806119ac700
Parameter[2]: fffff8061196d000
Parameter[3]: fffff806119ac700
Parameter[4]: fffff806119ac700
Parameter[5]: fffff806119eb9c0
Parameter[6]: fffff806119e77c0
Parameter[7]: fffff806119e77c0
Parameter[8]: fffff80611993640
Parameter[9]: fffff80611974c80
Parameter[10]: fffff806119e8ed0
Parameter[11]: fffff8060ed1e830
Parameter[12]: fffff80611ad9210
Parameter[13]: fffff806118f86c0
Parameter[14]: fffff806119ae6d0

Code: 
0: kd> [COLOR=rgb(65, 168, 95)]ln fffff806118ba060[/COLOR]
Browse module
Set bu breakpoint

(fffff806`118ba060) Ntfs!NtfsFsdWrite | (fffff806`118ba4f0) Ntfs!NtfsCommonWrite
Exact matches:
Ntfs!NtfsFsdWrite (void)

What is the file name of the Minidump you tried? None of them seem to provide anything like the call stack you provided?[/code]
 
There were a few new ones since I posted the thread, I will attach them. The computer rebooted itself several times overnight. I'm not sure if I was running the command correctly though, I was just running "dps ffffa40f`304e1970" with the addresses listed when I ran the "!analyze /v" command in the debugger.
 

Attachments

As I posted elsewhere - :-)



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
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
 
Thanks jcgriff2! I was casting a wider net by posting my question on two forums. I have implemented your advice and am waiting to see what happens. I'm about to step away from the computer for an hour or two so hopefully it'll still be up and running when I get back.
 
I don't blame you for the wide net at all.

One day, you're running Windows 7 with no problems; the next day - upgrade to Windows 10 and you get hit by a BSOD epidemic. It doesn't make much sense.

You've got several very good experts helping now.

John
 
txg said:
I was just running "dps ffffa40f`304e1970" with the addresses listed when I ran the "!analyze /v" command in the debugger.
Click to expand...

Okay, I understand what you've done now, dumped the default range of dps with the exception record address as the start. I'm not sure how accurate it is because I had different function calls when I went through each one with the ln command.
 
Since removing the drivers John mentioned earlier I haven't had a crash as of yet today although I've been on the computer most of the day and it seemed to happen when it was idle. I also removed AsIO.sys and disabled its service as it seemed to be another Asus related driver I no longer needed. I couldn't actually find that service through the gui but disabling it via the command line seems to have worked. I did also change the setting to turn my monitors off when idle. I normally leave my computer on 24/7 so I will see how it does tonight in terms of crashing (or not!). If all goes well, I'll change the setting back for my monitors and see what happens there as well.
 
txg said:
Since removing the drivers John mentioned earlier I haven't had a crash as of yet today although I've been on the computer most of the day and it seemed to happen when it was idle.
Click to expand...
Great news!

txg said:
I also removed AsIO.sys and disabled its service as it seemed to be another Asus related driver I no longer needed. I couldn't actually find that service through the gui but disabling it via the command line seems to have worked.
Click to expand...
Good call.

Yes...asio.sys is definitely another Asus driver that causes BSODs.
 
Hi txg,

Great to hear you haven't had a crash yet.

If you get yet another crash despite all efforts, please remove everything piracy related from your pc first before requesting assistance.

Your logs appear to have entries related to bypassing the activation of one or more programs.
 
txg said:
Since removing the drivers John mentioned earlier I haven't had a crash as of yet today although I've been on the computer most of the day and it seemed to happen when it was idle. I also removed AsIO.sys and disabled its service as it seemed to be another Asus related driver I no longer needed. I couldn't actually find that service through the gui but disabling it via the command line seems to have worked. I did also change the setting to turn my monitors off when idle. I normally leave my computer on 24/7 so I will see how it does tonight in terms of crashing (or not!). If all goes well, I'll change the setting back for my monitors and see what happens there as well.
Click to expand...

That's great, please keep us updated!
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top