BSOD During Application of Update KB4462919

N

ndresang

Member
Joined
Nov 5, 2018
Posts
10
Here are steps:

User is prompted to restart to apply update. Computer restarts. Blue screen indicating updates applying. Then restart again, and you are at Win10 recovery. You must choose start-up repair to get back into windows. Once back in update kb4462919 is pending install. It will download and ask you to restart, and the same process occurs.

Unfortunately the image that this computer is running is applied to 300 other student devices...they are all experiencing this issue. LOL...and not at the same time. Students have limited rights, but nothing excessive. Devices are Azure joined.

I have seen several threads related to this update...and it seems most are resolved by removing or disabling anti-virus software. We just use Windows Defender, and I have tried disabling it and to no avail.

Attached is the BSOD tool log(s). Any advice would be awesome!!
 

Attachments

Code: 
2: kd> .bugcheck
Bugcheck code 1000009F
Arguments 00000000`00000004 00000000`0000012c ffffc809`ea160040 ffff9a0b`ea637a40

0x4 subcode 0x9F bug check, implying a driver (we don't know yet) failed to conform to Windows' power IRP rules within the allotted time period.

Code: 
2: kd> .formats 000000000000012c
Evaluate expression:
  Hex:     00000000`0000012c
  Decimal: 300
  Octal:   0000000000000000000454
  Binary:  00000000 00000000 00000000 00000000 00000000 00000000 00000001 00101100
  Chars:   .......,
  Time:    Wed Dec 31 16:05:00 1969
  Float:   low 4.2039e-043 high 0
  Double:  1.4822e-321

300 second timeout.

When I see this bug check I always check the device itself:

Code: 
2: kd> !sysinfo machineid
Machine ID Information [From Smbios 2.8, DMIVersion 0, Size=1014]
BiosMajorRelease = 5
BiosMinorRelease = 6
BiosVendor = American Megatrends Inc.
BiosVersion = 1.51116.178
BiosReleaseDate = 03/09/2015
SystemManufacturer = Microsoft Corporation
SystemProductName = Surface 3
SystemFamily = Surface
SystemVersion = B16D1SW1C4G1X1
SystemSKU = Surface_3
BaseBoardManufacturer = Microsoft Corporation
BaseBoardProduct = Surface 3
BaseBoardVersion = 00

S3 tablet, a device that involves quite a lot of power management and connection of misc. USB peripherals. It's not surprising to see this bug check on this device.

Code: 
ffffc809ea160040

The 3rd subode contains the thread address that was involved in the code that was handling the driver's lock before the bug check:

Code: 
Child-SP          RetAddr           : Args to Child                                                           : Call Site
ffff9a0b`eebed4d0 fffff803`c4cb2876 : 00000000`00000100 ffffc809`ea160040 ffff9a0b`00000000 ffff9a0b`ffffffff : nt!KiSwapContext+0x76
ffff9a0b`eebed610 fffff803`c4cb206b : ffffc809`ea160040 00000000`00000000 00000000`00000000 ffff9a0b`00000003 : nt!KiSwapThread+0x2c6
ffff9a0b`eebed6e0 fffff803`c4cb178f : ffff9a0b`000000ff 00000000`00000000 fffff803`c4f89500 ffffc809`ea160180 : nt!KiCommitThreadWait+0x13b
ffff9a0b`eebed780 fffff803`c4eaff89 : ffffc809`eb555dc0 fffff803`00000000 ffffc809`e6244a00 ffffc809`e6244a00 : nt!KeWaitForSingleObject+0x1ff
ffff9a0b`eebed860 fffff803`c53fcaf7 : ffffc809`eb555ce0 ffffc809`e6244ad0 ffffc809`e6244ad0 00000000`00000103 : nt!IoReleaseRemoveLockAndWaitEx+0xb2359
ffff9a0b`eebed8a0 fffff803`c5354c86 : ffffc809`e6244ad0 ffff9a0b`eebed9a9 ffffc809`e6244ad0 00000000`00000300 : nt!PopFxUnregisterDevice+0xd7
ffff9a0b`eebed8e0 fffff803`c525f999 : 00000000`ee060001 ffff9a0b`eebed928 ffff9a0b`eebed928 fffff803`c5269023 : nt!PopFxUnregisterDeviceOrWait+0xf5e4a
ffff9a0b`eebed920 fffff803`c525f8bb : 00000000`00000017 ffffc809`e6244ad0 ffffc809`e6244ad0 ffffc809`ecd31800 : nt!PoFxAbandonDevice+0x45
ffff9a0b`eebed950 fffff803`c525f501 : ffff8785`fbe235d0 00000000`00000000 00000000`00000308 ffffc809`e6244ad0 : nt!IopRemoveDevice+0x16b
ffff9a0b`eebeda10 fffff803`c5260723 : ffffc809`e6244ad0 00000000`00000000 ffff9a0b`00000000 00000000`00000000 : nt!PnpSurpriseRemoveLockedDeviceNode+0xb5
ffff9a0b`eebeda70 fffff803`c526046a : 00000000`00000000 ffff9a0b`eebedaf0 ffff8785`fb1eb1b0 ffff8785`fc93f6d0 : nt!PnpDeleteLockedDeviceNode+0x57
ffff9a0b`eebedab0 fffff803`c525e7d7 : ffffc809`ecd31800 00000003`00000002 ffffc809`e8831240 ffff8785`fb1eb1b0 : nt!PnpDeleteLockedDeviceNodes+0xba
ffff9a0b`eebedb20 fffff803`c52622d6 : ffff9a0b`eebedc70 ffff8785`fc93f600 fffff803`c51ba500 00000000`00000003 : nt!PnpProcessQueryRemoveAndEject+0x1df
ffff9a0b`eebedc10 fffff803`c51ba8a3 : ffff8785`fbe235d0 ffff8785`fc93f6d0 ffff8785`fc93f6d0 00000000`00000000 : nt!PnpProcessTargetDeviceEvent+0xee
ffff9a0b`eebedc40 fffff803`c4d11285 : 00000000`00000900 ffffc809`ea160040 fffff803`c51ba5d0 ffffc809`e62c9250 : nt!PnpDeviceEventWorker+0x2d3
ffff9a0b`eebedcc0 fffff803`c4d94e37 : ffffc809`ea160040 00000000`00000080 ffffc809`e62cb040 ffffc809`ea160040 : nt!ExpWorkerThread+0xf5
ffff9a0b`eebedd50 fffff803`c4e4b116 : fffff803`c3e1a180 ffffc809`ea160040 fffff803`c4d94df0 00000708`00000000 : nt!PspSystemThreadStartup+0x47
ffff9a0b`eebedda0 00000000`00000000 : ffff9a0b`eebee000 ffff9a0b`eebe8000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16

This call stack tells me that a peripheral (or something connected to the tablet itself) is being unplugged purposefully by an end-user, or automatically by Windows (a bug we will find) without safely "ejecting" it first - i.e. right clicking a USB driver in task manager and clicking "Eject".

Code: 
nt!PnpSurpriseRemoveLockedDeviceNode+0xb5

Basically Windows is going:

Oh, that thing that was there before is now.... not there, let's clean up its mess by properly removing the device, un-registering it, and remove its lock(s).

Code: 
ffff9a0b`eebed6e0 fffff803`c4cb178f : ffff9a0b`000000ff 00000000`00000000 fffff803`c4f89500 ffffc809`ea160180 : nt!KiCommitThreadWait+0x13b
ffff9a0b`eebed780 fffff803`c4eaff89 : ffffc809`eb555dc0 fffff803`00000000 ffffc809`e6244a00 ffffc809`e6244a00 : nt!KeWaitForSingleObject+0x1ff
ffff9a0b`eebed860 fffff803`c53fcaf7 : ffffc809`eb555ce0 ffffc809`e6244ad0 ffffc809`e6244ad0 00000000`00000103 : nt!IoReleaseRemoveLockAndWaitEx+0xb2359

This is where we go off the rails, for some reason. We attempted to release and remove the lock that was previously held by the device's driver, and we put the thread into a wait state until it could be done. The problem is, it was never completed (at least in time), therefore the 0x9F bug check was called.


Debugging this without:

1. Driver Verifier

or

2. A full kernel dump

is not really possible given we cannot run !locks to check what locks are still being improperly held, and we cannot further disassemble the bug check's code call stack to check anything else.

So from here you have two choices:

Enable Driver Verifier and wait for it to bug check and then upload that, or see if you have a MEMORY.DMP in your C:\Windows folder and upload that somewhere and then paste the link here.
 
First and foremost. Wow. Thank you. I will definitely be donating. :)

Second, as you pointed out it is a Surface 3 device, and I have even disconnected the keyboard after hitting restart & update. Otherwise there are no external peripherals or anything being unplugged. Not sure what it is waiting on.. I will check for the memory.dmp, and also run the driver verifier. :) I will post the results.



Debugging this without:

1. Driver Verifier

or

2. A full kernel dump

is not really possible given we cannot run !locks to check what locks are still being improperly held, and we cannot further disassemble the bug check's code call stack to check anything else.

So from here you have two choices:

Enable Driver Verifier and wait for it to bug check and then upload that, or see if you have a MEMORY.DMP in your C:\Windows folder and upload that somewhere and then paste the link here.
Click to expand...
 
Hi ndresang,

Have you manually checked Windows Update to see if there are any pending updates other than [FONT=Verdana,Arial,Tahoma,Calibri,Geneva,sans-serif]KB4462919 ? Assuming this page is about the Surface 3 with an Atom processor it looks like your UEFI firmware might be out of date. I've seen firmware updates fix 0x9F issues on systems so it might be worth looking into.[/FONT]
 
Hi,

please run a FRST scan so we can gain an insight in what may be interfering:

Step#1 - FRST Scan

1. Please download Farbar Recovery Scan Tool and save it to your Desktop.
Note: You need to run the 64-bit Version so please ensure you download that one.
2. Right click to run as administrator. When the tool opens click Yes to disclaimer.
3. Please ensure you place a check mark in the Addition.txt check box at the bottom of the form before running (if not already).
4. Press Scan button.
5. It will produce a log called FRST.txt in the same directory the tool is run from (which should now be the desktop)
6. Please attach the log back here.
7. Another log (Addition.txt - also located in the same directory as FRST64.exe) will be generated Please also attach that along with the FRST.txt in your reply.
 
Might be a long shot, but after some digging through the threads, I find a lot of references to...

Code: 
        Child-SP          RetAddr           Call Site
        ffff9a0b`eaabc960 fffff803`c4cb2876 nt!KiSwapContext+0x76
        ffff9a0b`eaabcaa0 fffff803`c4cb206b nt!KiSwapThread+0x2c6
        ffff9a0b`eaabcb70 fffff803`c4cb0f67 nt!KiCommitThreadWait+0x13b
        ffff9a0b`eaabcc10 fffff800`4d41b015 nt!KeWaitForMultipleObjects+0x467
        ffff9a0b`eaabccf0 fffff803`c4d94e37 [COLOR=#ff0000]LSMFWfp[/COLOR]+0xb015
        ffff9a0b`eaabcd50 fffff803`c4e4b116 nt!PspSystemThreadStartup+0x47
        ffff9a0b`eaabcda0 00000000`00000000 nt!KiStartSystemThread+0x16

...the Lightspeed Mobile Filter driver, which *may* be our culprit considering schools (like your environment) use this software to manage many devices at once. If we look into the device tree for this:

Code: 
  UserFlags (0x6b8c0b0d)  DNUF_WILL_BE_REMOVED, DNUF_NEED_RESTART, 
                          DNUF_NOT_DISABLEABLE

This is probably why we inevitably throw the 0x9F bug check, because Windows is waiting for the device to release its lock but it's not going to because the device utilizing the driver isn't going to let it disable.

Code: 
2: kd> lmvm LSMFWfp
Browse full module list
start             end                 module name
fffff800`4d410000 fffff800`4d431000   LSMFWfp    (no symbols)           
    Loaded symbol image file: LSMFWfp.sys
    Image path: \SystemRoot\system32\DRIVERS\LSMFWfp.sys
    Image name: LSMFWfp.sys
    Browse all global symbols  functions  data
    Timestamp:        Fri Dec  8 15:16:26 2017

2017, I'd see if the manufacturer has an updated driver.

Code: 
2: kd> !blackboxpnp
    PnpActivityId      : {00000000-0000-0000-0000-000000000000}
    PnpActivityTime    : 131820409131434836
    PnpEventInformation: 3
    PnpEventInProgress : 1
    PnpProblemCode     : 24
    PnpVetoType        : 0
    DeviceId           : PCI\VEN_11AB&DEV_2B38&SUBSYS_045E0002&REV_00\4&38419195&0&00E0

The deviceID is in regards to the Surface device's wireless network controller. PnP code 24 tells us:

Devices stay in this state if they have been prepared for removal. After you remove the device, this error disappears.
Click to expand...


Two things I'd do for now:

1. Update the driver for Lightspeed - If no update, remove the software at least on one system to see if we can still reproduce the crash.

2. If yes, update the Surface device's network drivers, especially wireless, if you have not already.
 
Seriously, cant say enough positive things. This outcome is funny because this isn't happening on our staff devices (same device) just students. The driver is part of the Lightspeed Mobile Web Filter, it redirect traffic to our proxy server when devices are off campus.

The latest version is 6.2.9 and that is what is installed, but obviously that doesn't mean their drivers have been updated. I went ahead an uninstalled the software, did a restart, and then reapplied the update. Still BSOD... Currently getting dump and then uploading.

I will also look at latest device drivers, but those should be fairly updated as well...
 
That looks like the same memory.dmp as before and has a date of [FONT=Verdana,Arial,Tahoma,Calibri,Geneva,sans-serif]Sat Sep 22 01:56:12.329 2018. Are you sure new dump files are being generated?[/FONT]
 
cwsink said:
That looks like the same memory.dmp as before and has a date of Sat Sep 22 01:56:12.329 2018. Are you sure new dump files are being generated?
Click to expand...


Good call. I was curious the dating on the file. I had assumed that maybe system time was off, but no...you are right, that memory dump is old and isn't being replaced. It does hit a STOP error though. So why wouldn't a memory dump ensue? So steps are Restart & Apply Update > Goes to Please Wait, Update Applying> Stop Error with Sad Face, Restart and into windows recovery.


Attached are the SRT files, if that helps any. I noticed in the SrtTrail.txt it refers to a 'Recently serviced boot binary...' Not sure what to look at...

Thanks for any help.

Nick

View attachment Archive.zip
 
Can you provide C:\Windows\Inf\setupapi.dev.log? I'd like to check if there's something relevant written there.

Also, are the students' and the staff devices identical in terms of software/hardware?
 
Things can go so wrong that a dump file doesn't get created and it doesn't look like the crash is being written to the event log, either. The only indication in Event Viewer is "Event ID: 41" which just means Windows wasn't shutdown properly prior to the latest boot. Is there a progress counter on the crash screen indicating it's trying to create a dump and does it show a crash code and/or driver?​
 
softwaremaniac said:
Can you provide C:\Windows\Inf\setupapi.dev.log? I'd like to check if there's something relevant written there.

Also, are the students' and the staff devices identical in terms of software/hardware?
Click to expand...

Yes, both running Surface 3's. Log attached. The only difference between students and staff, staff have admin rights and are on a less restrictive network.


View attachment setupapi.dev.log.zip
 
cwsink said:
Things can go so wrong that a dump file doesn't get created and it doesn't look like the crash is being written to the event log, either. The only indication in Event Viewer is "Event ID: 41" which just means Windows wasn't shutdown properly prior to the latest boot. Is there a progress counter on the crash screen indicating it's trying to create a dump and does it show a crash code and/or driver?​
Click to expand...
Yes it starts and gets to about 60%, and then restarts. My presumption is that it finishes the last 40% quickly...

I will get it to reboot again and find if there is a stop code I can give you.
 
Seems like I have officially broke it. I no longer can use the utility to fix the startup and get back into windows. :(

Here is a copy of the latest. Note the SrtTrail.txt
"Boot configuration is corrupt.
Repair action: Partition table repair"

I will try to get back in (mbr fix, etc.), but like I said it won't be long before another one comes down the pike.
 

Attachments

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

Back
Top