Several unexpected shutdowns happening over and over according to the error code.
Several unexpected shutdowns happening over and over according to the error code.
Sorry, I'm a bit late to this one. All these dumps are 0x9F bugchecks, indicating that a device failed to complete a power transition in time. The dump parameters give us both the address of the IRP managing the power transition request and the address of the device object for the failing device. The IRP managing the power transition shows that the driver that's failing is Netwtw10.sys, the Intel WiFi driver... Rich (BB code): 4: kd> !irp ffffe309ab4028f0 Irp is active with 7 stacks 5 is current (= 0xffffe309ab402ae0) No Mdl: No System Buffer: Thread 00000000: Irp stack trace. cmd flg cl Device File Completion-Context [N/A(0), N/A(0)] 0 0 00000000 00000000 00000000-00000000 ..... >[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)] 0 0 ffffe309abe18050 00000000 00000000-00000000 Unable to load image Netwtw10.sys, Win32 error 0n2 *** WARNING: Unable to verify timestamp for Netwtw10.sys \Driver\Netwtw10 Args: 00000000 00000001 00000004 00000000 [IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)] 0 e1 ffffe309ac062700 00000000 fffff8020ed2cf80-ffffe309b1085248 Success Error Cancel pending \Driver\vwifibus nt!PopRequestCompletion Args: 00000000 00000001 00000004 00000000 That indicates that the problem device is a wireless adapter. The device object address leads us (via the device node address) to the identity of the failing device... Rich (BB code): 4: kd> !devnode ffffe309a86cea20 DevNode 0xffffe309a86cea20 for PDO 0xffffe309a85bc360 Parent 0xffffe309a858dc40 Sibling 0xffffe309a85c3a20 Child 0xffffe309b4f97b20 InstancePath is " PCI\VEN_8086&DEV_A0F0 &SUBSYS_00748086&REV_20\3&11583659&0&A3" ServiceName is "Netwtw10" State = DeviceNodeStarted (0x30a) @ 2023 Dec 17 12:16:21.688 Previous State = DeviceNodeEnumerateCompletion (0x30f) @ 2023 Dec 17 12:16:21.688 .... StateHistory[17] = Unknown State (0x0) StateHistory[16] = Unknown State (0x0) Flags (0x4c0000f0) DNF_ENUMERATED, DNF_IDS_QUERIED, DNF_HAS_BOOT_CONFIG, DNF_BOOT_CONFIG_RESERVED, DNF_NO_LOWER_DEVICE_FILTERS, DNF_NO_LOWER_CLASS_FILTERS, DNF_NO_UPPER_CLASS_FILTERS CapabilityFlags (0x00002000) WakeFromD3 The hardware identifiers of VEN_8086&DEV_A0F0 in the InstancePath indicate that this device is an Intel AX201 wireless adapter. The first thing to check is the driver, and the version of Netwtw10.sys that you have loaded is 9 months old... Rich (BB code): 4: kd> lmvmnetwtw10 Browse full module list start end module name fffff802`20330000 fffff802`20894000 Netwtw10 T (no symbols) Loaded symbol image file: Netwtw10.sys Image path: Netwtw10.sys Image name: Netwtw10.sys Browse all global symbols functions data Timestamp: Sun Aug 6 17:51:52 2023 (64CFB388) CheckSum: 004F843E ImageSize: 00564000 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4 Information from resource tables: I'd suggest looking for an update for that driver, either from the Lenovo website for your model of laptop or from Intel. If an updated driver doesn't stop the BSODs then you'll need to investigate the card. Laptop wireless cards are generally replaceable, although it's a bit fiddly, and they do occasionally fail.
thanks i updated the driver and rebooted then a little later picked up the laptop again was rebooted Event Viewer exported Windows>System again 12:01pm and 12:09 has the errors https://mega.nz/file/oxAwDDZT#zqM-nI1fTg...t_SArMQfIU new minidump file https://mega.nz/file/UpglWAAI#LBoBCpQxeT...V02Rmljxig event viewer Name resolution for the name client.wns.windows.com timed out after none of the configured DNS servers responded. Client PID 6440. The driver entered RTD3. All the connected devices will be removed from driver's internal state, so it is expected that DeviceDisconnected events will happen. Driver exit RTD3. All the connected devices will now cause DeviceConnected events. The previous system shutdown at 11:54:24 AM on 5/12/2024 was unexpected. (((I'm not seeing the shutdown in event viewer...*** The system has rebooted without cleanly shutting down first. This error could be caused if the system stopped responding, crashed, or lost power unexpectedly. 12:09pm The computer has rebooted from a bugcheck. The bugcheck was: 0x0000009f (0x0000000000000003, 0xffffc70c514c8360, 0xfffff8056a7010f8, 0xffffc70c539ed8e0). A dump was saved in: C:\Windows\Minidump\051224-18187-01.dmp. Report Id: 44c83df4-28d6-4620-a70b-8cd83bec28c8. 12:09pm The operating system started at system time 2024-05-12T16:09:21.500000000Z. The last shutdown's success status was false. The last boot's success status was true. EFI time zone bias: 2047. Daylight flags: 0. Firmware time: 2024-05-12T12:09:20.000000000Z.
That recent dump looks exactly like the rest of them. The error shows up as 0x9F, which means your wireless adapter is Intel's AX201 card. It fails right when power switches off. Since updating the driver didn't fix it, you probably need to replace the hardware. Many old laptop wireless cards broke down before I started, and I've seen others fail too since then.
Go into Device Manager and right-click on your AX201, then pick Properties. Click Power Management tab, and make sure "Allow the computer to turn off this device" stays unchecked. Also, check that version of netwtw10.sys you have is from Feb 22, 2024, but the newest driver from Lenovo goes back to Aug 17, 2021. Where did the new version come from? If it came through Windows Update, then maybe it's okay.
Laptops make drivers tricky because they are often customized just for that specific laptop to help with power saving and other things. A generic driver from Intel won't have those special settings and might cause problems. One thing you can try is getting the driver directly from the Lenovo website, uninstalling the old AX201 driver (right-click it in Device Manager and check the box to remove it), then installing the new one instead.
We know that the Lenovo driver works well with your laptop, so if the computer keeps BSOD-ing with a 0x9F bugcheck code after you switch over, then the AX201 card is likely the problem. You can buy a brand-new AX201 for about $20 online and changing it out isn't too hard.
Last time my graphics card broke, someone suggested getting Intel's stuff and I did that. They might have been the newer drivers for networking and other things, but it seems Windows update is working fine after switching back to the Lenovo 2022 Win11 driver. Let's see if this helps!
It's happening again here: https://mega.nz/folder/MpATmL4L#3RV4W2_yX4I8UcQpV_vOoA. Is it just my wifi adapter? Should I check the minidump instead? My event viewer log says the problem happened after a hibernate or resume, and that "Reset and/or resume count do not match expected values" for ntoskrnl.exe. The Wi-Fi Direct Virtual Adapter had this fatal error: The miniport failed during a power transition to operational power 6062 - Lso was triggered. Also, the Secure Boot update didn't work because Secure Boot isn't enabled on my machine. For details, see that Microsoft link about Secure Boot. A different adapter also hit a Fatal error: The miniport had trouble going from standby back to working. Name resolution for go.microsoft.com timed out because none of the DNS servers answered. Another one timed out for client.wns.windows.com. Client PID 2644 tried connecting but failed because the TCP/IP standard is trying too many times in a row, which often causes data corruption issues. Power Manager asked to stop all inputs with INPUT_SUPPRESS_REQUEST=1. Name resolution for client.wns.windows.com also timed out because no DNS servers replied. The old shutdown at 12:30:56 PM on May 31st was unexpected; the dump file failed to create, so the system rebooted without a clean stop. This can happen if the computer stops responding, crashes unexpectedly, or loses power. The driver WUDFRd for device PCI\VEN_8086&DEV_9A03... couldn't load. Another driver WudfRd failed to load for HID\Vid_8087... twice. The driver also failed to load for device {DD8E82AE-334B...} and USB\VID_1C7A&PID_0576... File System Filter 'Mrvdp' doesn't support bypass IO. Secure Boot update failed again because Secure Boot isn't enabled, pointing to that Microsoft link. Application permission settings don't grant Local Launch for the COM Server application CLSID Windows.SecurityCenter.WscDataProtection and APPID Unavailable to user NT AUTHORITY\SYSTEM SID from LocalHost running in a container; this security rule can be changed via Component Services. An error code 0x145 happened, with sub-code 0xA9 and again 0x1CA after the hibernate/resume mismatch reset. Yesterday I updated my download folder right when I plugged the computer down, then came back and it crashed again today.
It has been working way better lately. I think some humidity or condensation might have caused a few issues recently, but overall, it's been doing its job great. I found an Ax201 for around $11 or so, though I did get a couple more reboots too. I'm probably upgrading to a new laptop eventually. It seems like there is still this very similar bugcheck going on, so I am trying to view the minidump file not sure if that means it is exactly the same problem or something else. https://mega.nz/folder/XosEkaBa#njqFu-lbKSaOjREciRR1aA
That comment sounds weird because we rarely get statements like that. What made you think there was moisture inside? That would hurt a lot more than just get wet. These dumps are all the same, every single one showing 0x9F DRIVER_POWER_STATE_FAILURE bugcheck and they all say it's for Netwwt10.sys driver again - which I can see has been updated since last time. One thing I notice is that you seem to be using Mullvad Wireguard? There are Wireguard drivers loaded and they too are quite old, dating back from 2021... Code: 2> kd> lmDvmmullvad_wireguard Browse full module list start end module name fffff800`57150000 fffff800`571ea000 mullvad_wireguard (deferred) Image path: mullvad-wireguard.sys Image name: mullvad-wireguard.sys Browse all global symbols functions data Timestamp: Wed Dec 1 14:13:35 2021 (61A766EF) CheckSum: 0007BB3B ImageSize: 0009A000 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4 Information from resource tables: It's not even far from being possible that this is what's causing the delayed power transitions. Maybe it would be worth uninstalling it and see if those 0x9F BSODs stop.