Surface Pro Miracast Connection Problem

Anonymous
2018-02-09T02:30:39+00:00

I am essentially re-asking the same question, but in a different manner as it has been two weeks and the problem of the Surface Pro 2 not connecting to our new LG OLED, Miracast-compatible TV remains unresolved.  They do attempt to negotiate a connection, but they fail to connect.

I ran dxdiag on the Surface Pro 2 running Windows 10 with all the latest updates, and the results show the computer is Miracast compatible.  I have also separately checked for updated drivers and the result was that the drivers are up-to-date.


System Information


      Time of this report: 1/25/2018, 09:54:36

      ...

                 Miracast: Available, with HDCP

     ...


Display Devices


           Card name: Intel(R) HD Graphics Family

     ...

            Miracast: Supported

Initial attempts failed every time, even when the Surface is just a few feet from the TV.  Conversely, our HP laptop connects flawlessly every time.  This tends to suggest that the problem is within the Surface computer - not the TV.

I read Barb Bowman's informative article describing how Miracast negotiates a connection and, as a result, I checked the visible 2.4GHz networks around here.  There are four weak ones (~20% strength) on CH1, our own 'main' network on CH6 all by itself, and our own secondary network and two other weak ones on CH11 (78% and ~20% strength, respectively).  I presume the Surface and the TV being just a few feet apart, the related signal strengths would be adequate to override the weaker network signals on CH1 and, therefore, Miracast should be able to negotiate a connection.  The HP computer is 6x further away from the TV and, as mentioned, it connects flawlessly every time.

However, I did spot a difference between our two computers when connecting - namely the IPv4 address indicated for the direct-connection 'adapter'.  The IPv4 Address was 192.168.137.1 for the HP computer (and it was the same for my various acquaintances' computers as well), whereas on the Surface it was indicated as Autoconfiguration IPv4 Address 169.254.56.231.  The IPv4 Subnet Masks were 255.255.255.0 and 255.255.0.0, respectively.

As Miracast is essentially a peer-to-peer connection without a DHCP server to provide an IP address, on the virtual wireless adapter that is active during Miracast connections, I configured the IPv4 'Alternate configuration' to an address of 192.168.137.1, the same IP address that works every time when the HP laptop connects.

I thought I had found the answer as it worked briefly (during a 20-minute test period), and the results were very good .

However, the next day when there was something my wife actually wanted to see on the big-screen TV, she tried again and it failed to connect.  Several attempts were made - all unsuccessful.

A few days later a friend suggested that I try adding the same IP address for the Default gateway and DNS server.  I wasn't sure what good this would do, but I tried and it worked again during an hour of testing (to see if it would drop out - it remained solid).

However, once again, while it worked for the hour or so of testing, later it again failed to connect.  We tried several times throughout the day and again over the next couple of days, but no luck.

I have tried shutting off Bluetooth, and even shutting off the HP computer to eliminate any impact they may have, but the Surface and TV will NOT connect.

The issue is almost certainly within the Surface computer, and I have no idea where else to look.  Can someone from Microsoft please shine some light on this?  There are so many discussions on the web about this problem with Surface computers; so, it must be very widespread and there must be a lot of frustrated Surface owners out there!

Any expert assistance would be appreciated.  Thank you.

Surface | Surface Pro | USB-C

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments No comments

45 answers

Sort by: Newest
  1. Anonymous
    2018-02-11T15:15:46+00:00

    Barb, thanks for the thoughtful and detailed sequence of steps to follow.

    Undoing the changes I made took three attempts, as I have to work fast each time.  That Local Area Connection* only shows up during attempts to connect and when the negotiation fails and times out, it disappears.  Nevertheless, after three attempts with reboots, it was finally undone and back to its original setting.

    Unfortunately your suggested process did not resolve the problem.  Of course, as expected, it put things back to 'square 1' and the result was just as it was in the beginning with the connection failing and the related Local Area Connection* IP address being an Autoconfiguration IPv4 address in the 169.254.xxx.xxx range.  I tried again and checked the properties while the connection negotiation is underway, and found the 'configuration' is identical to that of the HP computer - except for the IP address, that is.  The HP indicates an IPv4 address(not Autoconfiguration IPv4 address) of 192.168.137.1.

    The only two times the Surface has connected with the TV were immediately following my changing the Alternate Configuration for the related Local Area Connection* to 192.168.137.1, which I chose merely because that is the address that my HP computer uses when it connects successfully every time.  I knew that only one computer at a time would be able to connect to the TV, so I presumed there would be no IP conflict - and that is the same address as a few friends' computers have when they successfully connect to their TVs.

    Although I had a 42+ year career in a high tech field, I am not a computerexpert and definitely not all that knowledgeable in networking; so, I do not understand why that same IP address is the one that occurs on all four 'working' connections that I am aware of.

    Following the failure of the Surface to connect after completion of your suggested process, I then turned on the HP laptop again and tried to connect with it.  As usual, it connected very quickly.

    I remain baffled and at a loss as to what to try next.  Your assistance would be very much appreciated.

    Thank you.

    Was this answer helpful?

    0 comments No comments
  2. Anonymous
    2018-02-11T15:13:26+00:00

    I am not sure how to use the Network troubleshooter on the Local Area Connection*, when it only shows up briefly while the connection negotiation is occurring, and it disappears as soon as the connection fails. 

    What version of W10 do you have?  That peek-a-boo behaviour with no chance of using a troubleshooter is what I used to see.  Now with W10 FCU it at least sticks around in Control Panel's Network Adapters (which can be opened from the Settings Network page) but more significantly it also now appears in the Network Diagnostics troubleshooter (which can also be opened from the Settings Network page, who knew?); so I can see it either way--once the Connect dialog (Win-K) finds the MWDA.

    Perhaps it would help to know what you see in the Connect dialog when you try to use it.  Also, if you see an associated audio port in any way I would try disabling that.  Although I have not had a problem with the MWDA's audio it is a continuing long-standing problem with the real HDMI connection.

    There are other bits of implementation it may help to look at too.  E.g. in PowerShell Get-NetConnectionProfile at some point in the state changes pops up with the MWDA's LAC* as an "InterfaceAlias".  I have mine as Private and it seems to be sticking but at least in the past it would switch to Public and I would need to switch it back.   Before that  netsh wlan sh ne mo=BSSID shows a connection possibility which then disappears from there and changes its name.  (Etc.)  YMMV.

    Windows 10.  Still an Adventure ("Twisty passages, all different.")

    Was this answer helpful?

    0 comments No comments
  3. Barb Bowman 80,815 Reputation points MVP Volunteer Moderator
    2018-02-11T10:52:08+00:00
    1. Undo any manual changes you made in network config properties
    2. Turn off the TV
    3. Turn off the HP
    4. Power cycle your router, wait 2 minutes
    5. Turn on the TV
    6. Restart your Surface
    7. Go to device manager and uninstall but do not delete the Marvell wifi adapter driver
    8. restart your Surface again and connect to your wifi network
    9. try connecting to the TV.

    As Miracast is essentially a peer-to-peer connection without a DHCP server to provide an IP address, on the virtual wireless adapter that is active during Miracast connections, I configured the IPv4 'Alternate configuration' to an address of 192.168.137.1, the same IP address that works every time when the HP laptop connects.

    Was this answer helpful?

    0 comments No comments
  4. Anonymous
    2018-02-11T05:12:50+00:00

    Thanks for the suggestions Robert.

    I have already tried removing the TV a couple of times, but I tried again with no change in outcome.

    I am not sure how to use the Network troubleshooter on the Local Area Connection*, when it only shows up briefly while the connection negotiation is occurring, and it disappears as soon as the connection fails.  Perhaps you can advise me on this.

    It is extremely frustrating when Miracast works so well every time with my HP computer but has only worked briefly a couple of times with the Surface Pro 2, and I haven't been able to repeat those two brief successes, which occurred immediately after I changed the Alternate Configuration for the IPv4 address as described above.

    I am not sure where else to look at this stage.

    Was this answer helpful?

    0 comments No comments
  5. Anonymous
    2018-02-10T04:25:38+00:00

    However, once again, while it worked for the hour or so of testing,later it again failed to connect.  We tried several times throughout the day and again over the next couple of days, but no luck.

    When it fails (and can not be reconnected) go to Bluetooth and Other devices to Remove it (and its associated audio device) from there.  Sometimes this is not necessary but too often it seems that it is.  Alternatively, you could try using the Network troubleshooter on the associated Local Area Connection* name. 

    Good luck

    Robert Aldwinckle


    Was this answer helpful?

    0 comments No comments