The project is WinUI 3 + Native AOT. Everything runs fine during debugging, but after publishing and launching, it works normally for a few seconds, then the UI thread randomly becomes unresponsive, stuck in a "fuzzy state" — not a crash and exit, but a freeze with no response.

The strange part is:

• Runs fine in Debug mode
• Runs fine in non-AOT publish
• Removing the JSON parsing calls inside makes it not hang
• Reducing the for loop count to only the first 100 records also makes it not hang

2. Hypotheses​

Hypothesis 1: JsonElement metadata trimmed under AOT​

Initially suspected that System.Text.Json's JsonElement dynamic access was missing metadata under Native AOT. But this was quickly disproven:

On the same item, GetStringProperty was called 8 times in a row, each involving TryGetProperty + GetString + string construction. If JsonElement had a metadata issue, the first GetStringProperty should have crashed.

Hypothesis 2: double value type returning a reference​

TryGetDouble(out var value) — value is a double, a pure value type, copied directly, not referencing JsonDocument's internal buffer. Ruled out.

Hypothesis 3: Object initializer syntax​

Splitting new QuoteData { ... } into new first and then assigning line by line still causes the hang, so assignment ordering is ruled out.

Hypothesis 4: ObservableObject's PropertyChanged​

QuoteData inherits from ObservableObject, but changing it to plain auto-properties still reproduces the issue. Event mechanism ruled out.

3. Key Information​

The observation that "it appears randomly after several seconds" is key. If the crash were data-level, it should trigger the moment that object is accessed. A delay of several seconds means:

• GC runs after a few seconds
• It reclaims some memory or traverses some list
• It hits an inconsistent state inside the runtime

Based on the stack structure of the frozen process, a similar issue record was found in the official dotnet/runtime Issues.

dotnet/runtime #104582:

"The collection being traversed entered a bad state — already-released entries remained in the list. This is the result of a missing lock on the removal operation, causing a race with the finalizer when it runs."

microsoft-ui-xaml #9928:

"The app starts, seems quite smooth, until the UI thread completely freezes. The deadlock happens very randomly, sometimes after a few minutes, sometimes after just a few seconds, but always when GC is waiting for collection to complete."

The complete chain of the problem:

1. Your code creates ProductInfo / QuoteData objects

2. Under the WinUI 3 environment, these objects are projected by CsWinRT into native object wrappers

3. The wrappers are registered into the runtime's global tracker list

4. The UI thread adds entries to the list, while the GC finalizer thread removes entries from the list

5. The removal operation lacks lock protection; both threads operating simultaneously corrupts the list's internal pointers

6. A few seconds later, GC traverses the list again, reads the bad pointer → hang or access violation

   

Why "removing a certain call" "fixes" it​

In reality, this is not a fix — it lowers the trigger probability. Removing the GetDoubleProperty or GetDateTimeProperty call reduces the number of wrappers created during a single traversal. The frequency of add operations decreases, shrinking the probability window of colliding with the finalizer's "removal operation."

Likewise, taking only the first 100 records or batching are all the same logic: reducing the wrapper creation density during a single traversal, avoiding the lock contention window.

4. Solution​

If you encounter a similar issue, while waiting for a runtime update, you can adopt batching to lower the trigger probability: split the large array into small batches, and after each batch, let the UI thread yield once, giving GC a chance to complete its traversal.

Of course, this only lowers the contention probability. A single yield takes milliseconds, depending on how busy the message queue is. The best approach, of course, is still to upgrade the .NET version.

This issue has been fixed and merged into the latest .NET. Friends encountering similar issues can simply upgrade their project's .NET version:

• Fix commit: dotnet/runtime@d7948dc — "Fixes hang in WinUI apps published to AOT (#104583)"
• Currently merged into the .NET 9 branch; .NET 8 users should see the issue disappear after upgrading to the latest patch version

5. Summary​

• In conclusion, this problem is not in your code — it's a ComWrappers lock contention under the .NET runtime AOT path
• It's also unrelated to JSON parsing; it's related to the behavior of "creating a large number of objects"
• If batching can work around it, it only lowers the probability
• The root fix requires upgrading to a .NET runtime version that contains the fix

Reference Links

• dotnet/runtime #104582
• microsoft/microsoft-ui-xaml #9928
• dotnet/runtime fix commit d7948dc

This article uses the interception of DNS A-record queries for www.abc.com as an example to walk through how to intercept DNS requests at the transport layer via WFP (Windows Filtering Platform) and return a specified IP address (e.g., 192.168.1.100). The focus is on the configuration flow and key decision points, supplemented by essential code snippets.

Overall Flow​

The entire solution consists of five steps:

1. Register a Provider and SubLayer to establish your own "territory"
2. Register a Callout and bind callback functions
3. Add a filter to capture only UDP traffic on port 53
4. In the callback, parse the DNS request, match the target domain, construct a response, and inject it
5. On unload, clean up all resources in reverse order

Step 1: Create Provider and SubLayer​

A Provider identifies who registered the rules, while a SubLayer manages priority ordering for filters under the same Provider. Both are prerequisites for registering Filters and Callouts.

When creating a SubLayer, the weight value directly determines the evaluation priority of our filters within the same layer. Setting it to a high value like 0x7FFF ensures that our filter rules are evaluated before system default rules, preventing preemption by Windows Firewall or other third-party software.

Two APIs are called for this step: FwpmProviderAdd and FwpmSubLayerAdd.

Step 2: Register Callout​

A Callout is the "hook" that WFP provides for developers to inject custom logic.

Two things need to be done here:

1. Kernel Registration (FwpsCalloutRegister): Binds the classifyFn, notifyFn, and flowDeleteFn callbacks to the Callout. classifyFn is the core handler invoked for every matching packet; notifyFn handles Callout lifecycle events; flowDeleteFn cleans up flow context.
2. Management Registration (FwpmCalloutAdd): Registers this Callout with the filtering engine's management layer and specifies the layer it attaches to. We choose FWPM_LAYER_OUTBOUND_TRANSPORT_V4.

Why the transport layer instead of the network layer? The network layer (IPPACKET) also exposes UDP ports, but it presents complete IP packets that may be fragmented, requiring the developer to handle reassembly themselves. The transport layer, by contrast, delivers already-reassembled UDP datagrams and can associate them with process information, offering richer filtering conditions and simpler implementation.

Step 3: Add Filter Conditions​

After registration, the Callout does not take effect automatically—it must be activated by adding a Filter.

A Filter consists of a set of Conditions and an Action. We need two conditions:

• Protocol must be UDP (FWPM_CONDITION_IP_PROTOCOL == IPPROTO_UDP)
• Destination port must be 53 (FWPM_CONDITION_IP_REMOTE_PORT == 53)

The action is set to FWP_ACTION_CALLOUT_TERMINATING, meaning: once both conditions match, terminate subsequent filter processing immediately and hand the packet over to our Callout. This ensures both performance and avoids conflicts with other filters.

This step calls FwpmFilterAdd.

Step 4: Prepare Injection Resources​

The forged DNS response must be re-injected back into the network stack, which requires two infrastructure components:

1. NET_BUFFER_LIST Pool (NdisAllocateNetBufferListPool): Used to allocate memory structures that hold the forged packet. Pool-based allocation is more efficient than allocating from scratch every time, which is critical for performance-sensitive network processing.
2. Injection Handle (FwpsInjectionHandleCreate): Creates a transport-layer injection handle. We choose FWPS_INJECTION_TYPE_TRANSPORT because our forged packet is a constructed UDP datagram that needs to be injected from the transport layer. This handle is used when calling FwpsInjectTransportReceiveAsync for asynchronous injection.

Both resources are prepared once during initialization to avoid repeated creation overhead per injection.

Step 5: What Happens Inside the Callback​

Once a DNS request hits the filter conditions, the classifyFn callback is invoked. Its function prototype is:

typedef void (NTAPI *FWPS_CALLOUT_CLASSIFY_FN2)(
    _In_ const FWPS_INCOMING_VALUES0* nFixedValues,
    _In_ const FWPS_INCOMING_METADATA_VALUES0* inMetaValues,
    _Inout_opt_ void* layerData,
    _In_opt_ const void* classifyContext,
    _In_ const FWPS_FILTER2* filter,
    _In_ UINT64 flowContext,
    _Inout_ FWPS_CLASSIFY_OUT0* classifyOut
);

The processing flow is as follows:

5.1 Extract Packet Information​

Retrieve remote address, local address, ports, interface index, and other fields from inFixedValues. For the OUTBOUND_TRANSPORT_V4 layer, available fields include:

• FWPS_FIELD_OUTBOUND_TRANSPORT_V4_IP_REMOTE_ADDRESS: Destination IP
• FWPS_FIELD_OUTBOUND_TRANSPORT_V4_IP_LOCAL_ADDRESS: Source IP
• FWPS_FIELD_OUTBOUND_TRANSPORT_V4_IP_REMOTE_PORT: Destination port
• FWPS_FIELD_OUTBOUND_TRANSPORT_V4_IP_LOCAL_PORT: Source port
• FWPS_FIELD_OUTBOUND_TRANSPORT_V4_INTERFACE_INDEX: Network interface index

These are needed when constructing the response packet—particularly the interface index, which determines the NIC through which the packet is injected.

5.2 Extract and Parse the DNS Request​

Inside the classifyFn callback, layerData points to a NET_BUFFER_LIST structure. Using NdisGetDataBuffer, we extract the complete UDP datagram:

• UDP header is fixed at 8 bytes (source port 2 bytes + destination port 2 bytes + length 2 bytes + checksum 2 bytes)
• The UDP header is immediately followed by the DNS message

DNS Query Format (QR=0) – www.abc.com A-record query:

                                    1  1  1  1  1  1
      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                      ID                     |   Transaction ID (matches response)
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |QR|   Opcode  |AA|TC|RD|RA| Z|AD|CD| RCODE   |   QR=0 indicates query
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    QDCOUNT                    |   Question section count (=1)
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ANCOUNT                    |   Answer section count (=0)
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    NSCOUNT                    |   Authority section count (=0)
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ARCOUNT                    |   Additional section count (=0)
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                                               |
    /                     QNAME                     /   Domain name (www.abc.com)
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    QTYPE                      |   Query type (A=1)
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    QCLASS                     |   Query class (IN=1)
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

The QNAME field is encoded with each label prefixed by a length byte, followed by the label content, and terminated by 0x00. For example, www.abc.com is encoded as:

03 77 77 77 03 61 62 63 03 63 6f 6d 00
3  w  w  w  3  a  b  c  3  c  o  m end

First, check the QR bit in the DNS header (the high bit of the third byte)—if it is 1, this is a DNS response, so skip it; only queries with QR=0 need to be processed.

Then parse the Question section to extract the queried domain name. For a domain like www.abc.com, use RuleManagerMatch to determine whether it matches the rule list.

5.3 Check Query Type and Construct Response​

Extract the QTYPE (query type) from the end of the Question section to determine whether it is an A-record (IPv4, QTYPE=1) or AAAA-record (IPv6, QTYPE=28).

Upon receiving an A-record query, construct a response containing 192.168.1.100. The response is based on the original request with the following modifications:

DNS Header Modifications:

DNS Response Format (QR=1) – www.abc.com -> 192.168.1.100:

                                    1  1  1  1  1  1
      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                      ID                     |   Same transaction ID as request
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |QR|   Opcode  |AA|TC|RD|RA| Z|AD|CD| RCODE   |   QR=1, AA=1
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    QDCOUNT                    |   Question count (=1)
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ANCOUNT                    |   Answer count (=1)
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    NSCOUNT                    |   Authority count (=0)
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ARCOUNT                    |   Additional count (=0)
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                                               |
    /                     QNAME                     /   Echo back the query domain
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    QTYPE                      |   Echo back (A=1)
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    QCLASS                     |   Echo back (IN=1)
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                                               |
    /                     NAME                      /   Answer section: echo domain
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    TYPE                       |   Type (A=1)
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    CLASS                      |   Class (IN=1)
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    TTL                        |   Time-to-live (e.g., 300s)
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    RDLENGTH                   |   Data length (IPv4=4)
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    RDATA                      |   192.168.1.100 (4 bytes)
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

The RDATA field holds the IP address. 192.168.1.100 in network byte order (big-endian) is written as C0 A8 01 64.

When constructing the response, you need to modify the DNS header of the original request: flip the QR bit, set response flags, and populate the Answer section. The UDP header must also be prepended before the data because the injection occurs from the transport layer.

5.4 Encapsulate IP Header and Inject​

The constructed DNS response also needs a UDP header prepended before it can be injected from the transport layer:

UDP Header (8 bytes):

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |            Source Port (DNS server=53)        |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |            Destination Port (client port)     |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |              UDP Length                       |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |             UDP Checksum                      |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |              DNS Response (above)             |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Then, use FwpsConstructIpHeaderForTransportPacket0 to encapsulate the IP header in front of the NBL:

status = FwpsConstructIpHeaderForTransportPacket0(
    pInjectNbl,          // NBL containing UDP+DNS data
    0,                   // headerIncludeHeaderLength
    AF_INET,             // IPv4
    (UCHAR*)&srcIp,      // Source IP (DNS server address)
    (UCHAR*)&dstIp,      // Destination IP (client address)
    IPPROTO_UDP,         // Protocol type
    0,                   // endpointHandle
    NULL,                // controlData
    0,                   // controlDataLength
    0,                   // flags
    NULL,                // reserved
    interfaceIndex,      // interface index
    subInterfaceIndex    // sub-interface index
);

After encapsulation, call FwpsInjectTransportReceiveAsync for asynchronous injection. The completion callback is responsible for freeing the NBL and the previously allocated DNS response data memory.

5.5 Block the Original Packet​

This final step is critical: you must set classifyOut->actionType = FWP_ACTION_BLOCK and set the FWPS_CLASSIFY_OUT_FLAG_ABSORB flag.

If the original packet is not blocked, the real DNS response will arrive later and conflict with the forged packet, causing the application to receive the wrong IP. With these flags set, WFP discards the original request, and only the forged response reaches the application layer.

Step 6: Cleanup​

When unloading the driver, the resource release order must strictly reverse the initialization order:

1. Delete Filter (FwpmFilterDeleteById)
2. Delete user-mode Callout (FwpmCalloutDeleteByKey)
3. Unregister kernel Callout (FwpsCalloutUnregisterByKey)
4. Delete SubLayer (FwpmSubLayerDeleteByKey)
5. Delete Provider (FwpmProviderDeleteByKey)
6. Free NBL pool (NdisFreeNetBufferListPool)
7. Destroy injection handle (FwpsInjectionHandleDestroy)

Failure at any step may cause resource leaks. Use status flags to track failures, but do not stop subsequent cleanup just because one step fails—doing so would worsen the leak.

Key Decision Points Summary​

Important Notes​

1. Asynchronous Injection: Injection uses async interfaces. You must properly implement the completion callback to free the NBL and response data; otherwise, memory leaks will occur.
2. MDL Lifecycle: MDLs allocated via IoAllocateMdl must be freed after injection completes. The timing for this is inside the completion callback.
3. NBL Ownership: After calling FwpsInjectTransportReceiveAsync, ownership of the NBL transfers to WFP—do not manually free it. However, the DNS response data (completionContext) must be freed by yourself in the completion callback.
4. Memory Allocation: Allocate DNS response data using NonPagedPoolNx rather than NonPagedPool. Two reasons: first, the classifyFn callback may execute at DISPATCH_LEVEL, where only non-paged memory can be accessed; second, NonPagedPoolNx adds an additional No-Execute (NX) marker, which is Microsoft's recommended security practice to prevent malicious code execution following buffer overflows.
5. UDP Only: TCP-based DNS requests (DoH, DoT) are not handled by this filtering logic and require additional layers.

• If you have needs related to Windows network filtering, traffic interception, or IP redirection, feel free to reach out for consultation and collaboration.

This article won't dive into complex API details. Instead, it aims to explain, in the simplest terms possible, what WFP is, what it can do, and how it works internally.

What Exactly is WFP?​

In one sentence: WFP is a "universal power strip" embedded in the Windows kernel network stack.

It provides "sockets" (filtering layers) at all key points where network data passes through. You can plug your own processing logic ("plugs") into these sockets to intercept, inspect, modify, and allow/block network traffic.

The built-in Windows Firewall itself is Microsoft's own "plug" inserted into these sockets. Antivirus software, parental controls, and traffic monitoring tools all leverage this same infrastructure.

Why Use WFP?​

Before WFP, developers had several legacy approaches for network filtering: TDI filters, NDIS intermediate drivers, Winsock LSPs, and others. Each had its own limitations:

• Some could only intercept traffic at specific points, without end-to-end control.
• Some lacked compatibility with newer protocols like IPv6.
• Some frequently broke with OS updates.

WFP's greatest value is unifying and standardizing network filtering on Windows. Starting with Windows Vista/Server 2008, it became the foundation for modern firewall and network processing solutions.

The "Big Four" Components of WFP​

The WFP architecture can be understood as four roles working together:

1. Shims: The "On-site Intelligence Officers"​

These are kernel-mode modules embedded at various layers of the TCP/IP stack. They intercept passing traffic, package it into a format WFP understands, and forward it to the filter engine for classification.

Different shims handle traffic at different layers—ALE shims handle application connections, transport-layer shims handle transport data, network-layer shims handle network packets, and so on. You don't need to write shims yourself; they're built into the WFP framework.

2. Filter Engine: The Core "Referee"​

This is the heart that does the actual work. It spans both kernel-mode and user-mode, with approximately 50 kernel-mode layers and 10 user-mode layers. Data passes through different layers at different stages of its journey through the network stack.

Each layer contains sub-layers and filters. A filter is essentially a rule, such as "allow traffic if the destination port is 80." When traffic arrives, the filter engine evaluates rules in priority order and renders a verdict: "allow" or "block."

3. Base Filtering Engine (BFE): The Behind-the-Scenes "Dispatcher"​

BFE is a user-mode system service (the Base Filtering Engine) and serves as the management and control center for WFP.

Its primary responsibilities include:

• Accepting commands from upper-layer applications (like firewall management UIs) to add or remove filters.
• Arbitrating policies from multiple sources when conflicts arise.
• Maintaining WFP's operational state and statistics.
• Distributing IPsec and other policy configurations to the appropriate system modules.

In short, BFE issues the commands, and the filter engine executes them.

4. Callouts: The "Custom Hooks" for Developers​

This is where WFP's extensibility shines. The built-in "allow/block" logic not flexible enough? You can write your own Callout Driver to register one or more callback functions (Callouts).

You can attach a Callout to any kernel-mode layer. When a packet matches a filter that uses your Callout, your classifyFn function is invoked. Inside it, you can implement advanced logic such as:

• Deep Packet Inspection: Scan packet payloads for malware signatures.
• Packet Modification: Perform NAT, rewriting IP addresses and ports.
• Stream Modification: Replace or remove sensitive words in data streams (e.g., parental controls).
• Logging: Record all blocked or matched traffic.

With Callouts, WFP transforms from a simple "switch" into a deeply programmable network processing platform.

How is WFP Layered?​

WFP's layers correspond directly to the TCP/IP protocol stack, with filtering points available from application-layer data all the way down to raw packets leaving the NIC. Here's a brief walkthrough using an outbound TCP packet as an example:

1. Application Layer (ALE Layer): The app calls send(), and the data enters the kernel. The ALE_AUTH_CONNECT layer is triggered—this is the "connection authorization" stage, where you can obtain process PID, image path, destination IP/port, and other info. This is the most critical layer for building application-aware firewalls.
2. Transport Layer (TRANSPORT Layer): The TCP packet has been constructed but not yet fragmented. At OUTBOUND_TRANSPORT_V4, you can access the complete TCP header and payload data.
3. Network Layer (IPPACKET Layer): The IP packet has been encapsulated and may be fragmented. At OUTBOUND_IPPACKET_V4, you can access the IP header. Process information is no longer available at this layer, making it suitable for IP-level filtering and VPN tunnel encapsulation.

For inbound traffic, the order is reversed: INBOUND_IPPACKET_V4 → INBOUND_TRANSPORT_V4 → ALE_AUTH_RECV_ACCEPT, flowing upward.

How to Choose the Right Layer?​

Different development goals require different layers. The following table summarizes common use cases and their recommended layers:

Summary​

WFP is the "right path" for network filtering on Windows. It exposes critical points in the network stack, allowing you to intercept and process traffic in a standardized way.

While writing a Callout driver still requires working through the WDK documentation, understanding WFP's "power strip" model makes the core concepts clear: data travels through the stack, passes through a series of "sockets" (layers), and your "plugs" (Callouts) execute logic there, telling the system whether to allow, block, or modify each packet.

Today we're talking about a trick that goes against common sense. You've probably always thought: if you connect two PCs directly with a cable, they have to be on the same subnet to talk to each other (like 192.168.1.x and 192.168.1.y).

Yeah, that's the "politically correct" way. But sometimes life throws you curveballs:

• Maybe one PC has a static IP (10.10.10.5) and the other is DHCP (192.168.1.3), and you just don't want to keep changing them back and forth.
• Maybe you're just testing Layer 3 forwarding and don't want to set up a complicated router.
• Or maybe you just want to prove the old-timers wrong who insist "they must be on the same subnet!"

Today, I'm going to show you how to break that rule. Two directly connected PCs with IPs on different subnets? Still pingable! And you don't need an extra router – just the built-in "soft router" feature in Windows.

Step 1: The Hardware (If you mess this up, just quit networking)​

A crossover cable? Wrong! That was the rule back in the ancient times (circa 2000).

Just grab a regular straight-through cable, plug one end into PC-A's NIC, and the other into PC-B's NIC. Once plugged in, you'll see the little LEDs on the ports start "bling bling" – that means the physical link is ready.

Step 2: Set Up Their "ID Cards" (IP Addresses)​

Let's put them in two different "camps":

• PC-A: IP 192.168.1.3, Subnet Mask 255.255.255.0

• PC-B: IP 10.10.10.5, Subnet Mask 255.255.255.0

Notice that? One is on the 192.168.1.x network, the other on 10.10.10.x. If you do things the normal way and ping 10.10.10.5 from PC-A, the system will tell you: "Destination Host Unreachable" – because the OS thinks these two don't know each other.

Step 3: Grant "God Mode" to Your PCs (Add Static Routes)​

Since A and B don't know each other, we'll forcefully draw a map in their brains – telling them: when you're looking for the other guy, just go directly through your own NIC, don't bother asking the gateway!

On PC-A (192.168.1.3):​

Open Command Prompt (CMD) and type this "spell":

route add 10.10.10.0 mask 255.255.255.0 192.168.1.3

Translation: "Hey PC-A, anytime you're looking for someone on 10.10.10.x, don't ask anyone else – you're the guide! Just send it straight out of your own NIC!"

On PC-B (10.10.10.5):​

Open CMD and type the "reply":

route add 192.168.1.0 mask 255.255.255.0 10.10.10.5

Translation: "Hey PC-B, when you're looking for someone on 192.168.1.x, don't be shy – just fire it straight out of your NIC! "

Step 4: Witness the Miracle (And Make It Permanent)​

Now, ping B from A:

ping 10.10.10.5

Boom! You'll see Reply from 10.10.10.5: bytes=32 time<1ms TTL=128.

It works! Perfectly! Now you can share folders, transfer large files, or even play LAN games – no issues at all.

⚠️ Pro Tips (Survival Guide)​

1. Reboot = Gone: The route add commands above are temporary. They'll vanish after a restart. To make them permanent, use route -p add (Windows) instead.
2. Turn off the firewall! Turn off the firewall! Turn off the firewall! I can't stress this enough. Windows Firewall, by default, allows ICMP (ping) from the same subnet but blocks it from different subnets. If you don't disable it, all your hard work will just give you "Request Timed Out." Just turn off Domain and Private firewalls for testing.
3. Subnet Mask Matters: Use 255.255.255.0 if you want the entire subnet to route through. Use 255.255.255.255 if you only want that specific host to communicate (host route) – precision targeting!

Final Thoughts​

See? Feels like a whole new world has opened up, doesn't it?

This trick is super handy for server migration temporary setups, team networks without a switch, or just showing off your skills.

Remember: Technology is rigid, but people are flexible. Who says directly connected PCs have to be on the same subnet? As long as the routes are correct, you can ping across any distance!

Alright, I'm off to go mess with the product manager's head with this. Go try it out and report back!

If it doesn't work, double-check the IPs in Step 3, or see if Windows Update secretly turned the firewall back on. Peace out! 👋

The following configuration is based on two Windows devices. Node A has a public IP address (or has port mapping configured) and acts as the "central node" waiting for connections. Node B is behind a NAT (internal network) and actively connects to Node A to achieve mutual communication.

The core logic is: A is responsible for "waiting for connections," while B is responsible for "finding A." This "waiting" does not mean a persistent connection is established; instead, B maintains the data channel between the two by actively sending packets and establishing a keepalive mechanism. When B actively sends packets to A, B also leaves its external port on the router's public side, allowing A to send response data back to B.

1. Preliminary Preparation: Installation and Key Generation

• 1-1. Two Windows devices: Node A (with a public IP), Node B (behind NAT, just needs internet access).
• 1-2. Install the WireGuard client: The official website is currently blocked in China. You can find it on some domestic software sites, but be careful to ensure it is used only within China (e.g., from home to office). Cross-border forwarding will also be blocked.
• 1-3. Confirm A's port is reachable: A needs to allow a UDP port (e.g., 6000). Add an inbound rule in Windows Firewall. If there is a router in front of A, configure port mapping on the router to map the public IP's port 6000 to A's internal IP.
• 1-4. Prepare to record public keys: During the configuration process, you will need to copy each other's public keys. It is recommended to open Notepad in advance for temporary storage.

2. Configure Node A (Public Node)

Node A's core role is to listen on a publicly reachable UDP port, waiting for B to connect. It also assigns itself a virtual IP for identification within the virtual network.

Edit the configuration file: In the WireGuard main interface, select Node A's tunnel, click "Edit," and add the following content.

Among them, Public Key and Private Key are automatically generated key pairs; you only need to configure the listening port and the virtual address.

Address specifies Node A's IP within the virtual network; ListenPort is the port A listens on. Ensure this port is allowed in Windows Firewall and the router (if applicable).

After saving, the configuration will look like the example shown below. Note that the configuration is not yet complete—Node B's public key will be added later.

3. Configure Node B (Client Node)

Node B, as the device that initiates the connection, needs to know who to connect to and its own virtual IP.

Edit the configuration file: In the WireGuard main interface, select Node B's tunnel, click "Edit," and add the following content.

Among them, PrivateKey and PublicKey are automatically generated; Address is set by yourself.

4. Add Each Other to Peer Lists

Now that both A and B have their own key pairs, the next step is to add each other's public keys to their respective Peer lists. The added form is as follows:

• Node A:

• Node B: As the active connection initiator, Node B adds two additional items: Endpoint and PersistentKeepalive.

• Endpoint specifies Node A's public IP and listening port.
• AllowedIPs = 10.10.10.1/24 controls the packet matching rules for outbound/inbound traffic handled by the WireGuard driver.
• PersistentKeepalive = 25 ensures B sends keepalive packets every 25 seconds to maintain NAT mappings, allowing A to actively send data to B.

5. Start and Verify the Connection

• Startup sequence: Connect Node A (public node) first, then Node B.

• Verification method: Ping each other's virtual IP from Node A and Node B. If successful, the connection is working.

What is HTTP Sharing?​

HTTP Sharing is a one-click file sharing feature provided by Xiaoye Remote. Once you start the service, you can add files to the mapping list, and others can easily access your shared files through the HTTP links you generate.

Wide range of applicable scenarios: Whether on a local network at home or in the office, through the virtual subnet built by Xiaoye Remote, or even in broader network environments, you can quickly achieve file sharing.

How to Use HTTP Sharing?​

The entire process is designed to be intuitive and can be completed in just a few steps:

1. Run Xiaoye Remote App​

Launch the Xiaoye Remote App and navigate to the HTTP Sharing feature homepage. By default, the service is in a stopped state, and the interface is clear and concise.

2. Start the Service​

Click the "Start" button at the top. Once the service starts successfully, you will see an indicator showing that the service is running, indicating it is ready to receive file mappings.

3. Add Files to Share​

You can add files or directories to share in two ways:

• Direct Drag & Drop: Drag files or folders directly into the URI mapping table area
• Manual Addition: Click the "Add File" or "Add Directory" button and select files in the file manager window

You can flexibly add multiple files or entire folders as needed to build your sharing list.

4. View in Browser​

After adding files, click the "Open in Browser" operation, and you will see a basic file sharing list page.

Local Network Access: If another device is on the same local network as your device, simply enter http://<your_local_IP> in the browser to access and download files.

5. Share in Subnet or Public Network​

You may also want to access shared files through other network environments. Xiaoye Remote provides you with a more flexible solution:

1. Log in to your account: Click the avatar in the upper left corner to log in to your Xiaoye Pass account
2. Enable Subnet/Public Network: After logging in, return to the HTTP Sharing page and click the "Subnet/Public Network" enable button
3. Get access links: Once enabled, you will see two types of links:

• Subnet URI: Accessible between two devices logged in with the same Xiaoye Pass account, or between devices that have joined the same network group – ideal for team collaboration or multi-device synchronization
• Public Network URI: You can access this link from any other device or mobile phone (if access fails, wait a few seconds and refresh to try again)

Friendly Reminder​

For your data security, please disable the relevant features promptly when sharing is no longer needed. Xiaoye Remote always prioritizes your privacy and security.

Version Message​

The HTTP Sharing feature in Xiaoye Remote 3.0.5 is designed to provide you with a simple, flexible, and secure way to share files. Whether you're sharing photos with family on your home local network, collaborating with colleagues by transferring documents in an office environment, or achieving more flexible access through subnet/public network features, HTTP Sharing makes the entire process easier and more efficient.

Xiaoye Remote 3.0.5 is now available for download. Welcome to visit our official website or app store to update to the latest version and experience the new HTTP Sharing feature!

If you are already familiar with the concepts of gRPC, you can skip directly to Chapter 3; if you are already proficient with gRPC, you can skip this article entirely ^_^

1. What is gRPC? Why is it so important?​

gRPC is a high-performance Remote Procedure Call framework open-sourced by Google. It is based on the HTTP/2 protocol and uses Protocol Buffers (protobuf) as the interface definition language and data serialization format.

Several core advantages of gRPC:

• High Performance: Uses protobuf binary serialization, which is smaller and faster than JSON.
• Multi-language Support: Supports multiple languages including C++, Java, Python, Go, and C#.
• Bidirectional Streaming Communication: Based on HTTP/2, supports both client-side and server-side bidirectional streaming.
• Strong Typing: Explicitly defines interfaces through .proto files, generating strongly-typed code.
• Automatic Code Generation: Improves development efficiency and reduces the need to manually write boilerplate code.

Several communication patterns of gRPC:

1. Unary RPC: The client sends a single request, and the server returns a single response. This is the most basic and commonly used interaction, perfectly comparable to REST API calls.
2. Server-side Streaming RPC: The client sends a request, and the server returns a streaming response.
3. Client-side Streaming RPC: The client sends a streaming request, and the server returns a single response.
4. Bidirectional Streaming RPC: Both sides send streaming messages simultaneously.

2. .NET Support for gRPC: Mature and Powerful​

Microsoft's support for gRPC is a full commitment. Since .NET Core 3.0, gRPC has become a first-class citizen on the .NET platform.

Official Support Status:

.NET gRPC Technical Features:

• Fully Managed Implementation: Native .NET implementation, no dependency on C++ libraries.
• Seamless Integration with ASP.NET Core: Shares configuration, logging, dependency injection, and other infrastructure.
• Excellent Performance: Microsoft official benchmarks show gRPC significantly outperforms traditional REST APIs.
• Cross-platform Support: Runs perfectly on Windows, Linux, and macOS.

3. Hands-on: Creating a Complete gRPC Service and Client​

Now, let's create a basic gRPC example, including both the server and the client.

3.1 Environment Setup​

• Visual Studio 2022 (requires the "ASP.NET and web development" workload, as shown below)
• .NET 6.0 SDK or higher

3.2 Create the gRPC Server​

Step 1: Create the project

1. Launch Visual Studio and select "Create a new project".
2. Search for "gRPC" and select the "ASP.NET Core gRPC Service" template.

3. Name the project GrpcGreeter.
4. Select the .NET version (recommend .NET 8.0 or higher).

Step 2: Examine the project structure

After creation, you will see the following core files:

• Protos/greet.proto: The interface definition file for the gRPC service. It contains a request/response data structure and an interface function SayHello.

• Services/GreeterService.cs: Implements the business logic of the gRPC service.

Step 3: Run the server

Press F5 to run the service. The console will display the address the service is listening on, e.g., https://localhost:7208.

3.3 Create the gRPC Client​

Step 1: Create a Console App

1. Open another instance of Visual Studio.
2. Create a "Console App" project and name it GrpcGreeterClient.

Add the following NuGet packages to the client console project; their purposes are described at the beginning of the article.

Step 2: Add the proto file

1. Create a Protos folder in the client project and copy the greet.proto file from the server into this folder.
2. Modify the namespace in greet.proto to distinguish it (optional, not modifying it also works fine).

Edit the .csproj file to include the proto file in the project's build process:

<ItemGroup>
    <Protobuf Include="Protos\greet.proto" GrpcServices="Client" />
</ItemGroup>

Step 3: Write the client code and run it

Add our request code to the console project, and you will receive a response from the server. SayHelloAsync is an asynchronous function auto-generated from the Proto file. Here we have completed a complete RPC interaction using the simplest unary RPC mode of gRPC. Note that no valid HTTPS certificate was added for the server, so using HTTPS directly would cause certificate errors. Therefore, HTTP is used temporarily.

4. Summary: Typical Use Cases for gRPC​

✅ Scenarios suitable for gRPC:

• Microservices Communication: High-performance, low-latency internal service calls.
• Real-time Services: Scenarios requiring streaming data transmission (e.g., chat, location sync).
• Multi-language Environments: Services written in different languages need efficient communication.
• Mobile Clients: Binary transmission saves traffic and battery life.

❌ Although gRPC is powerful, there are scenarios where it is less suitable compared to REST APIs:

• Direct Browser Calls: Requires a grpc-web proxy, less convenient than REST.
• Public-facing APIs: Requires broad client support.
• Simple Query Scenarios: When the overhead of REST is acceptable, there's no need for additional complexity.

Through the introduction in this article, you can see .NET's comprehensive support for gRPC. From creating the server to writing the client, the entire process is smooth and natural. gRPC's features, such as high performance, strong typing, and multi-language support, make it a powerful communication tool for modern microservice architectures.

With the continuous development of the .NET platform, the application of gRPC in .NET will become even more widespread. The official team is also constantly optimizing the performance and experience of gRPC, positioning it as the preferred solution for future service-to-service communication.

Although Microsoft hasn't announced an abandonment of web technologies or cross-platform frameworks, company executives repeatedly emphasized across multiple key sessions that WinUI is now the preferred framework for building modern, high-performance, AI-ready native applications on Windows 11.

1. From "one of many options" to "production platform": Why is Microsoft going all-in on WinUI?​

In recent years, the Windows app ecosystem has become fragmented: Electron, React Native, Flutter, Tauri… developers have many choices, but system experience has suffered as a result — memory usage high, startup slow, interface styles inconsistent.

At Build 2026, Chris Anderson, Microsoft's Corporate Vice President of Windows UI & AI, directly answered the community's most pressing question: "We will not build another new framework. WinUI is the production platform for Windows apps."

To cement this promise, Microsoft even dropped the "3" version number, simplifying it to just "WinUI", signifying a commitment to:

• No disruptive refactoring
• No plans to abandon or replace it
• Long-term, stable investment suitable for enterprise applications

2. Mastering the fundamentals: addressing tearing, memory, and control gaps​

Previously, developer concerns about WinUI centered on foundational experience and missing enterprise controls. Microsoft has now provided a concrete roadmap:

"The top priority is to improve performance, solidify the foundation, ensure quality, and fix a large number of bugs." — Chris Anderson

These improvements mean WinUI is no longer just a "demo-grade" framework, but a true platform for building enterprise-grade applications like financial dashboards, HR management tools, and billing software.

3. Built for the AI agent era: WinUI + AI workflows​

Microsoft also highlighted WinUI's new positioning for the AI era — natively supporting AI agent workflows.

Specifically, this includes:

• Developers leveraging AI agents to help plan, build, and optimize WinUI applications
• Enabling intelligent migration of legacy applications (WinForms/WPF) to WinUI
• Providing clearer control flow and faster iteration experience for AI-assisted programming

In other words, Microsoft isn't simply "adding AI" on top of WinUI; it's optimizing the framework itself for AI-driven development processes.

4. Open but focused: WinUI coexists with other frameworks​

Microsoft hasn't "declared war" on other frameworks. Windows remains an open platform, and excellent patterns from React, SwiftUI, and Compose will be referenced. But Microsoft's clear hope is: when developers want to build the best possible native Windows experience, they think of WinUI first.

To that end, Microsoft has also increased WinUI's transparency — moving almost entirely to public code repositories — and promises "foolproof" interoperability between WinForms/WPF and WinUI, allowing enterprises to migrate progressively rather than rewrite overnight.

5. Signs of "Windows returning" inside Microsoft​

Multiple foreign media outlets commented after Build 2026: This is the conference with the most discussion about Windows native apps from Microsoft in recent years.

Specific evidence includes:

• Forming a new team specifically focused on Windows 11 native app development
• Beginning to rewrite the "Start Menu's" recommendations and "All apps" list from React Native to native implementation
• Planning to rewrite File Explorer using WinUI to achieve a consistent experience across the system

These actions suggest Windows' strategic priority within Microsoft is rising again, and WinUI is the technical foundation of that strategy.

6. Partnering with developers to build next-generation Windows applications​

As observers who have long followed Windows technology evolution, we believe a good framework requires continuous iteration with real-world development scenarios. WinUI is rapidly addressing its shortcomings, and we've already accumulated practical experience in areas like remote control and enterprise office tools (see case study: Xiaoye Remote).

If you or your team are planning Windows app development, or looking to modernize and migrate existing applications to WinUI, please contact us. We can assess feasibility, design architecture together, and leverage WinUI's native performance and AI-ready capabilities to build a better product.

Today, with Microsoft fully committed to WinUI, it's the perfect time to embrace the native Windows ecosystem.

Imagine a common scenario:

You type in an input box, and a text label on the other side of the screen changes synchronously, without you needing to click any "Save" or "Refresh" button.

This is UI automatic update.

Without Data Binding​

The more places where data changes, the more manual data-moving code you write. If you miss one place when modifying a field, the UI will display inconsistently.

With Data Binding​

The middle two steps are completely handled by the framework. You only need to do one thing: tell the UI what the relationship with the data is.

The following diagram shows a text input box and a text label displaying text. When you type in the text box, the text is automatically passed to the bound variable, and then reversely bound to the text label, achieving real-time automatic update.

2. Two Core Concepts for UI Automatic Update​

2.1 Data Binding: Establishing the Connection​

Declare in XAML: "This property of this control equals that property of that data."

For example:

<TextBlock Text="{x:Bind UserName}" />

This line means: the content displayed by this TextBlock always equals the "UserName" data.

No C# code is needed to assign values.

2.2 INotifyPropertyChanged: Sending Notifications​

This is the biggest pitfall for beginners.

WinUI does not automatically detect changes to ordinary C# properties. You must have the data class actively say "I've changed."

public string UserName { get; set; }

private string _userName;
public string UserName
{
    get => _userName;
    set
    {
        _userName = value;
        NotifyUIChanged();
    }
}

There are multiple ways to send notifications:

Method 1: Native INotifyPropertyChanged

Implement the INotifyPropertyChanged interface, implement the OnPropertyChanged method, and call the notification interface when the bound variable changes.

public event PropertyChangedEventHandler PropertyChanged;

private void OnPropertyChanged([CallerMemberName] string propertyName = null)
{
    PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
}

Method 2: Using CommunityToolkit.Mvvm

Use existing .NET libraries to simplify the notification process.

3. Basic Example: Building a Simple App Launcher​

Use a real project to tie all the concepts together. The interface is simple:

• GridView displays the app list (icon + name)
• Clicking an app launches it

3.1 Project Structure​

The structure is simplified here, mainly consisting of two parts:

• ViewModel: Contains data definitions and is responsible for notifications
• MyAppsPage: The UI (XAML), responsible for display

3.2 Data Model​

Define what each App looks like, mainly containing: icon, name, description.

3.3 ViewModel​

This is the hub of data binding.

Here we mainly expose an app list using the ObservableCollection type, so the UI will automatically refresh when apps are added or removed.

public class AppLauncherViewModel : ObservableObject
{
    public static ObservableCollection<AppInfo> AppItems;
}

3.4 XAML Interface​

Core binding syntax:

3.5 Running Effect​

The final running result is as follows:

• The interface displays a row of app icons and names
• Clicking any app launches the corresponding app

Throughout the process, no "click → find control → assign value" code was written.

4. Summary​

If you find that binding is not working, the most likely reasons are as follows:

WinUI 3 data binding is mainly about two things:

1. Declare the relationship: Use binding syntax in XAML
2. Send notifications: Implement INotifyPropertyChanged in the ViewModel

Once you understand this relationship, writing UI becomes "describing what the data looks like" instead of "moving data around manually". Code volume decreases, and bugs also decrease.

When using remote desktop software or accessing remote device resources, we often encounter this scenario:

Two people have different devices logged into different accounts and want to access each other's network resources. What to do?

For professionals, solutions like VPN or intranet penetration are possible, but for ordinary users, the setup cost is too high, and troubleshooting and maintenance can be challenging.

The Network Group feature in Xiaoye Remote Control 3.0.1 allows two people to easily form a network with their remote devices.

What is a Network Group?​

Simply put, a Network Group can be understood as a virtual local area network (VLAN).

Pull devices from different accounts into the same "room" (Network Group), and they can access each other just like on the same local network, with direct virtual IP connections — no public IP address, no port forwarding required.

Hands-On: Cross-Account Networking with Two Devices​

Environment Setup​

Step 1: Create a Network Group​

1. Open Xiaoye Remote Control and log in to Account A
2. Left menu: Network Group → Create Network Group
3. Enter a name: MyGroup (only letters, numbers, and underscores are supported)
4. Click Create

After successful creation, the network group you created will appear in the list below.

💡 Tip: Click "Create and Join" to automatically add your current device to the group, saving an extra step.

Step 2: Another Account Joins the Network Group​

1. Log in to Account B on the other device
2. Go to Network Group → Join Network Group
3. Enter the network group name created earlier: MyGroup
4. Click Join

After successfully joining, Account B's device will also appear in the network group.

Step 3: Verify Connectivity​

In the Network Group interface, each device will display a virtual IP address. Open the command line and ping the other device's virtual IP:

ping 100.x.x.x

If the ping succeeds, the network is established and the two devices can access each other.

Frequently Asked Questions​

Q1: Do multiple devices under the same account need a Network Group?

No. Devices under the same account are interconnected by default and can connect directly without additional configuration.

Q2: Which ports are allowed?

Currently, after two devices are connected, ports 80, 443, and 3389 are allowed by default. More configurable port options will be added in future updates.

Q3: How do I leave a Network Group?

Click the "Leave" button on the right side of the network group in the list. After leaving, the devices will no longer be able to access each other.

Q4: Is the Network Group secure?

Network Group communication uses end-to-end encryption. Devices within the group can see each other, but outside access is blocked.

Summary​

The Network Group feature simplifies "cross-account networking" from complex to simple, making it very practical for team collaboration, multi-account households, IT operations, and more.

🚀 Core Highlight: Cross-Account Network Groups​

In the past, when using remote control software, devices under the same account could connect easily. However, once different accounts were involved, complex configurations, relay servers, or even third-party tools were often required.

Now, Xiaoye Remote Control 3.0.1 completely solves this problem.

A Network Group is a virtual device cluster that allows you to add devices from multiple different accounts into the same logical group, enabling direct cross-account connectivity with no additional configuration required.

📖 How to Use Network Groups​

Step 1: Create a Network Group​

Log in to Xiaoye Remote Control with Account A, go to Network Group → Create Network Group, enter a name (e.g., MyGroup), and click Create.

💡 Tip: The name only supports letters, numbers, and underscores.

After successful creation, you can select "Create and Join" to automatically add your current device to the network group, or you can manually click the "Join" button on the right side of the network group later.

Step 2: Invite Other Accounts to Join​

Log in to Xiaoye Remote Control with Account B, go to Network Group → Join Network Group, enter the network group name created by Account A (e.g., MyGroup), and click Join.

Step 3: Test Network Connectivity​

After successfully joining, both devices will be assigned a virtual IP address. You can use the ping command to test connectivity:

If the ping succeeds, you can perform remote desktop connections, file transfers, and other operations just like on a local area network.

⚡ Same Account vs. Cross-Account​

📌 Note: If you log in to Xiaoye Remote Control on two devices with the same account, they are interconnected by default and do not require creating a network group.

🎯 Use Cases​

• Team Collaboration – Multiple team members' devices join the same network group for more efficient remote assistance and file sharing
• Multi-Account Households – Family members use their own accounts while still needing to control each other's devices
• IT Operations – Manage multiple client devices, each with its own account, unified under one network group
• Cross-Organization Cooperation – Temporary networking between partners, easily exit when the task ends

🔧 Other Updates​

• Optimized remote desktop connection stability
• Improved UI interaction experience
• Fixed several known issues

📥 Get Started Now​

Visit the Xiaoye Remote Control official website to download the latest version, or upgrade to 3.0.1 through the in-app update.

Start building your exclusive network group today →

1. What is NLA? Basic Principles and Version Support​

Network Level Authentication (NLA) is a technology that performs user authentication before establishing a full remote desktop connection.

Basic Principle​

In traditional mode without NLA, when you initiate an RDP connection, the target computer first allocates desktop session resources, loads the graphical interface, starts the login screen, and only then do you enter your username and password. This is like entering a room first and then being asked to show your ID.

With NLA enabled, at the very beginning of the connection, the client must send your credentials to the server for verification. Only after verification passes will the server start allocating session resources and loading the desktop environment. This is like having a guard at the door — if your ID isn't valid, you can't even enter.

Version Support​

• Server-side: Officially supported starting from Windows Server 2008 and Windows Vista.
• Client-side: Supported starting from Windows XP SP3, but fully integrated starting from Windows 7 and later.

Mainstream systems like Windows 10/11 and Windows Server 2016/2019/2022/2025 all fully support NLA.

2. NLA On vs. NLA Off: Effect Comparison​

To understand the differences intuitively, I'll compare three dimensions: connection efficiency, visual appearance, and security risks.

2.1 Connection Effect When NLA is Off: Lock screen appears first, then the password prompt.​

2.2 Connection Effect When NLA is On: Windows login prompt appears directly, no server resources are consumed before password entry.​

Forcing NLA On the Server Side​

In System Properties → Remote → Remote Desktop section, checking "Allow connections only from computers running Remote Desktop with Network Level Authentication" forces NLA on.

After forcing "NLA-only connections" on the server, clients that do not support NLA will receive a direct connection error, preventing session resource consumption.

3. Summary: For Security, Strongly Recommend Enabling NLA​

From the comparison above, it's clear that disabling NLA, while allowing compatibility with very old systems (such as Windows 2000 or non-standard RDP clients), comes at the cost of serious resource waste and significant security risks.

Especially for remote desktop services exposed to the internet (strongly not recommended to expose port 3389 directly, but if you must), disabling NLA essentially leaves a "backdoor" for attackers to consume your server resources without even needing to authenticate.

Final Recommendations​

✅ Default policy: On all operating systems that support NLA, make sure to check "Allow connections only from computers running Remote Desktop with Network Level Authentication."

✅ Compatibility handling: If old clients cannot connect, consider upgrading the client system, or disable NLA on a case-by-case basis only within isolated internal networks with firewall whitelisting, rather than globally.

✅ Further hardening: Even with NLA enabled, it is recommended to use strong passwords, account lockout policies, or non-standard ports (as a secondary measure).

In summary: Enable NLA — achieve pre-connection authentication and security protection with minimal configuration cost. This is a security best practice every Windows administrator should follow.

Remember those WinForms apps we used to build? Gray borders, square buttons, and monotonous interfaces. In this era where visual appeal matters, users have increasingly high expectations for desktop application aesthetics. The emergence of WinUI 3 has finally empowered .NET developers to effortlessly create modern-looking desktop applications.

This article will guide you through building a modern desktop application with glassmorphism effects and a custom title bar using WinUI 3, step by step. The final result will rival native Windows 11 applications.

1. Why Choose WinUI 3?​

2. Environment Setup​

Before you begin, ensure you have installed:

• Visual Studio 2022 (17.0+)
• .NET 6 SDK or higher
• WinUI 3 project template (available via VS Installer)

3. Create a Project and Enable Mica Background​

3.1 Create a New Project​

Select the "Blank App, Packaged (WinUI 3 in Desktop)" template.

3.2 Enable Mica Material​

Mica is a semi-transparent material introduced in Windows 11 that dynamically picks up colors from your desktop wallpaper, creating a sense of depth. Simply add the following to your Window object in XAML:

<Window.SystemBackdrop>
    <MicaBackdrop />
</Window.SystemBackdrop>

4. Customize the Title Bar​

Professional applications typically hide the default title bar, allowing content to extend to the top edge.

4.1 Create a Custom Title Bar in MainWindow.xaml​

<Grid x:Name="AppTitleBar" 
      Height="32" 
      VerticalAlignment="Top" 
      Background="Orange">
    <TextBlock x:Name="TitleTextBlock" 
               Text="My WinUI3" 
               Margin="12,0,0,0" 
               VerticalAlignment="Center" 
               Style="{StaticResource CaptionTextBlockStyle}"/>
</Grid>

4.2 Set the Title Bar Drag Region​

In your MainWindow.xaml.cs, configure the extension area during initialization:

public MainWindow()
{
    InitializeComponent();
    this.ExtendsContentIntoTitleBar = true;
    SetTitleBar(AppTitleBar);
}

You now have a custom title bar!

5. Core Layout Control Practices​

WinUI 3 provides powerful layout controls. Mastering them is the foundation of building modern UIs.

5.1 Grid — Grid Layout​

Grid is the most commonly used layout control, ideal for building complex interfaces. The example below defines a two-row layout: the first row for a custom title bar and the second row for a navigation bar:

<Grid>
    <Grid.RowDefinitions>
        <!--Title bar content-->
        <RowDefinition Height="Auto"/>
        <!--Navigation bar-->
        <RowDefinition Height="*"/>
    </Grid.RowDefinitions>              
    <Grid x:Name="AppTitleBar" Grid.Row="0"/>
    <NavigationView x:Name="AppNavPanel" Grid.Row="1" />
</Grid>

5.2 StackPanel — Simple Stacking​

StackPanel is used for simple content stacking, either vertically or horizontally. The following example defines a row of horizontally arranged buttons:

<StackPanel Grid.Row="1" 
            Orientation="Horizontal" 
            Spacing="8" 
            HorizontalAlignment="Center">
    <Button Content="New" />
    <Button Content="Edit" />
    <Button Content="Delete" />
</StackPanel>

5.3 Combination — Card-style List​

By combining Grid and StackPanel, you can create card-style interfaces similar to Windows 11 Settings. To add scrolling capability, simply wrap the content with a ScrollViewer. When the ScrollViewer's content exceeds the window boundaries, a scrollbar will be added automatically.

6. Conclusion​

WinUI 3 brings an unprecedented modern UI experience to .NET desktop developers. Through this article, you should have learned:

✅ Enable Mica/Acrylic glassmorphism effects

✅ Customize the title bar for a professional look

✅ Build flexible layouts using Grid and StackPanel

✅ Create card-style interfaces

✅ Implement responsive window adaptation

Compared to traditional WinForms, WinUI 3 offers both ease of use and advanced, powerful features. While the advanced features may be complex, the improvements in visual experience and user interaction are tremendous. If you're looking to build an impressive desktop application in 2026, WinUI 3 is an excellent choice.

In our daily work, we often need to copy files from our local computer to a remote server or office computer. The traditional approach involves network sharing, FTP, or cloud storage transfers, but these methods are either complex to configure or limited by speed.

Today, I'd like to share a practical feature of Windows Remote Desktop that is easy to overlook: Drive Redirection. Once configured, your local hard drive partitions will appear directly in "This PC" on the remote desktop, allowing you to copy files as simply as you would on your local machine.

Steps​

Step 1: Open Remote Desktop Connection

Press Win + R, type mstsc, and press Enter to open the Remote Desktop Connection client.

Step 2: Access Local Resources Settings

In the Remote Desktop Connection window, click on "Show Options" in the bottom-left corner, then switch to the "Local Resources" tab.

Step 3: Configure Drive Mapping

In the "Local Resources" tab, click the "More..." button.

Step 4: Select the Drives to Map

In the pop-up window, expand the "Drives" list and check the local disk partitions you wish to map to the remote desktop.

• Checking the "Drives" checkbox selects all partitions
• Alternatively, you can select individual drives such as C: or D: as needed
• Click "OK" to confirm

Step 5: Connect to the Remote Desktop

Enter the remote computer's IP address and credentials as usual to connect to the remote desktop.

Final Result​

Once connected, open "This PC" in the remote desktop window. Under the "Redirected Drives and Folders" section, you will see the local drive letters you checked earlier.

Now, you can drag, copy, and paste files directly between the remote computer and your local drives, just as you would on your local machine—no intermediate tools required.

Important Notes​

• Network and Policy Restrictions: In some corporate environments, IT administrators may disable drive redirection via Group Policy. In such cases, this option may be unavailable or ineffective.
• Security Recommendations: Only use this feature on remote computers you trust. Enabling this option on public or untrusted remote computers may lead to local data leakage.
• Performance Considerations: When reading or writing files to a mapped drive over a remote desktop session, data is transmitted over the network. The speed of copying large files is limited by your available network bandwidth.

Conclusion​

This little tip saves you the intermediate steps of setting up file sharing or uploading to cloud storage. It significantly improves efficiency, especially when you need to temporarily transfer a few files to a server.

If you frequently use Remote Desktop for work, give this feature a try.

Any application is bound to encounter exceptions—network disconnections, missing files, null references, out-of-memory conditions... The key is how to handle these exceptions gracefully rather than letting the application crash directly.

As a next-generation Windows desktop application framework, WinUI 3 provides a multi-level exception handling mechanism. This article will detail common exception handling approaches in WinUI 3 to help you build more robust applications.

1. Exception Handling Hierarchy​

Exceptions in WinUI 3 applications can be caught at different levels:

App Layer (UnhandledException)              ← Outermost layer, fallback

Page/Window Layer (try-catch)               ← UI layer

ViewModel/Service Layer                     ← Business logic layer

async/Task Exceptions (TaskScheduler.UnobservedTaskException) ← Async tasks

Due to space constraints, this article covers the most basic and commonly used exception handling methods.

2. Application.Current.UnhandledException​

This is the most critical global exception handling entry point in WinUI 3 applications. Any uncaught exception will eventually reach here.

Basic Usage​

In App.xaml.cs:

public partial class App : Application {
    public App()    {
        this.InitializeComponent();       
        
        this.UnhandledException += OnAppUnhandledException;
    }   

    private void OnAppUnhandledException(object sender, Microsoft.UI.Xaml.UnhandledExceptionEventArgs e)  {
        
        e.Handled = true;       

        
        LogException(e.Exception, "UnhandledException");       

        
        ShowErrorDialog("The application encountered an issue and has attempted to recover.");
    }
}

Key Points​

⚠️ Important Note​

UnhandledException can only catch exceptions on the UI thread! Exceptions in background threads and async tasks require other handling methods.

3. TaskScheduler.UnobservedTaskException​

Handles unobserved exceptions in async/await tasks. Triggered when a Task is garbage collected and an exception remains unobserved.

Usage​

public App() {
    this.InitializeComponent(); 
    this.UnhandledException += OnAppUnhandledException;   
    
    TaskScheduler.UnobservedTaskException += OnTaskUnobservedException;
}

private void OnTaskUnobservedException(object sender, UnobservedTaskExceptionEventArgs e) {
    e.SetObserved();  
    LogException(e.Exception, "UnobservedTaskException"); 
    
}

Practical Example​

async Task DangerousMethod() {
    await Task.Run(() => {
        throw new InvalidOperationException("Background operation failed");
    });
}

_ = DangerousMethod();  

Best Practice​

Always wrap async operations with try-catch, or use await + try-catch to properly handle exceptions.

4. Scenario-Specific Exception Handling​

File I/O Operations​

private async Task LoadFileAsync(string filePath) {
    try {
        var file = await StorageFile.GetFileFromPathAsync(filePath);
        var content = await FileIO.ReadTextAsync(file);
        
    }
    catch (FileNotFoundException ex) {
        await ShowErrorDialog($"File not found: {filePath}");
        LogException(ex, "FileNotFound");
    }
    catch (UnauthorizedAccessException ex) {
        await ShowErrorDialog("No permission to access the file");
        LogException(ex, "UnauthorizedAccess");
    }
    catch (Exception ex) {
        await ShowErrorDialog($"Failed to read file: {ex.Message}");
        LogException(ex, "FileIOError");
    }
}

Network Request Exceptions​

private async Task<HttpResponseMessage> SendRequestAsync(string url) {
    try {
        using var client = new HttpClient();
        client.Timeout = TimeSpan.FromSeconds(30);
        return await client.GetAsync(url);
    }
    catch (HttpRequestException ex) {
        LogException(ex, "NetworkError");
        throw new NetworkException("Network connection failed, please check your network settings", ex);
    }
    catch (TaskCanceledException ex) {
        LogException(ex, "RequestTimeout");
        throw new TimeoutException("Request timeout, please try again later", ex);
    }
}

5. Exception Handling Practices in Xiaoye Remote​

In actual development, exception handling is not only about preventing crashes but also about helping developers quickly locate issues.

One-Click Feedback​

In Xiaoye Remote, we have designed a convenient exception feedback mechanism:

If you encounter an exception while using Xiaoye Remote, simply click the one-click feedback button on the exception interface to report the error information to us. The error information does not contain any personal data.

Feature Highlights​

6. Best Practices Summary​

✅ DO (Recommended Practices)​

• Always set up UnhandledException as the outermost fallback
• Log detailed exception information (type, stack trace, time, context)
• Provide user-friendly prompts, avoid showing overly technical log details
• Handle specific exceptions at appropriate layers (e.g., network, file operations)
• Provide exception feedback channels to allow users to help improve the application

❌ DON'T (Practices to Avoid)​

• Don't swallow exceptions without logging them (e.Handled = true without any action)
• Don't perform long-running operations on the UI thread (use async/await)
• Don't ignore Task exceptions (use try-catch or await)
• Don't throw the same exception in a catch block (loses stack trace information)
• Don't display complete exception stack traces to users in production

Conclusion​

Exception handling is an indispensable foundation in desktop application development. WinUI 3 provides a comprehensive exception handling mechanism. Properly utilizing these mechanisms can make your applications more robust and your users more satisfied.

Remember: Good exception handling doesn't mean the application never reports errors—it means when errors occur, the application can degrade gracefully, log the issue, and help users recover their operations.

If you encounter any issues while using Xiaoye Remote, please feel free to report them to us through the one-click feedback feature on the exception interface, helping us make the product better!

As a Windows desktop developer, have you ever been confused about how many UI frameworks Microsoft actually has? Win32, MFC, WinForms, WPF, UWP, WinUI… these terms can be overwhelming. Today, we'll sort through the evolution of Windows UI frameworks and focus on Microsoft's current flagship—WinUI 3—to help you take your first step into modern Windows desktop development.

1. Three Generations of Windows UI Frameworks​

Looking back at the history of Windows desktop development, we can roughly divide these frameworks into three stages:

First Generation: The Native Era — Win32 / MFC​

Win32 API is the lowest-level interface for Windows UI programming, allowing direct interaction with the operating system. When developing desktop applications with Win32, you need to manually handle window messages (WM_PAINT, WM_CLOSE, etc.) and manage handles and resources. The advantages are extremely high performance and strong control, but the downside is low development efficiency—even creating a single button requires dozens of lines of code.

MFC (Microsoft Foundation Classes) is a C++ wrapper around Win32 that abstracts windows and controls into C++ classes, simplifying the development process. From the 1990s to the early 2000s, MFC was the mainstream choice for Windows desktop development. However, due to its dependence on C++ complexity and legacy issues, it has gradually faded from the scene.

Characteristics: Low-level, high performance, low development efficiency, rarely used in modern development

Second Generation: The Managed Era — WinForms / WPF​

With the introduction of the .NET Framework, Microsoft launched two major managed UI frameworks:

WinForms was released in 2002 with .NET Framework 1.0. It adopts a "what you see is what you get" design philosophy, making drag-and-drop development extremely intuitive and code simple to understand. For traditional business system development (such as inventory management, ERP), WinForms still has a wide user base today.

WPF (Windows Presentation Foundation) was released in 2006, bringing revolutionary changes: XAML declarative UI, vector graphics, data binding, and the MVVM pattern. WPF separates the interface from logic, achieving true "UI and code decoupling." Numerous enterprise applications still run on WPF today.

Characteristics: Managed code, high development efficiency, mature ecosystem, WPF suitable for complex interface development

Third Generation: The Modern Era — WinRT / UWP / WinUI​

WinRT (Windows Runtime) was introduced with Windows 8, designed for touchscreens and the Metro style, introducing a new application model and API design.

UWP (Universal Windows Platform) is an evolution of WinRT, with the slogan "develop once, run on multiple platforms" (PC, Xbox, HoloLens, etc.). UWP supports modern UI features (such as acrylic effects, fluid animations), but due to mandatory distribution through the Microsoft Store and API restrictions, developer adoption has been limited.

WinUI 3 is Microsoft's latest native UI framework, which can be seen as the "unbundled" version of UWP—it separates the modern UI control library from UWP, no longer requires Store distribution, and allows developers to use full Windows APIs. WinUI 3 is currently Microsoft's only heavily invested desktop UI framework.

Characteristics: Modern UI, fully native, no distribution restrictions, Microsoft's current strategic direction

2. Why Choose WinUI 3?​

1. Official Strategic Direction​

From Microsoft's official statements and version iterations, WinUI 3 has become the primary framework for Windows desktop development. While WinForms and WPF will continue to be maintained, new features are rarely added; WinUI 3, however, continues to evolve and tightly integrates with Windows 11's new features.

2. Modern UI Experience​

WinUI 3 comes with Fluent Design built-in, giving your applications:

• Mica and Acrylic effects: Frosted glass-like textures
• Rounded corners and animations: Aligned with Windows 11's design language
• Dark/Light theme auto-adaptation: No additional code required

3. Full API Access​

Unlike UWP, WinUI 3 applications can call all Windows APIs (including registry, system services, any file system location, etc.) without sandbox restrictions. This means you can smoothly migrate powerful features from existing Win32/WPF applications to a modern UI.

4. Multiple Distribution Methods​

WinUI 3 applications can:

• Run directly as .exe files
• Be packaged as MSIX for distribution through the Microsoft Store
• Be distributed through other installer tools

3. Creating Your First WinUI 3 Application​

Now that we've covered the theory, let's get hands-on and create a simple WinUI 3 application.

Step 1: Create the Project​

1. Open Visual Studio 2022 and click "Create a new project"
2. Enter "WinUI" in the template search box and select "Blank App, Packaged (WinUI 3)"
3. Click "Create," enter a project name such as "Xiaoye Remote," and you'll have a standard WinUI 3 project created

Step 2: Understand the Project Structure​

After creation, you'll see the following structure:

├── App.xaml                 # Application entry point, defines startup window and global resources
├── App.xaml.cs              # Code-behind for App.xaml
├── MainWindow.xaml          # Main window interface
├── MainWindow.xaml.cs       # Code-behind for the main window
├── Package.appxmanifest     # Packaging configuration file (icons, permissions, etc.)
└── (Other project files)

Step 3: Design a Simple Interface​

Open MainWindow.xaml and replace the content between <Grid></Grid> with the following code:

<Grid Background="#20b2aa">
    <TextBlock
        Foreground="White"
        HorizontalAlignment="Center"
        VerticalAlignment="Center"
        FontSize="50">Hello World</TextBlock>
</Grid>

Step 4: Run the Application​

Press F5 to start debugging, and you'll see a basic window:

Conclusion​

As Microsoft's new generation flagship framework for desktop development, WinUI 3 inherits the excellent design concepts of WPF, integrates the modern UI experience of UWP, while removing distribution restrictions. For Windows developers, now is the perfect time to learn WinUI 3—Microsoft is fully committed to it, and the ecosystem is continuously improving.

I hope this article helps you understand the evolution of Windows UI frameworks and successfully run your first WinUI 3 application!

1. Full-Screen Mode​

Design Concept

This is the most intuitive approach. Entering full-screen mode makes the remote desktop instantly fill your entire display, hiding the title bar, borders, and taskbar, leaving only the remote computer's desktop. It feels as if you're sitting right in front of that machine, with your view completely taken over.

In full-screen mode, the remote window typically occupies the current display, locking the mouse inside. To switch back to a local application—say, to check a message or reply on WeChat—you need to press a keyboard shortcut to exit full-screen mode.

User Experience

• Strongest immersion, ideal for extended focused work
• Maximised screen utilisation, unaffected by local window layouts
• On multi-monitor setups, full-screen usually takes over the current display, with the mouse confined to it

Best For

Scenarios where you need to "live" inside the remote computer without interruptions from local tasks.

2. Fixed Resolution Mode​

Design Concept

This is the more traditional approach. Before connecting, you specify the resolution you want—for example, 800×600. The remote host then outputs exactly that resolution, and the client displays it pixel-for-pixel.

User Experience

• Crystal-clear visuals, with pixel-perfect rendering
• Stable layout, independent of the local window size
• After connecting, the window itself has a maximum size limit—you cannot drag it beyond the pre-set resolution

Best For

Situations where image quality matters and the window size remains relatively fixed, such as remote debugging or reviewing design drafts.

3. Scaling Mode​

Design Concept

No matter how large or small you drag the window, the remote desktop content scales proportionally to fill it. This is achieved through interpolation algorithms: when the window grows, the content is "stretched"; when it shrinks, the content is "compressed". As a result, the display always fits the window, but text edges become less sharp, and icon details degrade slightly. On a 4K screen, shrinking a remote window can make text difficult to read.

User Experience

• Window can be resized arbitrarily; content always fits proportionally
• Extremely adaptable—works with any window shape or size
• Scaling affects sharpness; text and icons are less crisp than in fixed-resolution mode

Best For

Everyday office work and tasks where the window size changes frequently and absolute sharpness isn't critical.

4. Trade-offs Among the Three Modes​

From a design perspective, these three modes cater to different usage habits:

Each mode has its strengths, but they share a common limitation: the resolution is fixed once the connection is established. In full-screen mode, the resolution is determined by the physical display; in fixed-resolution mode, it's set beforehand; in scaling mode, while the window can change, the image quality varies with the scaling factor.

5. Xiaoye Remote Control: A New Balance Between Clarity and Flexibility​

Is there a way to freely adjust the window like scaling mode while maintaining the sharpness of fixed-resolution mode?

Xiaoye Remote takes a different approach: it dynamically adjusts the resolution rather than scaling the image.

When you enlarge the window, it tells the remote host: "The window is now bigger—please send me a new resolution that matches." When you shrink the window, it adjusts accordingly. Every time the window size changes, the resolution updates seamlessly. The result is a 1:1 pixel mapping, with no interpolation, no blur, and no empty borders.

There's no need to reconnect or manually tweak settings—the display always adapts to the window, eliminating the blur of scaling mode, the rigidity of fixed-resolution mode, and the lock-in of full-screen mode.

It feels like using a local application: you can freely resize the window, and the content remains perfectly clear.

Note: Xiaoye Remote is designed to connect two computers over the internet, so you need to sign in on both machines to use it.

1. Basic Operation: Save an RDP File​

Windows Remote Desktop Connection (mstsc.exe) allows you to save connection configurations as a file with the .rdp extension, so you don't have to re-enter all the information next time.

Steps:​

• Press Win + R, type mstsc, and open the Remote Desktop Connection window
• Enter the computer's IP address and username
• Click "Show Options" below the Connect button to expand more settings
• In the "General" tab, click the "Save As" button at the bottom
• Choose a save location, enter a filename, and click Save

Now you have an .rdp file on your desktop. Double-click it to quickly initiate a connection.

2. Advanced Tip: Make the RDP File Remember the Password​

By default, a saved RDP file does not include the password, so you still need to enter it manually each time. To achieve a true "one-click connection," here's a simple trick.

Two Steps to Remember the Password:​

Step 1: Check "Save Credentials," then Save As an RDP File

Step 2: Run the RDP File

Double-click the RDP file again. This time, you'll need to enter the password once. After the connection completes, the password will be saved automatically.

Principle: The "save credentials" operation in the RDP file saves the credentials to the Windows Credential Manager. From then on, double-clicking this RDP file allows you to log in directly without re-entering the password.

Reminder: Do not save credentials on public computers.

3. Security Alert: The Yellow Warning on RDP Files​

When you double-click an RDP file, you might see a yellow security warning:

This warning is a security feature in Windows, as RDP files may come from untrusted sources and automatically initiate a connection when double-clicked. However, if you created the RDP file yourself or it comes from a trusted colleague, this recurring warning can be a bit annoying.

How to Make an RDP File "Trusted"?​

To make Windows trust your RDP file, you need to digitally sign it. A signed RDP file will have the following characteristics:

• The yellow warning bar changes to blue or green (indicating the publisher has been verified)
• Displays "This remote connection is signed by a trusted publisher"

RDP File Signing Methods:​

• Use a code signing certificate: Purchase a code signing certificate from a legitimate CA (such as Symantec, DigiCert)
• Sign with rdpsign:

rdpsign /sha256 <your certificate thumbprint> <rdp file>

• Verify the signature: Right-click the RDP file > Properties > Digital Signatures tab, where you can see the signature information

Double-click the RDP file again, and it looks much cleaner. Of course, signing is not just about appearance—it also prevents tampering with critical information. If someone modifies key information in your RDP file, the signature will become invalid immediately, triggering another orange warning.

4. Summary and Best Practices​

• Personal daily use: Follow Step 2 to set up an RDP file that remembers the password for quick and convenient access
• Team shared connections: Use RDP files without saved passwords, paired with a shared password management tool
• Security-sensitive environments: Enable the "Always prompt for password" policy in Group Policy, or use certificate-signed RDP files
• Cross-platform use: Other remote desktop clients that support the RDP protocol generally also support importing RDP files, making things much easier

If you use Xiaoye Remote, the default experience is the same as using an RDP file—just double-click to connect. You can also choose to remember the password, which works similarly to the process described above—saving credentials to your local system's Windows Credential Manager

With these tips, your remote work experience will be smoother. If you have any questions or better suggestions, feel free to leave a comment below!

Tired of complicated network configurations for remote work? Or have you been trying out various solutions in search of a remote control tool that is both safe and free? Today, the new version of Xiaoye Remote Control might just be the answer you're looking for.

We are excited to announce the official release of Xiaoye Remote Control version 2.0.82! This update introduces an incredibly user-friendly policy: Two devices, permanently free. Whether you're providing technical support for a family computer or need seamless switching between two office locations, this free tier covers the daily needs of most individual users.

Why Choose Xiaoye Remote Control?

Building on its free model, Xiaoye Remote Control is committed to delivering excellence in both security and user experience.

1. Security, Designed from the Ground Up

• Device Isolation by Account: Your devices are only visible to your own account, naturally protecting them from random scans and attacks originating from the public internet.
• End-to-End Encryption: All remote connection data is encrypted with strong algorithms, ensuring your operations remain private even on public networks.
• No Public IP Required: Say goodbye to complex port forwarding and network configurations, fundamentally reducing your exposure to cyber threats.

2. Performance, Built for Efficiency

• Domestic Multi-Node Acceleration: We have deployed multiple network nodes within the country. The system automatically selects the optimal path for you, significantly reducing latency and making remote operations feel as smooth as local ones.
• Native RDP Experience: With perfect support for the Windows Remote Desktop Protocol, Windows users can enjoy the most familiar and efficient native desktop access experience.

3. Convenience, One Account for All

• Supports various login methods including email, WeChat, and phone number. You can also quickly log in using your existing Microsoft or GitHub accounts, eliminating the need for repeated registrations. One "Xiaoye Passport" manages all your remote devices and future services.

How to Get Started?

Experiencing Xiaoye Remote Control is simple, just three steps:

1. Visit the Xiaoye Remote Control official website (https://xiaoyeapp.com) to download the client.
2. Log in using your preferred method (email accounts require initial registration, while third-party options like WeChat allow direct login).
3. Log in to the same account on your two devices, and your permanently free remote journey begins!

Xiaoye Remote Control 2.0.82 aims to be your secure, high-speed, and simple remote desktop partner. Whether you're a remote professional or the "family IT consultant" helping relatives with their computers, you're welcome to give it a try.

If you encounter any issues during use, or have any suggestions, please feel free to provide feedback through our official channels. We are dedicated to serving you!

Windows Remote Desktop (Remote Desktop Protocol, RDP) is a powerful feature provided by Microsoft, allowing users to remotely control another Windows computer from one device. When connecting to Remote Desktop, users can log in using either a local account or a Microsoft account, each with its own characteristics and applicable scenarios. This article will detail the differences between these two account types, configuration methods, and login steps to help you choose the most suitable solution.

I. Understanding the Two Account Types​

1.1 What is a Local Account?​

A local account is an account created on a specific computer and exists only on that machine.

• Nature: A Windows user account created only on the local computer
• Access Scope: Can only access resources and services on the local computer
• Password Storage: Password is stored on the local computer
• Applicable Scenarios: Standalone use, small office environments without cloud services

1.2 What is a Microsoft Account?​

A Microsoft account is a unified login credential provided by Microsoft, usable for accessing all Microsoft services.

• Nature: A user account created within Microsoft Azure cloud services
• Access Scope: Can access all Microsoft services, including OneDrive, Office 365, etc.
• Password Storage: Password is stored on Microsoft cloud servers
• Applicable Scenarios: Users needing cloud synchronization and multi-device collaboration

You can choose to use a Microsoft account directly during system installation, or you can log in with a local account first and then bind it to a Microsoft account later.

Note: After binding to a Microsoft account, the local account still exists in the system, but its login method becomes invalid, and it will no longer support remote desktop login using the local account credentials.

II. Using a Microsoft Account to Log in to Remote Desktop​

2.1 Preparation Before Login​

During the Windows installation process, you might use authentication methods like an authenticator app instead of a password. In such cases, the system does not directly store your Microsoft account password, and you need to trigger password verification once.

As shown in the image below, if you have been using a PIN to log in after adding a Microsoft account, the password cache on the controlled computer will not be triggered, and you will be unable to connect via Remote Desktop.

Select the password login option from the login choices below and log in once using your Microsoft account password. This will allow your Microsoft account password to be verified for subsequent Remote Desktop connections.

2.2 Connection Steps​

On the controlling computer:

1. Open Remote Desktop Connection (mstsc)
2. Enter the connection information

• Computer: The computer name or IP address of the controlled computer
• User name: Enter the complete Microsoft account email address
• Password: Enter your Microsoft account password

3. Connect successfully

III. Practical Comparison of the Two Login Methods​

3.1 Connection Experience Comparison​

3.2 Practical Case Comparison​

Case 1: Zhang's Office Computer (Local Account)

Zhang uses a local account to log in to Remote Desktop at his company. He needs to manually maintain the same username and password on every computer that requires remote connection. If the password changes, all computers need to be updated. The advantage is that even if the company network is disconnected, he can still log in to his computer using the local account.

Case 2: Li's Home Network (Microsoft Account)

Li uses a Microsoft account for Remote Desktop at home. He only needs to remember one password, and all his devices synchronize automatically. However, if network issues occur or Microsoft services are interrupted, the login experience might be affected. Additionally, if he changes his password on a new device, he needs to manually trigger password verification once on the controlled computer before continuing to use Remote Desktop.

IV. Common Problems and Solutions​

Problem 1: Unable to Connect to Remote Desktop​

Checklist in order:

1. Confirm Windows version support (Pro edition and above)
2. Check if Remote Desktop is enabled
3. Confirm the firewall allows Remote Desktop (usually configured automatically when enabled)
4. Verify the account has remote login permissions
5. Confirm the account has a password set
6. Test network connectivity: ping target IP

Problem 2: Microsoft Account Login Fails​

Possible causes and solutions:

• Local password verification not triggered: Log in to Windows once using your Microsoft account password.
• Password changed: Re-execute the password verification command to update the password.
• Account locked: Unlock the account by logging into the Microsoft website.

Problem 3: Credentials Cannot Be Verified​

• Ensure the username format is correct (local account uses username, Microsoft account uses full email).
• Check if the password is correct.
• Try adding a domain prefix before the username: Computer Name\Username or MicrosoftAccount\Email Name.

V. Xiaoye Remote Desktop's Support for Microsoft Accounts​

Xiaoye Remote Desktop also supports accessing Remote Desktop using a Microsoft account, provided that your Windows Remote Desktop meets the prerequisites mentioned in Chapter II.

Conclusion​

Choosing between a local account and a Microsoft account for Remote Desktop login depends on your specific needs:

• If you are in a standalone environment or internal network, focusing on simplicity and directness, a local account is perfectly sufficient.
• If you need multi-device synchronization, cloud service integration, and want to simplify password management, a Microsoft account is more suitable.

Regardless of the choice, proper configuration and security awareness are key to ensuring a smooth and secure remote working experience. We hope this guide helps you easily build a stable and secure remote working environment!