Fix Error 0x104 & Hex to Decimal Guide (260)

You likely stumbled upon "0x104" while hunting for a quick decimal conversion or battling a stubborn connection failure. If you just needed the math: 0x104 is 260 in decimal. That’s the informational answer, delivered immediately.

But if you’re reading this because your computer is throwing a red error code and you’re stuck in a coffee shop trying to reach your home PC, you’re not alone. In my 15 years of troubleshooting network environments, I’ve seen the error code 0x104 cause more panic than it warrants. It’s the classic "PC Can’t Be Found" message from Windows Remote Desktop. While the hex value itself is just a number, the specific 0x104 failure in RDP contexts usually points to a breakdown in name resolution or network routing, not a hardware failure.

This guide bridges that gap. We’ll start with the basics of hexadecimal notation to satisfy the "math" intent, then dive deep into the technical reality of why your remote session is failing. Whether you’re trying to connect from within your home LAN or across the entire internet, the decision tree below will help you pinpoint the exact friction point.

What is 0x104? Hexadecimal Notation & Decimal Conversion

Before we fix the error, let’s clear up the linguistic confusion. In computer science, numbers often look like gibberish to non-developers. The "0x" prefix is the standard convention in C, C++, and many other languages to denote a hexadecimal (base-16) integer. It’s a shorthand that tells the compiler: "Don't treat this as a decimal number; treat it as a base-16 value."

Understanding Base 16 & Hexadecimal Notation

Hexadecimal uses sixteen distinct symbols: the standard digits 0-9, plus the letters A-F to represent values 10 through 15. This base-16 system is fundamental to how memory addresses are displayed in debuggers and low-level programming. When you see 0x104, you are looking at a valid integer representation. It is not inherently an "error" in the mathematical sense; it’s just a number.

Think of it like a language barrier. In decimal (base-10), we use ten fingers. In binary (base-2), we use on/off states. In hex, we’re essentially grouping bits into nibbles (4-bit chunks) to make them human-readable. 0x104 is simply the hex way of writing the number 260. It appears frequently in memory dumps because hex makes it easy to see byte boundaries. If you’ve ever peeked at a system log, you’ve likely seen these values floating around. They’re just addresses, offsets, or codes waiting to be interpreted.

Converting 0x104 to Decimal (Step-by-Step)

If you’re the type who prefers to know why the number is what it is, here is the positional breakdown. In base-16, each digit represents a power of 16, starting from the right at $16^0$.

To convert 0x104, we expand it as follows:

1. The '1' (leftmost): $1 \times 16^2 = 1 \times 256 = 256$
2. The '0' (middle): $0 \times 16^1 = 0 \times 16 = 0$
3. The '4' (rightmost): $4 \times 16^0 = 4 \times 1 = 4$

Summing these up: $256 + 0 + 4 = 260$.

For a quick-check in code, here’s a Python snippet you can run in any terminal:

hex_value = 0x104
print(hex_value)  # Output: 260

In C, you’d simply cast it: int val = 0x104;. This confirms the decimal equivalent is exactly 260. Keep this in mind; if a tool outputs "260" as a status code, it might be displaying the hex value in decimal form, or vice versa. Context is king.

Diagnosing the '0x104 Error' in Remote Desktop Connections

Now, let’s pivot to the frustration. When Windows Remote Desktop Connection (mstsc.exe) spits out error 0x104, it’s usually accompanied by the text: "We couldn't connect to the remote PC because the PC can't be found." This is where most users get stuck. They assume the PC is off. They aren’t. The PC is likely on, but your client can’t "find" it in the network fabric.

What Does Error Code 0x104 Mean? (The 'PC Not Found' Issue)

In my experience, this error code is a symptom, not a disease. The root cause is almost always a mismatch between how the client is trying to locate the host and how the network allows that location to happen.

There are two distinct realms here: Internal LAN and External Internet.

• Internal: You’re on the same Wi-Fi or cable network. The client uses NetBIOS or DNS to resolve the computer name (e.g., DESKTOP-ABC123). If that name resolution fails, you get 0x104.
• External: You’re on a cafe Wi-Fi or mobile data. You cannot use the local hostname. The Internet doesn’t know what DESKTOP-ABC123 is. It only knows IP addresses or public DNS names. If you try to use the local name from outside, the error is immediate.

This is the "PC Not Found" issue in its most literal form. The client is shouting into a void where no one answers.

Clarifying 0x104 vs 0x1104

You might notice forum threads mentioning 0x1104. These are cousins. While 0x104 strictly means "host not found," 0x1104 often points to similar connectivity gateway issues or specific timeout values in the RDP negotiation process.

Differentiating them is tricky because both stem from the client failing to establish a TCP handshake on port 3389. However, I’ve found that 0x1104 can sometimes indicate a specific failure in the certificate or security negotiation after the initial connection is partially established. For the average user, the fix is nearly identical: ensure you’re using the correct IP/hostname and that the port is open. Don’t get bogged down in the hex difference unless you’re a developer debugging the RDP protocol stack itself.

Environment-Specific Troubleshooting Decision Tree

Generic lists like "check your firewall" are useless if you don’t know which firewall or which network segment we’re talking about. I structure my troubleshooting into three scenarios. Find yours below.

Scenario A: Home Network & Local LAN Failures

If you’re sitting in the same house as the target PC, and it’s failing, this is a DNS or Discovery issue.

1. Kill the Name, Use the IP. The fastest way to diagnose this is to bypass name resolution entirely. Open Command Prompt on the target PC and find its local IP (usually 192.168.1.x or 192.168.0.x). On your client machine, enter this IP address into the Remote Desktop Connection box, not the computer name.

   • If it works: Your problem is DNS/NetBIOS. The name isn’t resolving.
   • If it still fails: Your problem is the firewall or RDP service.

2. Verify Network Discovery. In Windows, some Home networks have "Public" profiles enabled by mistake. Go to Control Panel > Network and Sharing Center > Change advanced sharing settings. Ensure "Network discovery" is turned ON for Private networks.

3. Check the RDP Service. On the target PC, press Win + R, type services.msc, and look for "Remote Desktop Services." Ensure it is Running. If it’s stopped, start it. This is the most basic check, yet I’ve seen it missed by hundreds of users.

Scenario B: Connecting from Outside the House (Internet)

This is where the "Error 0x104" becomes a physics problem. Your local name is invisible to the outside world.

The Core Concept: Port Forwarding To connect from outside, you must tell your ISP’s router to let traffic for port 3389 (the RDP port) through to your internal PC. This is called port forwarding.

• Step 1: Find your Public IP. Search "What is my IP" on your external device. Remember this number. It changes if you restart your router (Dynamic IP).

• Step 2: Log into your Router. Usually 192.168.1.1 or 192.168.0.1. Find the "Port Forwarding" or "Virtual Servers" section.

• Step 3: Create a Rule.

  • Service Name: RDP
  • Protocol: TCP
  • External Port: 3389
  • Internal IP: The static local IP of your target PC (e.g., 192.168.1.50)
  • Internal Port: 3389

• Step 4: Connect. Use your Public IP: [PublicIP]:3389 in the Remote Desktop box.

Security Warning: I cannot stress this enough: Do not expose port 3389 to the open internet without protection. RDP is the #1 target for brute-force attacks.

• Better Alternative 1: Use an RDP Gateway (RD Gateway) which uses HTTPS (443), which is less frequently scanned by bots.
• Better Alternative 2: Use a VPN (like Tailscale or ZeroTier). This is the cleanest solution. It creates a private tunnel, so you can use your local hostname from anywhere in the world, without opening firewall ports.

Dynamic DNS (DDNS): If your ISP gives you a changing IP, set up a free DDNS service (like No-IP.com). Your router will update the hostname (e.g., myhome.ddns.net) whenever the IP changes. You connect to the hostname instead of the raw IP.

Scenario C: macOS 'Windows App' & Mobile Client Issues

If you’re using the "Windows App" (formerly Remote Desktop) on a Mac, or a mobile client on Android/iPad, the "0x104" error often looks the same but the cause is different.

The macOS Local Network Permission (The Silent Killer) In recent versions of macOS (Mojave and later), Apple introduced strict privacy controls. If the "Local Network" permission was denied or reset after an update, the app cannot see the local IP addresses of other devices. It will fail to find the host, resulting in a "not found" error, even if the IP is hardcoded.

• Fix: Go to System Settings > Privacy & Security > Local Network. Find the "Windows App" (or your RDP client) and toggle it ON. You may need to restart the app for it to re-scan the network.

Mobile Clients On Android/iPad apps (like the Microsoft Remote Desktop app), ensure you are adding the connection using the Public IP if you are off-network. Also, check that your device’s network adapter isn't set to "Airplane Mode" or if a Wi-Fi captive portal (like in a library) is blocking non-HTTPS traffic. RDP traffic often gets blocked by corporate or public firewalls because it’s not encrypted by default (unless you use RD Gateway).

Advanced Context: 0x104 as a Memory Address & System Offset

For the developers and debuggers among us, 0x104 is just an offset. It’s decimal 260. In C programming, you might see this value when traversing large structs or reading memory headers.

Low-Level Programming & Debugging

If you’re writing a driver or parsing a file format, 0x104 might point to the 260th byte of a header. For example, in some proprietary or legacy data structures, an offset of 0x104 might hold a checksum or a pointer to a payload.

Consider this C snippet:

struct DataHeader {
    uint32_t magic;
    // ... fields up to offset 0x100 ...
    uint8_t reserved[4]; // Ends at 0x104
    uint32_t payload_offset; // Starts at 0x104
};

// Accessing the field
DWORD offset = header.payload_offset;

In crash dumps, if an exception occurs with a pointer near 0x...104, it’s likely a buffer overflow or a null pointer dereference where the pointer got corrupted by exactly 260 bytes. This is rare for general users but critical for those debugging kernel mode drivers.

A Note on HTTP: Just to clarify a common confusion: 0x104 (260) is NOT a standard HTTP status code. HTTP 1.1 defines codes like 200 (OK), 404 (Not Found), 500 (Internal Error). There is no standard code 260. If you see "260" in a web API log, it’s a custom application-level status code defined by that specific software. Don’t waste time looking for it in the IETF RFCs.

FAQ

How to fix error code 0x104 on Mac specifically?

If you are using the "Windows App" on a Mac and hitting this error, the most frequent fix is granting Local Network permissions. Navigate to System Settings > Privacy & Security > Local Network and ensure the switch for the Windows App is enabled. If that doesn't work, try entering the target PC's local IP address directly instead of the hostname, as name resolution on Macs can sometimes behave differently than on Windows.

What is the decimal value of 0x104?

The decimal value of 0x104 is 260. You can calculate this manually: $(1 \times 16^2) + (0 \times 16^1) + (4 \times 16^0) = 256 + 0 + 4 = 260$.

Is 0x104 a common error code in Windows?

It is a common symptom in Remote Desktop Connection, but it’s not a universal Windows system error code like 0x80070057 (Parameter incorrect). In the context of RDP, 0x104 specifically indicates that the target host could not be resolved or reached. It typically points to firewall blocks, incorrect IP/hostname usage, or DNS failures, rather than a bug in the OS itself.

Conclusion

0x104 is a chameleon. To a mathematician, it’s 260. To a developer, it’s an offset. But to the majority of users reading this, it’s the dreaded "PC Not Found" error blocking their remote work.

If you’re stuck, go back to the decision tree:

1. Inside the house? Use the IP, not the name. Check Network Discovery.
2. Outside the house? You need Port Forwarding (with caution) or a VPN. A local name will never work externally.
3. On a Mac? Check Local Network permissions in Privacy settings.

I recommend securing your external access with a VPN like Tailscale rather than exposing raw RDP ports to the internet. It’s the same price (free for personal use) but infinitely safer.

Next Step: If you’re setting up port forwarding, download our free 'RDP Port Forwarding Checklist' PDF from the link below to ensure you don’t miss a single router setting. Or, drop a comment describing your specific network setup (Home/Work, Device Types) and I’ll help you diagnose the exact bottleneck.