Month: July 2017

Examining DRIVER_POWER_STATE_FAILURE (9f) BSOD

My work computer recently hanged when shutting down to sleep mode.

When booting the computer the next day I realized that it had eventually crashed.

This happened again after disabling hyper-threading, so I decided to investigate.

 

Checked Event Viewer and found:

Log Name: System
Source: Microsoft-Windows-WER-SystemErrorReporting
Event ID: 1001
Task Category: None
Level: Error
Keywords: Classic
Description:
The computer has rebooted from a bugcheck. The bugcheck was: 0x0000009f (0x0000000000000003, 0xfffffa800cd5e060, 0xfffff80000b9a3d8, 0xfffffa802e232590). A dump was saved in: C:\Windows\MEMORY.DMP.

 

Searched online for BSOD 0x0000009f and found:

https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x9f–driver-power-state-failure

 

Examined the memory dump with WinDbg (x64).

Checked for details about the crash with:

!analyze -v

Part of the result:

DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time.
Arguments:
Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
Arg2: fffffa800cd5e060, Physical Device Object of the stack
Arg3: fffff80000b9a3d8, nt!TRIAGE_9F_POWER on Win7 and higher, otherwise the Functional Device Object of the stack
Arg4: fffffa802e232590, The blocked IRP

FAILURE_BUCKET_ID: X64_0x9F_3_POWER_DOWN_Rt64win7_IMAGE_pci.sys

BUCKET_ID: X64_0x9F_3_POWER_DOWN_Rt64win7_IMAGE_pci.sys

FAILURE_ID_HASH_STRING: km:x64_0x9f_3_power_down_rt64win7_image_pci.sys

 

Checked for information about the I/O request packet with:

!irp fffffa802e232590

Result:

Irp is active with 5 stacks 4 is current (= 0xfffffa802e232738)
No Mdl: No System Buffer: Thread 00000000: Irp stack trace.
cmd flg cl Device File Completion-Context
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
>[ 16, 2] 0 e1 fffffa800da84050 00000000 fffff800032ca230-fffffa800eb3bb50 Success Error Cancel pending
*** ERROR: Module load completed but symbols could not be loaded for Rt64win7.sys
\Driver\RTL8167 nt!PopSystemIrpCompletion
Args: 00015400 00000000 00000005 00000003
[ 0, 0] 0 0 00000000 00000000 00000000-fffffa800eb3bb50

Args: 00000000 00000000 00000000 00000000

 

Examined available information about Rt64win7 with:

lmvm Rt64win7

Result:

start end module name
fffff880`05c3a000 fffff880`05d39000 Rt64win7 (no symbols)
Loaded symbol image file: Rt64win7.sys
Image path: \SystemRoot\system32\DRIVERS\Rt64win7.sys
Image name: Rt64win7.sys
Timestamp: Fri Oct 07 11:27:12 2016 (57F76A70)
CheckSum: 0010CDA5
ImageSize: 000FF000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4

 

Found the driver file in Windows explorer under:

C:\Windows\system32\DRIVERS\Rt64win7.sys

Then checked Properties. The details view confirmed that the driver was for the Realtek network interface card, version: 7.103.1007.2016.

 

Decided to look for a newer driver from Realtek.

Found, downloaded and installed the current latest version 7.109.

Unfortunately this was not the solution, the problems continued.

However, later on I discovered that adjusting power options seemed effective.

Android emulator hanging with black screen

I recently experienced a situation where Android Studio’s x86 emulator would not start.

It just showed a black screen with no apparent progress.

 

To investigate I connected Android Device Monitor to the emulator.

LogCat showed a lot of messages and they seemed to repeat over and over.

 

I decided to pause the emulator to examine the log.

Found and followed Christoper Orr’s advice here:

telnet localhost 5554
avd stop

 

Checked the LogCat messages and noticed this section:

I/ServiceManager(16997): Waiting for service SurfaceFlinger...
I/SurfaceFlinger(17248): SurfaceFlinger is starting
I/SurfaceFlinger(17248): SurfaceFlinger's main thread ready to run. Initializing graphics H/W...
D/libEGL(17248): Emulator has vendor provided software renderer, qemu.gles is set to 2.
D/libEGL(17248): loaded /vendor/lib/egl/libEGL_swiftshader.so
D/libEGL(17248): loaded /vendor/lib/egl/libGLESv1_CM_swiftshader.so
D/libEGL(17248): loaded /vendor/lib/egl/libGLESv2_swiftshader.so
D/gralloc_ranchu(17248): Emulator without host-side GPU emulation detected.
E/gralloc_ranchu(17248): Could not find software fallback module!?
E/gralloc_ranchu(17248): [ 07-04 12:54:38.858 17248:17248 E/ ]
E/gralloc_ranchu(17248): connect: failed with fd -1 errno 22
E/gralloc_ranchu(17248): [ 07-04 12:54:38.858 17248:17248 E/ ]
E/gralloc_ranchu(17248): Failed to connect to host (QemuPipeStream)!!!
E/gralloc_ranchu(17248): gralloc: Failed to get host connection
E/SurfaceFlinger(17248): hwcomposer module not found
E/SurfaceFlinger(17248): ERROR: failed to open framebuffer (I/O error), aborting
A/libc(17248): Fatal signal 6 (SIGABRT), code -6 in tid 17248 (surfaceflinger)
A/libc(17248): [ 07-04 12:54:38.858 1319: 1319 W/ ]
A/libc(17248): debuggerd: handling request: pid=17248 uid=1000 gid=1003 tid=17248
I/ServiceManager(17212): Waiting for service SurfaceFlinger...
I/ServiceManager(17212): [ 07-04 12:54:38.860 17256:17256 E/ ]
I/ServiceManager(17212): debuggerd: Unable to connect to activity manager (connect failed: Connection refused)

 

Decided to check the emulator configuration.

Noticed that the emulator was configured to use software graphics.

Changed this to hardware graphics, started the emulator again and noticed that it started normally. The workaround solved the problem.

 

Conclusion

If the Android Studio emulator hangs with a black screen, try checking the LogCat messages and try switching graphics mode.