New
#101
If you mean fast startup (in power options), yes I disabled that a long time ago, I did that the first time I tried 1809 back in October and had issues. I checked to see if the setting has stuck now I'm on 1903, and it has.
If you mean fast startup (in power options), yes I disabled that a long time ago, I did that the first time I tried 1809 back in October and had issues. I checked to see if the setting has stuck now I'm on 1903, and it has.
Disabling Fast startup would prevent the computer from hibernating when told to shutdown through the physical power button and menus but it could still go through a sleep/wake cycle from closing the lid or if the Power Options are set to sleep after a period of inactivity. It might be worth a try if you hadn't also changed those settings.
I've had a few bugchecks from an idle screen on a fresh boot, with no sleep/wake cycles.
Here's another dump for good measure, ckcl running and paging exec still disabled.
MEMORY15.zip - Google Drive
1) Check the motherboard manual and view the motherboard.
2) Different driver versions have caused recurrent BSOD.
3) Are you able or unable to remove Intel wireless hardware?
4) Are you able or unable to use only Eternet or cat5e internet connection?
5) Are you able or unable to use only a USB wireless?
Code:Netwbw02.sys Mon Sep 3 05:14:07 2018 (5B8D096F)Code:NETwNb64 Intel(R) Wireless Adap Intel(R) Wireless Adap Kernel Manual Running OK TRUE FALSE 749,568 2,179,072 0 03/09/2018 11:14:07 C:\WINDOWS\system32\drivers\Netwbw02.sys 4,096Code:Name [00000002] Intel(R) Dual Band Wireless-AC 3160 Adapter Type Ethernet 802.3 Product Type Intel(R) Dual Band Wireless-AC 3160 Installed Yes PNP Device ID PCI\VEN_8086&DEV_08B3&SUBSYS_81708086&REV_CB\E4F89CFFFF508B7E00 Last Reset 19/06/2019 20:31 Index 2 Service Name NETwNb64 IP Address 169.254.55.221, fe80::3417:1c50:fa1:37dd, fdaa:bbcc:ddee:0:89:6687:6aa2:e7ea, 2a00:23c6:a10f:3a00:89:6687:6aa2:e7ea, fdaa:bbcc:ddee:0:3417:1c50:fa1:37dd, 2a00:23c6:a10f:3a00:3417:1c50:fa1:37dd IP Subnet 255.255.0.0, 64, 128, 128, 64, 64 Default IP Gateway fe80::a608:f5ff:fe67:b249 DHCP Enabled Yes DHCP Server 255.255.255.255 DHCP Lease Expires 31/10/1932 09:35 DHCP Lease Obtained 30/10/1932 09:35 MAC Address E4:F8:9C:50:8B:7E Memory Address 0xB1100000-0xB1101FFF IRQ Channel IRQ 4294967289 Driver C:\WINDOWS\SYSTEM32\DRIVERS\NETWBW02.SYS (18.33.14.3, 3.43 MB (3,595,472 bytes), 12/10/2018 14:25)
That's odd, I didn't update that wireless driver, it was on 17.5.0.5 (auto installed after I removed device in dev mgr and rebooted). I have checked and I still have WU driver updates disabled, and I haven't run the Intel DSA. How has it updated itself?
For information, 18.33.14.3 isn't the latest driver available from Intel. So don't know where that's come from.
The prior post was updated while you were posting and this may not have been seen:
1) Check the motherboard manual and view the motherboard.
2) Different driver versions have caused recurrent BSOD.
3) Are you able or unable to remove Intel wireless hardware?
4) Are you able or unable to use only Eternet or cat5e internet connection?
5) Are you able or unable to use only a USB wireless?
It's a laptop with built-in wireless so I'm not able to remove the hardware. Unfortunately I don't have an ethernet port either. I'm not sure I have a USB wifi dongle, but I may be able to get hold of one.
I have a funny feeling the wifi driver isn't the issue, but rather is falling victim to another driver misbehaving.
If you add to that the fact that all wifi driver versions I've had run without incident in v1803, plus a growing number of other Toshiba users are reporting similar problems, some with different wireless hardware, I think by process of elimination it's looking like a Toshiba driver problem, apparent in v1809 and above. That's just what it's starting to seem like to me.
On other computers I'm using windows 1607 and 1709 so you may need to do that while waiting for a Tohiba solution.
At this time you can:
a) make a backup image
b) save the image to another drive or to the cloud
c) clean install windows 1803
d) stress test drivers with windows 1803
e) if stress testing confirms that there are no problems then block windows uprades
f) alternatively use a USB dongle and uninstall / disable Intel wireless
I've just rebooted from a bugcheck, and something is different now, the mouse pointer is jerking really badly, like continuously doing it. What could be causing that? I'm pretty sure if I reboot again it will fix it. It did last time.
Interestingly, it's only the mouse pointer, the touchscreen is behaving fine.
Just thought I may be able to look somewhere to see what's interfering with it?
Last edited by spark001uk; 20 Jun 2019 at 12:36.
I learned from this blog post that since we can get the addresses from the etl trace and the symbols exist in the dump we can actually use the address to find the name of the function being called using the "ln" command in WinDbg. Looking at memory15.dmp shows this:I believe AmliWatchdogInitiateBugcheck is just a function which gets called to trigger a watchdog bugcheck so not very interesting.Code:0: kd> ln 0xFFFFF807814E2AC0 Browse module Set bu breakpoint (fffff807`814e2ac0) ACPI!AmliWatchdog | (fffff807`814e2b1c) ACPI!AmliWatchdogInitiateBugcheck Exact matches: 0: kd> ln 0xFFFFF80781488F70 Browse module Set bu breakpoint (fffff807`81488f70) ACPI!ACPIInterruptDispatchEventDpc | (fffff807`814892ac) ACPI!ACPIWakeRemoveDevicesAndUpdate Exact matches: ACPI!ACPIInterruptDispatchEventDpc (void) 0: kd> ln 0xFFFFF8077C12BCD0 Browse module Set bu breakpoint (fffff807`7c12bcd0) nt!KiEntropyDpcRoutine | (fffff807`7c12bd30) nt!KeRestoreExtendedProcessorState Exact matches: 0: kd> ln 0xFFFFF80781488DA0 Browse module Set bu breakpoint (fffff807`81488da0) ACPI!ACPIInterruptServiceRoutine | (fffff807`81488ef8) ACPI!CLEAR_PM1_STATUS_BITS Exact matches: ACPI!ACPIInterruptServiceRoutine (void)
ACPIWakeRemoveDevicesAndUpdate is interesting because it suggests the system is trying to wake and/or remove devices and update something.
Perhaps ACPIInterruptServiceRoutine is expecting CLEAR_PM1_STATUS_BITS to be updated but it's not happening. I'm just speculating but it seems plausible. The callstacks all seem to show something waiting on and trying to acquire a spinlock so perhaps it involves those bits.
I suspect it's a Toshiba ACPI implementation bug (either UEFI/BIOS or driver) which has been exposed by newer versions of Windows 10.