Last Updated on September 30, 2010 by Dave Farquhar
Fixing an unexplainable slowdown. You may never see this. Yesterday I struggled for about 5 hours on a Win98 laptop that was incredibly sluggish. It would just pause for several minutes in the middle of anything, for no good reason. Open up Control Panel and wait. And wait. And wait. Finally the icons would show up. Open a new browser window, same thing. And almost any time an application had to open a new dialog box, you’d have to hurry up and wait.
I couldn’t find anything especially wrong with the configuration. I made some tweaks, sure–I always do–and that improved speed during those non-idle times, but it would still go catatonic on me. I downloaded WinTop and ran it so I could see what the CPU was doing. I found nothing unusual. The CPU was mostly idle.
“Gotta be a network problem,” I told our networking guy. So he went and grabbed his ultimate l337 h4x0r tool, a Micron laptop loaded down with Linux and packet sniffers and analyzers. He ran Ethereal and just watched. There was no weird network activity, and nothing particularly heavy. But we noticed the laptop was chatting away an awful lot with a server two T-1s and two routers away on our WAN, and sometimes it didn’t get a response. I pulled all of the shares on that server and every other reference I could find, but they just kept chattering.
Finally, on a reboot, I watched autoexec.bat roll by (I had the Windows splash screen turned off) and I noticed the suspicious path–that server’s UNC was in the path statement! And futhermore, C:Windows, C:WindowsSystem, and C:WindowsCommand were not! No wonder the system was running like garbage–it was looking for stuff two routers away before it looked in its own system directories!
When I removed that line and pulled a desktop shortcut that referred to that server, all was well.
One of the server-hosted apps we run requires that directory be in the path. If you have to do that sort of thing in a WAN environment, rather than adding lines to autoexec.bat, you’re much better off writing a batch file that does this:
path c:windows;c:windowssystem;c:windowscommand;[path to application on server] [command to execute application]
Then put that batch file on the desktop, instead of a shortcut directly to the app. That way, when your laptop road warriors are away, those changes won’t slow their laptops to a crawl. And the laptop won’t start trolling the network until after they’ve run that application once that day. Since networks are an order of magnitude slower than local hard drives, the system will run slightly better in the office as well. And remember when you construct your path statements, always put the system directories first, and application directories last, with local applications taking precedence over apps on network drives.
David Farquhar is a computer security professional, entrepreneur, and author. He started his career as a part-time computer technician in 1994, worked his way up to system administrator by 1997, and has specialized in vulnerability management since 2013. He invests in real estate on the side and his hobbies include O gauge trains, baseball cards, and retro computers and video games. A University of Missouri graduate, he holds CISSP and Security+ certifications. He lives in St. Louis with his family.
One thought on “Solving a perplexing slowdown problem”
Surely, you want $PATH;[path to application on server] or do *all* of your users have windows in c:windows? What about the Windows 2000 ones?
Comments are closed.