Press ctrl-alt-delete to begin.

May 18, 2007 3:43 PM

WindowsFilter: Please help me find examples or reports that state that it is recommended / required that machines running Windows be rebooted from time to time.

So here's the setup:

A company has a product that runs on an embedded version of Windows 2000 Professional. A customer that has purchased this unit is quite happy with the products operation, but finds that after 60 to 90 days of straight uptime, he is unable to communicate with one of the features of this unit over the network. A reboot of the unit seems to correct the problem, for another 60 to 90 days.

Assuming that the problem isn't related to his network performance, and we are able to rule out a problem with the software, that leaves us with the age-old adage that computers running Windows require periodical reboots in order to function optimally.

I may have a need to back up this claim with reports or documentation from a 3rd party source, and would appreciate any help from MeFites that have experience in this or can link me to some articles or reports that support this.

(Note: If there are reports that suggest the opposite of this, they are welcome as well. No such thing as too much research.)

posted by Industrial PhD to computers & internet (22 comments total)

You won't be able to rule out a problem with the software, because that is almost certainly the cause. I've worked with a lot of Windows servers, and their uptime is as good or bad as the software they run. At least, that's been my experience. I've had Windows database servers running uninterrupted for years, for example.

That said, the easiest way to solve a lot of problems with the software you run on Windows is often to schedule reboots periodically. Software that allocates and/or releases significant amounts of memory can cause problems in Windows over time, and occasionally these problems aren't solved by simply killing the application in question.
posted by me & my monkey at 4:05 PM on May 18, 2007

I think you've fallen for an urban legend. I have not heard of any such requirement or recommendation.

The last place I worked, we were required to leave our computers running 24 hours, because they did backups remotely in the middle of the night. We never reset them, and there was no reduction in performance over periods of months.

Frankly, this sounds like Macophile anti-MS FUD.
posted by Steven C. Den Beste at 4:07 PM on May 18, 2007

Anecdotal:

I run a home media server with WinServer 2k3. I end up rebooting it every 45 days or so, just because I think I should.

It's run over 60 days with no problems, though. All it does is serve and receive files on a software RAID 5 array.
posted by SlyBevel at 4:11 PM on May 18, 2007

While I can understand why you would think that, it's far from the truth. Although I have dabbled with Linux and OSX to a fair extent, I still use XP pro as my primary OS at work and home.

I am absolutely willing to entertain the possibility that the problem is on the software level, but unfortunately the software is made by another company, and the team in our organization responsible for testing the code as we receive it are of the opinion that a computer running Windows for 90 days straight without a reboot is more like a success story than a problem.

My question lies in the area of, is there basis for this? Or do we need to hold feet to flame and revisit software? In this organization it is difficult to have resources assigned to released product, rather than development of new product, so I want as much data.
posted by Industrial PhD at 4:18 PM on May 18, 2007

I end up rebooting it every 45 days or so, just because I think I should.

This is what drives me to this question: Why do we think we should?

I do it to. Why? I find trouble pointing to a specific culprit. I understand that some programs have poor memory management that produces leaks, which would speak to this as well, but when those programs are not present, we (I) continue to do it anyway.
posted by Industrial PhD at 4:21 PM on May 18, 2007

There is sort of a basis for rebooting every 45 days: this support document is evidence. But it only applies to Win95/98, and even then to unpatched Win95/98 systems. I don't know of anything similar for Win2k. It's almost certainly, as m&mm says, a software problem.
posted by hades at 4:24 PM on May 18, 2007

Why do we think we should?

Why do we believe any superstition? Because it seems to work. If we stand in the town square in Omaha and beat on a drum, it keeps wild elephants away. How do you know?

Well, have you seen any wild elephants near Omaha?

Why do we believe it? Confirmation bias.
posted by Steven C. Den Beste at 4:27 PM on May 18, 2007

I will try and provide feedback to comments quickly.

That said, the easiest way to solve a lot of problems with the software you run on Windows is often to schedule reboots periodically. Software that allocates and/or releases significant amounts of memory can cause problems in Windows over time, and occasionally these problems aren't solved by simply killing the application in question.

In the product we do have an option of scheduling an automatic reboot, but the party that is complaining about this issue does not believe periodic reboots are an acceptable solution, as he, understandably, does not want the 3-5 minutes of downtime. (This product records video feeds for surveillance cameras.)

Most people have accepted this periodic rebooting nuisance, probably because they subscribe to the Windows reboot theories. This gentlemen does not.
posted by Industrial PhD at 4:28 PM on May 18, 2007

Most people have accepted this periodic rebooting nuisance, probably because they subscribe to the Windows reboot theories. This gentlemen does not.

I think most people accept this because most people run Windows on their personal computers. All kinds of crap happens on personal computers, which do often require reboots because of this crap.

Servers are another matter. They shouldn't require reboots except when kernel patches are applied (or not even then, if possible).

Can you provide more specific information on what fails exactly?
posted by me & my monkey at 4:38 PM on May 18, 2007

If you want to reduce the likelihood of needing to do this, and if you're certain that there are no memory leaks or whatnot in your software code, start looking at the drivers you've got running on the machine.

BSODs and the need to reboot over time is caused more often by badly written hardware drivers than by badly written userland software; they've got a deeper hook into the system, and so can cause more havoc.

Since this sounds like an industrial piece (or at least a headless appliance) it's probably the network card driver that's at fault -- at least, that's where I'd start researching.
posted by davejay at 4:45 PM on May 18, 2007

The product runs on an embedded version of Windows 2000 Professional. Most of the ports and services that do no pertain to the operation of it have been disabled for security reasons.

The software offers 2 remote interfaces. One is a web-based client that uses java, and the other is a application-based remote client that is basically an exact copy of the server's interface. They connect across the network on 3 different TCP ports that are not well-known ports.

The complaint is that after 60-90 days, the application-based program no longer connects. The web client remains functional, however.

The web-client is running from IIS which is running in the Windows portion. The application-based client is written in C++ by another company.
posted by Industrial PhD at 4:48 PM on May 18, 2007

I briefly considered the NIC driver, but when the web client still worked I didn't continue in that direction.
posted by Industrial PhD at 4:50 PM on May 18, 2007

The complaint is that after 60-90 days, the application-based program no longer connects.

After this, are there any events in either the client's or the server's event logs?

How exactly does the remote client connect? Using a well-known protocol? Is Windows authentication involved?
posted by me & my monkey at 5:16 PM on May 18, 2007

Windows authentication is not involved. The ports are in the 9000 range, TCP. I'm not sure if there is another protocol other than IP at play.

There are no error logs on the client end. I have not seen the servers log, but the server itself continues to function normally, even though it will not accept remote logins through the application-based client.
posted by Industrial PhD at 5:50 PM on May 18, 2007

Can you examine the traffiic?
posted by me & my monkey at 5:54 PM on May 18, 2007

Unfortunately I'm in california and the equipment is in canada. they are using point to point wan links so i cannot access it. I don't trust the guy to use wireshark / ethereal.
posted by Industrial PhD at 6:13 PM on May 18, 2007

I'm going to be blunt: "reboot periodically" is a cop-out. There is nothing in the current version of Windows server that requires such a thing. There are a lot of Windows servers out there (tens of thousands) which have run continuously for much longer periods of time than you describe without any cumulative degradation of performance.

If the application program is causing some sort of accumulating damage (e.g. a memory leak, heap fragmentation) then it's an application bug and the proper solution is to find and fix it.

Which may require you to go onsite to Canada.
posted by Steven C. Den Beste at 7:29 PM on May 18, 2007

FWIW, both the Windows 2003 school servers I manage have completely stopped suffering random System Stop errors since I set up a scheduled task to reboot them every Sunday night. Sorry I can't give you chapter and verse on what was actually causing them to die. I spent about two hours digging through logs and looking at performance metrics before deciding that a periodic reboot was worth trying as a stopgap, only to find that the stopgap works just fine. I no longer care what was killing Windows. But then, I *am* a Linux fanboi.
posted by flabdablet at 7:57 PM on May 18, 2007

Blunt works. I completely accept the notion that it's a cop-out. Hence my quest to determine if there was fact supporting that claim. For the mostpart, as you can plainly see in this thread, the facts tend to lean the other way.

This thread has answered my question for the most part, and introduced curious other questions as well, that I will investigate.

Thank you all.
posted by Industrial PhD at 9:38 PM on May 18, 2007

This Microsoft support document mentions the need to reboot Windows 2000 49.7 days after starting the print spooler, which will hang and stop accepting jobs after that amount of time. A patch was made available. Perhaps it wasn't applied to the embedded software in the device? Via.
posted by lhauser at 10:22 PM on May 18, 2007

I totally agree with SCDB, by the way, that it's a cop-out. But since there's a large percentage of Windows Server users for whom a weekly or monthly reboot causes no negative consequences whatsoever, and since most of what runs on a typical Windows box is closed-source software with spotty or even nonexistent vendor support, it's a cop-out that saves a lot of sysadmins a lot of time.

I think it's going to be at least a decade before Windows culture shifts to the point where this particular cop-out is generally thought of as unacceptable, along with the the assumption that it's OK to require administrative or even "power user" rights to make apps run properly. The norms of Windows 98 are burned deep into the brains of the Windows community :-)
posted by flabdablet at 12:17 AM on May 19, 2007

There were a bunch of problems affecting Windows flavors from 95 through 2000 involving a timer rolling over to 0 after 49.7 days, and there was a time when rebooting more often than that was recommended. They may have all been patched before 2000 went unsupported; I'm not sure.
posted by Zed_Lopez at 3:23 PM on May 19, 2007