Surface Book Taskbar Previews close too quickly (when battery status updates)

Mine is defective as well. Surface Pro 4, 12V power supply, Serial# 0D130C0A7W261

All,

This bug is caused by your power supply. You need to get it replaced.

https://dl.dropboxusercontent.com/u/1293973/Bad%20Surface%20Power%20Supplies%20Cause%20Thumbnail%20Previews%20to%20Disappear.docx

If you have this bug, please post the serial number of your power supply to the thread below, so that we can include it in the above document for Microsoft.

Hi Loren,

Let me try that again. I'm stevej at pmFAQtory dotc om.

Regarding seeing the PBT_APMPOWERSTATUSCHANGE messages, we use Microsoft Spy++, which is part of Visual Studio: https://msdn.microsoft.com/en-us/library/aa242713(v=vs.60).aspx.

Generally, there is no such thing as a perfectly flat direct current waveform. The power delivered isn't a steady x watts, but an average from a sinusoidal signal. Whenever you have a Surface power supply plugged into a power source, it's rectifying the signal. It takes a sinusoidal signal from a wall outlet and flattens it out. Think of taking the absolute value of a flattened sinusoidal wave. It still oscillates. You can also have a noisy signal due to weak shielding. Minor voltage spikes can occur. Whether such a real-world, as opposed to ideal, direct current could somehow trigger the Surface power circuits and OS to think that erroneous power state changes (however Microsoft defines those) are occurring is anyone's guess. What could give us some valuable data is for an electrical engineer who works with power supplies to put a (believed to be) defective power supply on a digital oscilloscope, monitor the waveform, and simultaneously monitor power-related events and messages in Spy++ to see what, if any, correlation there is.

This bug could be the result of an interaction among the power supply, the Surface battery (or batteries, in the case of the Surface Book), and the power management code, whether firmware or the OS (including drivers). As Erwin Ried pointed out, to us, the Surface is just a black box. We can see what happens when we make changes, such as swapping out a power supply, or disabling the ACPI-Compliant Battery Control Method driver, but our ability to delve deeper is limited by tool limitations and not knowing much about the Surface architecture, both hardware and software. We can only do so much. At some point, Microsoft has to figure the rest out.

Our goal is to make clear to Microsoft that there  is a real problem, to get them to take action, because this bug is a Windows usability show stopper. This bug has a very long (i.e. years of) history, and Microsoft has never formally acknowledged it. There have been a lot of suggestions as to what to do, from workarounds (such as disabling the ACPI driver, which could lead to overcharging and damaging batteries and disables power management functionality such as time remaining) to swapping out power supplies (which has worked for three people that I'm aware of so far).

The most promising advance we've made to help Microsoft, so far, has been identifying that PBT_APMPOWERSTATUSCHANGE messages cause thumbnail previews to disappear. So, we've been tracking serial numbers of (believed to be) defective power supplies, as well as good ones, on the assumption that it really is defective power supplies that are causing this problem, but this is a tentative conclusion pending further evidence. One experiment that I'd love to try with your SB is to send you this 65W Microsoft power supply, which works perfectly for me on my SP4, to see if you still have #ThumbnailPreviewsDisappear while both your batteries are 100% charged and your SB is plugged in (or under any other circumstances). If you do, then that would give us invaluable information: we'd definitively know that it's not (just) the power supply.

Thanks,

Steve

Steve,

You probably noticed they removed your eMail from the post, and also from my notification. So replying here... 

Apologies if the typeface comes out weird. In Firefox, I can't use "Format" at all. If I switch to Chrome, and try to make the diagram a code block, it insists on changing the entire message. Oh, well...

The 15 Volt adapter is generally much better than any source of 12 volts. Maybe with the lower power draw of the SP4, it is a sufficient improvement. I have the i7 Surface Book with the graphics chip, and under many operating conditions 15 Volts almost hides the problem. But as I said, when I'm on the edge of a battery state transition, like _almost_ fully charged, the state chatters back and forth with CPU loading, and every time the state changes, the previews drop.

The data I think you need to gather from people who see the problem is what state their battery is reporting - or rather which states it is chattering between. And also what the report is when the problem is least apparent. For me, the worst case chatters between "in use" and "fully charged", and since the SB has two batteries, it also chatters between one or the other "in use". If both are severely discharged, it can often stay on "charging" for both of them for longer periods.

In my first post, I said the top line changes to "Not charging", one of the batteries changes to "in use", and then the top line says "Calculating", and then finally they all agree both batteries are charging. I don't notice that any more - I believe one of the major updates removed the "Not charging" and "Calculating" reports. But the state changes still chatter as often, I just see fewer messages.

As for your third-party adapter being an improvement, I see a couple of possibilities. It might put out more than the nominal 12 volts, or less - as might your original MS adapter. Down around 12.2 Volts, my system chatters its worst between "charging" and "fully charged". A bit less and it gives up charging, a bit more and it can hold onto "fully charged" longer. I don't have an OEM 12 Volt adapter to try.

Another possibility is that Microsoft does something tricky with those other contacts on the power plug, and the third-party adapter does not. I was not able to measure anything going on when the plug is not connected to my computer, and obviously can't reach the contacts when it is. I know my pure DC connection just provides the DC on the main pairs of pins.

Here's what I know:

After  Orig    ________    Orig  After

              |        |              

              |        |              

centr  5-10V  |  o||o  |  5-10V  centr

centr  0V     |  o||o  |  0V     N/C  

outer  0V     |  o||o  |  0V     outer

              |   ||   |              

              |   ||   |              

              |   ||   |              

outer  0V     |  o||o  |  0V     outer

N/C    -.03V  |  o||o  |  0V     centr

centr  5-10V  |  o||o  |  5-10V  centr

              |        |              

              |__    __|              

                 |  |                 

                 |  |                 

                 |  |                 

"Orig"inal measurements are voltage relative to the USB -/neutral pin on the charger. (Fluke 87 ohms scale found no connection between USB -/neutral and any fin contact.) Recorded values are from the DC Volt scale with the charger powered. "5-10V" values were recorded (100ms min/max) as minimum 4.5V, maximum 10.2V, with a constant rapid pulsation. The single "-0.03V" reading was solidly repeatable and not present on the opposite mirror image pin. All other pins were below 10 mV. Apparently the power supply is in some kind of seek mode...  

"After"market measurements are Ohms scale connectivity between fin contacts and the center socket or outer sleeve of the 2.1 x 5.5 mm DC plug.

I do know the LED in the Microsoft plug only comes on when the plug is in the computer, so they are sensing things and changing the output in response. The LED in my aftermarket cable is on all the time.

I'm curious what tool or program you're using to see the PBT_APMPOWERSTATUSCHANGE messages. But my view is that they are going to happen regardless of the power supply, and Microsoft just needs to make the taskbar previews ignore them. I can't imagine any reason they should be connected. 

I'm happy to test things on my Surface Book, if the procedure isn't too time consuming...  

Loren

Loren,

Here's one more bit of data.

The Kingdo power adapter's output is:

12 V @ 2.58 A = 30.96 W for the Surface, and

5 V @ 1 A = 5W for the USB plug.

Overall, it produces just under 36 W of power.

I believe that these specs are identical to the ones for the original SP4 adapter, which I no longer have. Perhaps someone else can confirm this.

So, I'm using 12 V on my SP4 right now--the same SP4 that produced #ThumbnailPreviewsDisappear nonstop using Microsoft's original 36 W adapter. And I'm experiencing zero #ThumbnailPreviewsDisappear using this Kingdo 36 W adapter.

Even though I'm only one data point, if my results generalize, then there's no difference between 12 V as opposed to 15 V on #ThumbnailPreviewsDisappear.

Thanks,

Steve

Hi Chris,

I'm very happy that it worked for you, but it's possible that that power supply is just masking the real problem. We don't know yet. It's also possible that if you got another 65W power supply, it *wouldn't* work. At the very least, that swapping power supplies has worked for some of us once again shows that this is some type of power management bug--and possibly a very complicated one.

Could you please post the model number, status (good/defective, where defective=#ThumbnailPreviewsDisappear), and serial number of your various power adapters, and the model of the Surface device(s) that you're using these adapters on? We need as much data as we can get to force Microsoft to get to the bottom of this.

At this point, swapping power supplies is a possible solution, but I worry that we haven't heard the last word on this bug yet.

Thanks,

Steve