TABLE OF CONTENTS


What is Miracast?

Miracast is a screen mirroring standard, based on Wi-Fi Direct standard. It is the native mirroring protocol on Microsoft Windows and on several Android manufacturers. Unlike AirPlay and Google Cast which rely on mDNS to advertise the presence of a receiver, Miracast uses Wi-Fi beaconing, which is why Miracast troubleshooting often looks different from other protocols.


How Miracast works on AirServer Connect

To make itself discoverable, AirServer Connect always broadcasts a Wi-Fi SSID starting with DIRECT-. This SSID is required by the Miracast specification and is used for discovery and session negotiation. 


From there, AirServer Connect supports two ways of running a Miracast session:

  • Miracast over Infrastructure (Infracast). After the sending device discovers AirServer via the DIRECT- SSID, the actual media stream is carried over the existing wired or wireless network. This mode is available on Windows 10 version 1703 and later. It's more stable and connects faster than the alternative, and it's what AirServer Connect uses by default whenever possible.
  • Direct Miracast (P2P). If Miracast over Infrastructure isn't available, the sending device connects to the DIRECT- SSID and streams over that peer-to-peer link. This works even when the sender isn't connected to the same network as AirServer, which is useful for guests who don't have access to your Wi-Fi.

Before troubleshooting

Confirm the device actually supports Miracast. See How to check if a Windows PC supports Miracast for the compatibility checks. If those pass and Miracast still isn't working, continue below.

Also make sure the sending device's Wi-Fi and graphics drivers are up to date. Outdated drivers are a frequent cause of Miracast failing at any stage, from discovery to stability.


How to check which Miracast mode your session is using

While a Miracast session is active, you can check which mode is in use by opening the on-screen overlay on the display AirServer is connected to. Click anywhere on the display using a mouse connected to AirServer, or tap the screen if the display is touch-enabled. The overlay shows the connection type for each active session, using one of three labels:

  • Miracast via Ethernet or Miracast via Wi-Fi: the session is running as Miracast over Infrastructure. The media stream travels over the wired or wireless network.
  • Miracast via Guest Access: the session is running as Direct Miracast, or as Infracast tunneled through the built-in hotspot. Either way, the media stream travels over a peer-to-peer Wi-Fi connection.


Which problem are you experiencing?

Miracast can fail at three different points, and the fix depends on where things break. Find the symptom that matches your situation and jump to the relevant section below.

  1. AirServer doesn't appear in the list of available displays: this is a discovery failure. See Discovery problems below.
  2. AirServer appears in the list, but selecting it shows "Could not Connect" or the connection fails immediately: this is a connection failure. See Connection problems below.
  3. Mirroring starts successfully but then drops, freezes, or performs poorly: this is a session stability problem. See Stability problems below.


1. Discovery problems: AirServer doesn't appear in the list of available displays

If Miracast isn't finding AirServer at all, the issue is almost always in the wireless environment, since Miracast discovery happens over Wi-Fi Direct regardless of how the media stream will eventually travel.

  • Check that Wi-Fi is enabled on the sending device. Miracast requires an active Wi-Fi radio on the sender even when using Miracast over Infrastructure, because the discovery phase uses Wi-Fi Direct beaconing. If the sending device's Wi-Fi is off, AirServer won't appear.
  • Check the distance between the sender and AirServer. Miracast discovery relies on Wi-Fi Direct beaconing, which has a much shorter effective range than a regular Wi-Fi network. If the sending device is too far from AirServer (for example, on the other side of a large building or behind several walls) AirServer may not appear in the list even when everything else is configured correctly. Move closer to test whether distance is the issue.
  • Match the Wi-Fi band. AirServer's Miracast channel and the sending device's WLAN band need to be compatible. A typical failure: AirServer's Miracast is on 2.4 GHz, the laptop is on a 5 GHz access point, and AirServer never shows up in the list. Matching both bands usually resolves it. Channel configuration depends on your Connect generation, see the How Wi-Fi channels are configured section further down for details.
  • Group policy on managed devices can block Miracast discovery entirely by preventing Windows from creating the temporary wireless profiles Miracast requires. If AirServer is invisible on a domain-joined machine but visible on a personal machine on the same network, this is likely the cause. See Group policy on managed devices below.


2. Connection problems: AirServer appears in the list of available displays but won't connect

If Miracast finds AirServer but selecting it produces an error or immediately fails, the discovery phase worked but the session couldn't be established.

  • "Could not Connect" error. This is almost always caused by cached wireless display information on the sending Windows device. To clear it:
  1. Press Win + K.
  2. Select Find other types of devices at the bottom.
  3. Find the AirServer entry in the list of saved devices and select Remove Device.
  4. Reboot the computer.

The next connection attempt will be treated as a fresh pairing.

  • Firewall blocking Miracast components. Two Windows applications must be permitted through any firewall on the sending device:
  • CastSrv.exe
  • WUDFHost.exe

Both are Windows system components required for Miracast. Add them as exceptions if a corporate or third-party firewall is running on the sender.

  • Miracast over Infrastructure isn't reaching AirServer. If the sender is connected to Wi-Fi and the connection fails, but works when the sender is disconnected from Wi-Fi (Wi-Fi radio still on, but not joined to any network), it's a strong sign that Miracast over Infrastructure is being blocked by the network. Windows is trying to reach AirServer through the WLAN, failing, and either not falling back to Direct Miracast or falling back too slowly. This typically points to a network-level block. Confirm the required Miracast ports are open between the sender and AirServer. See What ports & Bonjour services are used by AirServer Connect hardware?


3. Stability problems: mirroring starts but doesn't stay stable

If Miracast connects successfully but drops, freezes, or performs poorly during a session, the issue depends on how the media is traveling.

While your Miracast session is running, you can check which mode it's using by opening the on-screen overlay on the display AirServer is connected to. Click anywhere on the display using a mouse connected to AirServer, or tap the screen if the display is touch-enabled. The overlay shows the connection type for each active session.

  • Miracast via Ethernet or Miracast via Wi-Fi: Miracast over Infrastructure. The media stream is going over the infrastructure network.
  • Miracast via Guest Access: Direct Miracast, or Infracast tunneled through the built-in hotspot. Either way, the media stream is going over Wi-Fi.


If the media stream is going over Wi-Fi (Direct Miracast, or Infracast where AirServer or the sender is on Wi-Fi rather than Ethernet), the following are the most common causes of instability:

  • Wi-Fi channel alignment. Channel mismatches between AirServer and the sending device's WLAN cause instability. See How Wi-Fi channels are configured below.
  • Wireless interference. In dense environments (e.g. schools, offices), overcrowded channels degrade Miracast even when everything is configured correctly. Use a Wi-Fi scanner app or your access point's management interface to see which channels are least congested.
  • DFS channels. Dynamic Frequency Selection channels pause transmission when radar is detected nearby, which is unreliable for Miracast streaming.


If the media stream is going over Ethernet (Infracast with AirServer on Ethernet and the sender on Ethernet), wireless conditions matter much less. Focus on:

  • Outdated drivers on the sending device. Miracast depends on both the wireless stack and the graphics stack. Even in Infracast, outdated Wi-Fi drivers and outdated GPU drivers can cause sessions to drop or freeze. 
  • Network conditions. As with any real-time stream, general network performance and configuration affect Infracast stability.

How Wi-Fi channels are configured

Earlier sections mention that Miracast performance depends on matching the Wi-Fi channel between AirServer and the sending device's WLAN. But how you can set that channel manually depends on which Connect generation you have, and whether the device is running as a Wi-Fi client. In some scenarios, the channel is fully user-configurable. In others, it's automatically forced to match the WLAN, and any manual setting is silently ignored.

Note: for the most stable Miracast experience, we recommend connecting AirServer Connect via Ethernet. Wi-Fi client mode is supported but adds complexity to channel configuration.  See below.


Connect 3 

Connect 3 has a dual-band Wi-Fi module.

If the guest hotspot is disabled, only Miracast is using the wireless radio, and its channel can be set freely.

If the guest hotspot is enabled, Miracast and the guest hotspot can be on different channels only if they're on different bands. You could, for example, run Miracast on channel 6 (2.4 GHz) and the guest hotspot on channel 48 (5 GHz). If they're on the same band, they share the same channel: changing one changes the other.

If Connect 3 is also running as a Wi-Fi client, the client uses one of the two available bands. Any feature (Miracast or guest hotspot) on that same band is forced to the WLAN's channel. Features on a different band remain independent.


ScenarioMiracast channelGuest hotspot channelWi-Fi client channel
Ethernet only, hotspot disabledConfigurable— (hotspot off)
Ethernet only, hotspot enabled — different bandsConfigurableConfigurable
Ethernet only, hotspot enabled — same bandConfigurableShared with Miracast
Wi-Fi client modeConfigurable, unless on the same band as the WLAN (then matches automatically)Configurable, unless on the same band as the WLAN (then matches automatically)Set by the WLAN


Connect 2 and Connect 1 (4K UHD)  

Connect 1 (4K UHD) and Connect 2 have a single Wi-Fi radio.

If the guest hotspot is disabled, the radio is dedicated entirely to Miracast, and its channel can be set freely.

If the guest hotspot is enabled, Miracast and the guest hotspot share the same radio, so they must be on the same channel. Changing one changes the other.

If the device is running as a Wi-Fi client (connected to a WLAN rather than using Ethernet), the radio is occupied by that connection. Miracast and the guest hotspot automatically align to the WLAN's channel to prevent channel jumping, and any channel set manually in the AirServer settings is silently ignored.


ScenarioMiracast channelGuest hotspot channelWi-Fi client channel
Ethernet only, hotspot disabledConfigurable— (hotspot off)
Ethernet only, hotspot enabledConfigurableShared with Miracast
Wi-Fi client modeMatches the WLAN automaticallyMatches the WLAN automaticallySet by the WLAN

Group policy on managed devices

On domain-joined devices, group policy can silently block Miracast, most commonly by preventing Windows from creating the temporary wireless profiles Wi-Fi Direct requires. To check whether this is your issue:

  1. Press Win + R and run rsop.msc to open the Resultant Set of Policy tool.
  2. Navigate to Computer Configuration → Windows Settings → Security Settings → Wireless Network (IEEE 802.11) Policies.
  3. Open the wireless policy, go to the Network Permissions tab, and select Allow everyone to create all user profiles.