There are moments when a technical problem seems to point towards failing hardware. A slow laptop, an old operating system, or an aging browser often becomes the first suspect. However, real-world troubleshooting frequently tells a different story.

This article walks through a real troubleshooting session where GitHub Codespaces refused to load on one Windows laptop while working perfectly on another device connected to the same Wi-Fi network. Instead of replacing the laptop, a systematic investigation revealed that the real culprit was a simple DNS configuration.

If you ever encounter a similar problem, this guide may save you hours of frustration—and possibly thousands of rupees.

---

The Problem

A GitHub Codespace opened normally on one device but remained stuck on the message:

Setting up your codespace

The issue occurred consistently on an HP Windows laptop.

Interestingly,

• GitHub itself opened normally.
• The user could log in successfully.
• Chrome and Microsoft Edge both showed the same behaviour.
• The same GitHub account worked perfectly on another device using the same internet connection.

This immediately suggested that the problem was probably not with GitHub.

---

First Thoughts

Many people would naturally assume:

• The laptop is too old.
• Windows is outdated.
• The browser is incompatible.
• It’s time to purchase a new computer.

That would have been an expensive mistake.

Instead of replacing hardware, the issue was investigated step by step.

---

Step 1 – Rule Out Browser Problems

Both browsers were tested.

• Google Chrome ❌
• Microsoft Edge ❌

Since both browsers behaved identically, it became unlikely that Chrome itself was responsible.

---

Step 2 – Check Proxy Settings

The following command was executed:

netsh winhttp show proxy

Result:

Direct access (no proxy server)

This ruled out proxy configuration as the cause.

---

Step 3 – Open Browser Developer Tools

Chrome Developer Tools (F12) were opened.

Initially, the Network tab showed several failed requests.

The important observation was that JavaScript files from GitHub’s asset server were failing to load.

This meant the browser could not download files required to start Codespaces.

---

Step 4 – Investigate DNS Resolution

The next step was checking whether GitHub domains could be resolved.

The command

nslookup github.dev

worked successfully.

However,

nslookup assets.github.dev

returned

Query refused

This was the first major clue.

The DNS server was refusing requests for one of the domains required by GitHub Codespaces.

---

Step 5 – Don’t Jump to Conclusions

At this stage, it would have been very easy to conclude that

• Windows was corrupted,
• the browser was broken,
• or the laptop had become obsolete.

None of those assumptions were correct.

The evidence pointed towards DNS.

Good troubleshooting always follows evidence rather than assumptions.

---

Step 6 – Change DNS Servers

Instead of using the default DNS supplied by the internet provider, the DNS servers were changed to Cloudflare.

Preferred DNS

1.1.1.1

Alternate DNS

1.0.0.1

This can be configured from

Network Adapter
→ Properties
→ Internet Protocol Version 4 (TCP/IPv4)

---

Step 7 – Flush the DNS Cache

After changing DNS, the following command was executed:

ipconfig /flushdns

This removes cached DNS entries so Windows begins using the new DNS server immediately.

---

Step 8 – Verify the Fix

Running

nslookup assets.github.dev

now returned valid IP addresses instead of “Query refused.”

This confirmed that the DNS issue had been resolved.

At this point, GitHub Codespaces was finally able to download the JavaScript files required to start.

---

Lessons Learned

Several valuable lessons came out of this troubleshooting exercise.

1. Never blame the hardware first

An older laptop does not automatically mean faulty hardware.

Many software and networking issues produce symptoms that resemble hardware failures.

---

2. Compare with another device

Since another device worked on the same internet connection, GitHub itself was quickly ruled out.

Comparisons like this dramatically reduce troubleshooting time.

---

3. Browser Developer Tools are incredibly useful

Opening the Network tab revealed that JavaScript files were failing to download.

Without that clue, troubleshooting would have taken much longer.

---

4. DNS problems can appear in unexpected ways

Most people think DNS only affects opening websites.

In reality, modern web applications often depend on multiple domains.

If even one required domain cannot be resolved, the entire application may fail.

---

5. Work systematically

Rather than guessing, eliminate one possibility at a time.

In this case, the following possibilities were ruled out:

• Browser
• GitHub account
• Internet connection
• Proxy
• Hardware

Only then did DNS become the obvious suspect.

---

Commands Used During Troubleshooting

Check proxy

netsh winhttp show proxy

Check GitHub domain

nslookup github.dev

Check GitHub assets

nslookup assets.github.dev

Flush DNS cache

ipconfig /flushdns

---

Final Thoughts

One of the biggest mistakes people make during troubleshooting is assuming that the most expensive explanation is the correct one.

When software refuses to work, it’s tempting to think:

“My laptop has become too old.”

In this real-world case, that assumption would have been completely wrong.

The solution wasn’t a faster processor, more RAM, or a new computer.

It was simply replacing an uncooperative DNS server with a reliable public DNS provider.

A few minutes of careful investigation solved a problem that could easily have resulted in an unnecessary laptop purchase.

Good troubleshooting is one of the most valuable technical skills you can develop. It saves time, reduces frustration, and often saves money by preventing unnecessary upgrades.