When you're working in Windows Networking - that is, the ability to share files, using named resources, between computers - you'll find sometimes that you can't access the files on one computer. Sometimes, you can't even see the files on another computer.
The challenge here is that the inability to see the files on another computer might be something as simple as your having kicked the network cable loose - or it might come from your having given a different workgroup name to the other computer. But how are you going to diagnose the problem?
Some folks will tell you, immediately
If you don't see the other computer in My Network Places, go to Entire Network - Microsoft Windows Network, and look there.
Now, if your physical network is solid, and the Internet Protocol is properly configured, then checking in Entire Network for a missing computer name is one of the next logical steps. But be aware of the lower layers, and check them, at least briefly. Maybe your network cable is broken, AND your computers are in different workgroups.
As I point out in Solving Network Problems - A Tutorial, Windows Networking is based on the OSI Network Model.
- Windows Networking, in its default state, uses an application interface called NetBIOS Over TCP.
- NetBIOS Over TCP, aka NetBT, uses TCP/IP for the logical network.
- And in your home or small office, you'll likely have either Ethernet or WiFi. TCP/IP uses Ethernet, WiFi, and similar transports for physical connectivity.
When you test, observe those layers. Test from the bottom up.
- Test Layers 1 & 2 - Physical & Data Link. If you have Ethernet, you'll have an Ethernet cable connecting either 2 computers, or one computer and a hub / switch / router. If you have WiFi, you'll have a computer connected to another computer, or to a similar WiFi hub / switch. Physical devices like Ethernet adapters, WiFi adapters, and hubs / switches / routers have diagnostics. Most have multi-colour lights. Find out about the diagnostics for each device. Learn what each colour means, and how it tells you that it detects a connection (or not).
- Test Layer 3 - Network. If you verify that your computer is physically connected to another computer, or to the hub / switch / router, next check your IP settings. First, verify that the settings are good, using "ipconfig /all". Next, ping the other computer, or the router, and make sure that you get a consistent reply. If you get a partial reply (with some dropped packets), or if the reply time from the other device varies widely, do some more research. Here's where PingPlotter may come in handy.
- Test Layer 7 - Application. If IPConfig and Ping indicate a good, solid, logical connection, look in My Network Places. If you don't see what you're hoping for, a combination of "browstat status" and "net config server" / "net config workstation" is a good diagnostic here. Coupled with "ipconfig /all", and compared against the same from the other computers involved, you can figure out just about any network problem.
- Finally, if neither "ipconfig /all", "browstat status", "net config server", nor "net config workstation" indicates a problem, then do relational analysis using CDiag and CPSServ.
I'm aware that this just scratches the surface. But it's a start.