After hard drive updated to SSD and memory upgrade Windows freezes and throw BSoD en less than 30 minutes, it works fine under Linux
I have an Asus Vivobook X505ZA that had 8G on board and a 1TB standard hard drive.
I decided to upgrade the hard drive to a 420 GB SSD and add 16GB (1 slot) for a total of 24GB of RAM
That memory is a Samgsun of 2400Mhz that is being detected fine by the BIOS and memory diagnosis tools have label as "passed tests"
I had my Windows 10 Pro ISO that used to work before, so used that one, the installation goes well and fast, but after using windows for a couple of minutes I get BSoD with one of these errors
- clock-watchdog-timeout (most frequent one)
- IRQL_NOT_LESS_OR_EQUAL
I have tried installing Chipset drivers, and updating all drivers (including Radeon Vega 8 driver) and also using the AVG Driver Updater, and all processes finish fine, but the BSoD continues usually in less than 30 minutes.
I have also tried with Windows updates, but they get stuck at 0% or 15% of download but always fail to install. With the windows upgrade assistant It downloaded after 3 reboots and it installed after other 3 reboots and then Windwos EFI loader got corrupted
I have tried using other more recent builds of Windows ISO files but they dont even load the installation proccess, the same USB works on other Laptop, In total I have made close to 10 Windows installations that all behave the same
I have enabled/disable CSM support and disable secure boot.
I have flashed my BIOS to the most recent version 313 and also the previous one 312 with the same issues.
I know that Linux has a much smaller memory foot-print so that might be the reason that I'm not seeing the issues there (that and of course a more robust driver arquitecture)
The initial upgrade has done with a Crucial memory of 16GB of up to 2666 MHz but I changed that to the Samsung one and still the same issues.
So What else can I try to Windows 10 work on this new configuration ? what can be causing all this ?
UPDATE of WinDbg information of the BSoD
Microsoft (R) Windows Debugger Version 10.0.19041.685 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Windows\Minidump\050821-38437-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: srv*
Executable search path is:
Windows 10 Kernel Version 10240 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 10240.16384.amd64fre.th1.150709-1700
Machine Name:
Kernel base = 0xfffff803`d368b000 PsLoadedModuleList = 0xfffff803`d39aff30
Debug session time: Sat May 8 17:33:23.148 2021 (UTC - 7:00)
System Uptime: 0 days 0:10:22.875
Loading Kernel Symbols
...............................................................
................................................................
..............................
Loading User Symbols
For analysis of this file, run !analyze -v
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
CLOCK_WATCHDOG_TIMEOUT (101)
An expected clock interrupt was not received on a secondary processor in an
MP system within the allocated interval. This indicates that the specified
processor is hung and not processing interrupts.
Arguments:
Arg1: 0000000000000018, Clock interrupt time out interval in nominal clock ticks.
Arg2: 0000000000000000, 0.
Arg3: ffffd0009ec80180, The PRCB address of the hung processor.
Arg4: 0000000000000005, The index of the hung processor.
Debugging Details:
------------------
KEY_VALUES_STRING: 1
Key : Analysis.CPU.Sec
Value: 3
Key : Analysis.DebugAnalysisProvider.CPP
Value: Create: 8007007e on DESKTOP-E896S63
Key : Analysis.DebugData
Value: CreateObject
Key : Analysis.DebugModel
Value: CreateObject
Key : Analysis.Elapsed.Sec
Value: 4
Key : Analysis.Memory.CommitPeak.Mb
Value: 71
Key : Analysis.System
Value: CreateObject
BUGCHECK_CODE: 101
BUGCHECK_P1: 18
BUGCHECK_P2: 0
BUGCHECK_P3: ffffd0009ec80180
BUGCHECK_P4: 5
FAULTING_PROCESSOR: 5
CUSTOMER_CRASH_COUNT: 1
PROCESS_NAME: System
STACK_TEXT:
fffff803`d530bc18 fffff803`d37f1801 : 00000000`00000101 00000000`00000018 00000000`00000000 ffffd000`9ec80180 : nt!KeBugCheckEx
fffff803`d530bc20 fffff803`d3695826 : 00000000`00000000 00000000`00005cd0 00000000`0000000c fffff803`d39ee180 : nt! ?? ::FNODOBFM::`string'+0xb001
fffff803`d530bcb0 fffff803`d369622d : 00000000`00000000 00000000`000013d6 00000000`00005cd0 00000000`00000001 : nt!KiUpdateRunTime+0x56
fffff803`d530bd10 fffff803`d361caa6 : 00000124`5499068c 00000000`00000000 ffffd000`9f769340 00000000`00000000 : nt!KeClockInterruptNotify+0x53d
fffff803`d530bf40 fffff803`d375a327 : fffff803`d36662e0 fffff803`d3832c65 00000000`00000002 00000000`00000000 : hal!HalpTimerClockInterrupt+0x56
fffff803`d530bf70 fffff803`d37d8fea : fffff803`d36662e0 fffff803`d39ee180 00000000`00000001 00000000`00000002 : nt!KiCallInterruptServiceRoutine+0x87
fffff803`d530bfb0 fffff803`d37d9417 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiInterruptSubDispatchNoLockNoEtw+0xea
ffffd000`9f769340 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiInterruptDispatchNoLockNoEtw+0x37
SYMBOL_NAME: nt! ?? ::FNODOBFM::`string'+b001
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
IMAGE_VERSION: 10.0.10240.16384
STACK_COMMAND: .thread ; .cxr ; kb
BUCKET_ID_FUNC_OFFSET: b001
FAILURE_BUCKET_ID: CLOCK_WATCHDOG_TIMEOUT_VRF_nt!_??_::FNODOBFM::_string_
OS_VERSION: 10.0.10240.16384
BUILDLAB_STR: th1
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
FAILURE_ID_HASH: {ee16f05f-246b-d0d7-9e9a-d626b64c0212}
Followup: MachineOwner
Bug Check 0x101: CLOCK_WATCHDOG_TIMEOUT
The CLOCK_WATCHDOG_TIMEOUT bug check has a value of 0x00000101. This indicates that an expected clock interrupt on a secondary processor, in a multi-processor system, was not received within the allocated interval.
CLOCK_WATCHDOG_TIMEOUT Parameters
The following parameters are displayed on the blue screen.
Parameter Description
1 Clock interrupt time-out interval, in nominal clock ticks
2 0
3 The address of the processor control block (PRCB) for the unresponsive processor
4 0
Cause The specified processor is not processing interrupts. Typically, this occurs when the processor is nonresponsive or is deadlocked.
From https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x101---clock-watchdog-timeout
Your second error is here https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0xa--irql-not-less-or-equal. This is usually a driver error. You can use Driver Verifier if the message doesn't have the driver's name- type verifier in Start - Run (Winkey+R) and follow the wizard.
Dump Files
Dump files are files containing the state of the machine when it crashed. We can analyse the file to identify the driver (or program) causing the crash. See the last section on how to get them analysed by a volunteer.
Analyse Dump Files
If you want to analyse your own dump files.
You need to access the files in C:\windows\Minidump. Right click WinDbg and choose Run As Administrator.
Download and install Debugging Tools for Windows
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/
Install the Windows SDK but just choose the debugging tools.
Create a folder called Symbols in C:\
Start Windbg. File menu - Symbol File Path and enter
srv*C:\symbols*http://msdl.microsoft.com/download/symbols
Close and reopen WinDbg. File menu - Open Crash Dump
This will analyse the crash dump. You need to close and reopen WinDbg for each dump file analysed. Because you are downloading symbols from the internet WinDbg will appear to be doing nothing. But it's downloading. Be patient.
You are looking for a driver or system library that the crash occurred in at the end of the listing. Find the file, right click then Properties - Details tab. If it shows a driver you'll need to update the driver identified.
After taking the computer to a official ASUS support and paying to get a diagnosis of "yes sr,Windows is producing a blue screen of death" combined with a "you have an issue with your mother board and (new) ssd drive"
I decided to give it another try.
It seems the issue was with all the ISO files that I tried, either because they got corrupted or because they where too old and did not handle the SSD correctly
So i created a ISO file using the Windows 10 Medial Tool creator https://www.microsoft.com/en-us/software-download/windows10
Used rufus to crete a MBR/UEFI USB with Windows 10 21H1 and it worked like a charm.