Bluescreen randomly when internet disconnected

There were 2 new BSOD since the prior V2.

Were the new BSOD between the prior V2 and the reinstallation of the chipset / iGPU drivers?


The last BSOD in the prior V2 was Fri Nov 10 18:57:29.210 2023 (UTC - 6:00)

The newest BSOD were:
Fri Nov 10 21:10:34.102 2023 (UTC - 6:00)
Fri Nov 10 23:19:00.688 2023 (UTC - 6:00)



Windows 11 troubleshooting is typically in Eleven Forum.



These are the applicable links to create a bootable Windows 11 MCT (Windows iso):

Download Official Windows 11 ISO file from Microsoft Tutorial | Windows 11 Forum

https://www.microsoft.com/software-download/windows11

If possible, have both iso available as needed.




Use the computer in the typical fashion for the next 24 - 48 hrs.

Monitor for unexpected shutdowns and restarts using reliability monitor:

View Reliability History in Windows 11 Tutorial | Windows 11 Forum

Yes 2 Bluescreen occurred, one before the reinstallation and second after reinstallation

Ouch sorry if I put my trouble here....
I thought this is for all OS

Did I need to recreate the thread in the 11 forum?


Right now the laptop is in memtest running mode.
I'll create the bootable for the windows 11 also. Is the bootable OS is for repairing the recovery partition that missing? Or I need to reinstall the windows?

The latest BSOD was after the replacement of the chipset / iGPU drivers.

There were no misbehaving drivers.

The computer appears to have malfunctioning hardware.

A working recovery partition is not needed as long as you have either or both:
a) Windows MCT
b) backup images saved to another disk drive or the cloud

Continue in TF.


The Windows 11 MCT can be used for a replacement recovery partition.

The Windows 10 MCT can be used to test the computer using another operating system with new drivers.


There are very limited hardware to swap test on a laptop.

If malfunctioning hardware is confirmed (ruled out RAM and drive) then contact a local computer store or Asus for servicing.

zbook said:

The latest BSOD was after the replacement of the chipset / iGPU drivers.

There were no misbehaving drivers.

The computer appears to have malfunctioning hardware.

A working recovery partition is not needed as long as you have either or both:
a) Windows MCT
b) backup images saved to another disk drive or the cloud

Continue in TF.


The Windows 11 MCT can be used for a replacement recovery partition.

The Windows 10 MCT can be used to test the computer using another operating system with new drivers.


There are very limited hardware to swap test on a laptop.

If malfunctioning hardware is confirmed (ruled out RAM and drive) then contact a local computer store or Asus for servicing.

Thank you very much for the diagnosed

I have the same thought too, probably there are some faulty hardware. Because when I disable the NVIDIA driver and only running in AMD the Bluescreen appear not as much as when the NVIDIA driver is enabled.

Will update here again with the result after 8 pass memtest.


a little bit story, I have bring the device to ASUS Service Center before (around June) but they don't found anything and they said they use their software to check for 4 hours the problem not occurred (the condition is after clean install) and said to me to try change the SSD (I don't have another SSD to check). I used around 2-3 days after clean install and the device is working well, but after I put all of my software used for work the problem occurred again and think the problem was in the OS / software not the hardware.

Make free or pay backup images > clean install Windows 10 with new drivers

If the computer is stable for several days then upgrade to Windows 11 and recheck.

If the computer is unstable with two operating systems and their respective drivers then decide whether to service or replace.


Some backup imaging software:
(Acronis, Aoemi, EaseUS, Macrium, Paragon, etc.)

Backup and Restore with Macrium Reflect

Clean Install Windows 10

(heading to bed; will check the thread later in the day)

Based on the dumps in your most recent V2 log upload I think this is most likely a RAM problem. Several of the dumps have corrupted function call addresses in the call stack, here's an example...

Code:

0: kd> knL
 # Child-SP          RetAddr               Call Site
00 fffff802`171230b8 fffff802`1a22bfa9     nt!KeBugCheckEx
01 fffff802`171230c0 fffff802`1a227634     nt!KiBugCheckDispatch+0x69
02 fffff802`17123200 fffff802`1a122145     nt!KiPageFault+0x474
03 fffff802`17123398 00000000`00000004     nt!KiShouldRearmClockTimer+0x45
04 fffff802`171234c8 ffff800f`e2898101     0x4
05 fffff802`171234d0 00000000`0000000a     0xffff800f`e2898101
06 fffff802`171234d8 00000000`0000000a     0xa
07 fffff802`171234e0 fffff802`15781180     0xa
08 fffff802`171234e8 00000002`ba2c8e5d     0xfffff802`15781180
09 fffff802`171234f0 00000005`00000000     0x00000002`ba2c8e5d
0a fffff802`171234f8 fffff802`17123508     0x00000005`00000000
0b fffff802`17123500 00000002`ba5133a4     0xfffff802`17123508
0c fffff802`17123508 ffffffff`ffffffff     0x00000002`ba5133a4
0d fffff802`17123510 00000000`00000000     0xffffffff`ffffffff

Some of those call addresses are clearly garbage (the 0x00000005`00000000 and 0x00000002`ba2c8e5d for certain, because they are user-mode address). Two dumps have misaligned instruction pointers and two dumps failed because of a stack pointer error. One dump also has a 0xC0000005 exception code (a memory access violation).

You need to test your RAM. One method is to use Memtest86 (free), which will find about 90% of RAM issues if you run it twice, one after the other. The other method is to remove one RAM stick and run on just the other for a day or two - or until you get a BSOD. Then swap sticks and run on just the other stick for a day or two -or until you get a BSOD. This is 100% guaranteed to identify a flaky stick.

ubuysa said:

Based on the dumps in your most recent V2 log upload I think this is most likely a RAM problem. Several of the dumps have corrupted function call addresses in the call stack, here's an example...

Code:

0: kd> knL
 # Child-SP          RetAddr               Call Site
00 fffff802`171230b8 fffff802`1a22bfa9     nt!KeBugCheckEx
01 fffff802`171230c0 fffff802`1a227634     nt!KiBugCheckDispatch+0x69
02 fffff802`17123200 fffff802`1a122145     nt!KiPageFault+0x474
03 fffff802`17123398 00000000`00000004     nt!KiShouldRearmClockTimer+0x45
04 fffff802`171234c8 ffff800f`e2898101     0x4
05 fffff802`171234d0 00000000`0000000a     0xffff800f`e2898101
06 fffff802`171234d8 00000000`0000000a     0xa
07 fffff802`171234e0 fffff802`15781180     0xa
08 fffff802`171234e8 00000002`ba2c8e5d     0xfffff802`15781180
09 fffff802`171234f0 00000005`00000000     0x00000002`ba2c8e5d
0a fffff802`171234f8 fffff802`17123508     0x00000005`00000000
0b fffff802`17123500 00000002`ba5133a4     0xfffff802`17123508
0c fffff802`17123508 ffffffff`ffffffff     0x00000002`ba5133a4
0d fffff802`17123510 00000000`00000000     0xffffffff`ffffffff

Some of those call addresses are clearly garbage (the 0x00000005`00000000 and 0x00000002`ba2c8e5d for certain, because they are user-mode address). Two dumps have misaligned instruction pointers and two dumps failed because of a stack pointer error. One dump also has a 0xC0000005 exception code (a memory access violation).

You need to test your RAM. One method is to use Memtest86 (free), which will find about 90% of RAM issues if you run it twice, one after the other. The other method is to remove one RAM stick and run on just the other for a day or two - or until you get a BSOD. Then swap sticks and run on just the other stick for a day or two -or until you get a BSOD. This is 100% guaranteed to identify a flaky stick.

Hi Ubuysa,

Thank you for the diagnosed.
I will complete my memtest first and then try to run with one RAM and the other. Is I need to do another memtest with one RAM too?

I would forget Memtest and remove one stick. It's a much more reliable test.

Please run Memtest86+ for 8 or more passes.

The more the passes the better the testing conditions.

It sometimes takes passes into the twenties to find malfunctioning RAM.




It may take a day of downtime but documentation of malfunctioning RAM is typically required for warranty replacement.

zbook said:

Please run Memtest86+ for 8 or more passes.

The more the passes the better the testing conditions.

It sometimes takes passes into the twenties to find malfunctioning RAM.




It may take a day of downtime but documentation of malfunctioning RAM is typically required for warranty replacement.

Yes I am still doing the memtest. Now in the 12 passes with 0 error. Let me continue to twenties like you said