PSA: Wireless display (Miracast) support is broken on the Surface Pro [now fixed]

With the release of the Windows 8.1 GA rollup (KB2883200), Microsoft seems to have inadvertently broken wireless display (Miracast) support on the Surface Pro.

Affected users will have trouble discovering Miracast capable devices, such as the NETGEAR Push2TV and ActionTec ScreenBeam.

Fix: New Marvell AVASTAR drivers (14.69.24044.150) are available in, funny enough, the Surface Pro 2 driver and firmware pack. They apply to the Surface Pro as well. I'm told these will eventually be pushed out via WU as well. [added 10/25/2013]

It's not clear where the fault lies, but I suspect we'll be seeing updated wireless drivers (Marvell AVASTAR 350N) in the very near future.

Stay tuned. 

For more information on Miracast support in Windows 8.1, check out my previous article


Surface Pro gets new wireless drivers for Windows 8.1


A keen-eyed buddy of mine, George Roberts, tweeted this morning about new Marvel 88W8797 drivers on Windows Update today. The newer drivers (14.69.24040.136) feature full Windows 8.1 (post-preview) support (i.e. NDIS 6.4) and the required high throughput/low latency improvements needed to properly support scenarios such as wireless display and Skype.

Speaking of wireless display -- some of you may have noticed the feature stopped working on Surface Pro after upgrading from Windows 8.1 Preview to RTM. Well, it's time to turn that frown upside down because after installing these drivers, it's back.

Thanks for the heads up George! supports simpler "+" email aliases too

outlook.png's email aliases are handy extensions of your core email account and can be used for outbound account consolidation or inbound mail categorization. Sounds complicated and hard to set up, but it's not. Paul Thurrott has some tips on setting it up and answers any questions you may have.

But if you're looking to create a cheap and easy inbound-only alias, or want an alias tied to your custom domain name, here's a quick tip: also supports Gmail's "+" aliasing.

For example, mail sent to lands in my inbox at without any additional configuration. It just works. And you can of course set up rules to put these emails into separate folders or delete on sight. (You can replace everything after the + with anything you'd like, as long as it's well formed.)


6tag leaks your account data, stores your private videos


Windows Phone developer Rudy Huyn released his unofficial Instagram clone app called 6tag today. And while I would love to take this moment to clear up misconceptions about how the app works and Huyn's involvement (or lack thereof) with Instagram, I must defer to another day. That's because I must, instead, share some important privacy concerns uncovered by Windows Phone developer Travis La Marr this morning.

6tag sends account data in the clear

To support video uploads, 6tag emulates the way Instagram's official apps work. That is, video is uploaded from the device to intermediate servers for transcoding into a compatible format and size, one step before Instagram. But where 6tag differs is that it sends your private account data -- for example, your username and authentication tokens -- in the clear, along with your video, to a black box server in France (presumably under the author's control) in preparation for a future app update. That means, in theory, a determined individual at a Starbucks armed with a sniffer could take over your Instagram account easy peasy.

Update 2 8/22 @ 4:22am PST:  Rudy, via Twitter, has indicated cookies will now be encrypted with a "512-bit key" in a future update.

But wait, there's more... 

6tag servers keep a copy of your public and private videos, for an unspecified amount of time

6tag's transcoding servers understandably keep uploaded video around for a little bit, giving the phone app time to grab a copy. What's concerning, however, is that uploaded video never seems to get deleted. For example, here's a permalink to a video I published on Instagram hours ago. And here's a video Travis published over a week ago. Yikes.

Update 1 8/22 @ 3:46am PST: Rudy, via Twitter, has confirmed that his server does not remove videos after publishing to Instagram, instead relying on an undocumented 48 hour retention policy. When asked about Travis' week old video, he noted that video was uploaded via the beta, implying they're special, and that beta videos will be wiped "in less than 48h". Travis' video went dark soon after.

6tag doesn't have a privacy policy

Against Windows Phone App Certification Policy 2.8, 6tag does not come bundled with a privacy policy, or at least one I could find. This means users have no clue what data is sent to Instagram or black box servers in France, nor an understanding of how private user data is handled, protected, or destroyed. How this got through Windows Phone Store testing is beyond me.

 Update 3 8/23 @ 3:40pm PST:  A new privacy policy is up.

Call to action: Upgrade to


This is a "FAST PUBLISH" article. The information contained herein is provided as-is in response to emerging issues. As a result of the speed in making it available, the materials may include typographical errors and may be revised at any time. 

Full disclosure: I was compensated as part of an Instagram API reverse engineering effort for the developer of Instance, a competing app in the Windows Phone Store. This was a one time deal. I do not receive compensation based on the success or failure of Instance, nor care about Instagram in general.

Armchair analysis of AX88772 driver pull


Last week, my Windows 8 Secrets co-author, Paul Thurrott, pinged me about the lack of USB Ethernet device support on Windows RT. (He wrote about it too.) He noted the increasingly noisy rumblings of the continued non-availability of a Windows RT driver for ASIX AX88772 chipsets in USB Ethernet devices (like the Pluggable USB2-E100, $13.95). I suspect the reason this is getting any attention is because the driver was once available and worked on Windows RT 8.0. Microsoft later -- without much explanation -- requested a take down of the driver. And as of the latest preview build of Windows RT 8.1, the driver is blocked from installation.

But why?

I reached out to Microsoft and haven't heard back yet and they declined to comment on the matter. But I pillaged my closet and found a ASIX-based dongle and ran it through some tests (with the driver in question) to determine how well it actually worked on Windows RT 8.0.

Here are my results.

It's not Windows RT certified

It's important to note that despite being signed by Microsoft, the ASIX drivers in question are not officially certified for use on Windows RT. I suspect these drivers were supplied to ASIX for internal development or testing and not meant for production use. Running the drivers through Windows Hardware Certification testing reveals a number of problems that likely led to the take down of the driver set.

Lack of network presence offloading

As part of its Windows 8 and Windows RT device certification requirements, Microsoft requires that wired LAN (Ethernet) devices support network presence offloading when used on Connected Standby (CS) systems. Over simplified, this means the device should support entering a low power state and respond to the usual indirect network chatter (i.e. ARP and NS ads) without waking the PC. This behavior improves power management and efficiency on CS systems (e.g. Surface RT).

Missing wake events

Wired LAN devices are also required, again on Connected Standby systems, to support various wake events -- the connection and disconnection of network media. That is, when a cable is connected or disconnected, the device should wake up and do whatever processing needed as a result.

Missing USB Selective Suspend support

In conjunction with the missing wake events (above), my device did not support entering a suspended state by way of USB Selective Suspend. This feature allows for the suspension of an individual port helping conserve battery power.

Other minor nits

Given work on this device began long ago, it's understandable that its driver contains some legacy code that needs cleaning up. My tests reported other nits that I feel are minor but worthy of documentation nevertheless.

So is Microsoft conspiring to kill Ethernet?


No, I'm kidding. Let's be realistic here.

Obviously this driver isn't up to code. Neither Microsoft or its partners want this driver circulating the Internet and causing battery (and possibly stability) chaos on Windows RT. While a beta driver is commonly welcomed over no driver, the release of such would incur costs -- time and money -- for what amounts to a niche audience of RT enthusiasts. Instead, let's just exercise a bit more patience and wait for Microsoft or ASIX to publish updated drivers. (If that doesn't happen though, you do have the option of never upgrading to Windows RT 8.1...)