7 ms·
Why Windows 95 and 98 would crash after 49.7 days of uptime
- The_suffocated 7y agoThis bug reminds me of the plot of the 1996 Japanese crime story "Subete ga F ni Naru" (The Perfect Insider).
- serf 7y agothe story that makes you love an incestuous homicidal genius. I thought the anime really glossed over that story terribly.
- hncensorsnonpc 7y agoFrom what thine is this? It says "There IS a bug ... NOW patched" Should make no sense anyway but I see no time attached to this.
- jaclaz 7y agoThe cited MS KB has been archived starting November 9, 2004: https://web.archive.org/web/20041109020858/http://support.microsoft.com/kb/q216641/ https://web.archive.org/web/20041109020858/http://support.mi... It is dated August 2004 (it is revision 3.2) but the patch (for Windows 98) has a date: Release Date: Jun-04-1999
- greggturkington 7y agoThere's a CNN article about it from 1999 too: http://www.cnn.com/TECH/computing/9903/05/win98bugfix.idg/ http://www.cnn.com/TECH/computing/9903/05/win98bugfix.idg/
- deleted 7y ago[deleted]
- chrisbennet 7y agoI underlying "bug" [GetTickCount()] is still a danger/pot hole that you need to watch out for. I think it is timeless, especially for those who don't have scars from encountering it before.
- cafard 7y agoIn one of Jon Bentley's "Pearls" books is a chapter of rules of thumb. One states that "Pi seconds is a nanocentury."
- justanotherc 7y agoNowadays you don't even get CLOSE to 49 days uptime before Win10 forces you to restart due to updates ;s
- webmobdev 7y agoWell, that's one way to the fix the bug ... ;)
- tsomctl 7y agoMy laptop with Win10 is at 72 days. I created a bat file with: net stop wuauserv sc config wuauserv start= disabled and then scheduled it to run every 10 minutes. The problem with that is you now have to remember to disable it and check for updates when you have time, which I'm obviously not doing.
- 7777fps 7y agoYou're oddly proud about not having updated your OS for 72 days.
- tsomctl 7y agoNo, I'm proud that I haven't rebooted in 72 days. The last clause was me acknowledging that this isn't good computer hygiene. edit: And I'm trying to help other people. I know how infuriating it is to have your computer restart in the middle of something, and the above fix is pretty straightforward.
- baybal2 7y agoI think having to disable the autoupdate in win10 is the most requested thing for IT helpdesks these days. As a result of this complete ignorance to ergonomics, the windows ecosystem is returning back to WinXP years, and windows users are now getting pwned by years old exploits again. I think microsoft best achievement in win7 was that it was working "out of the box" without having to hack it. Now, win10 again requires to be hacked right out of the box just to work. People now install stuff like https://www.novirusthanks.org/products/win-update-stop/ https://www.novirusthanks.org/products/win-update-stop/ or https://securityxploded.com/windows-autoupdate-disable.php https://securityxploded.com/windows-autoupdate-disable.php and countless others. But when they finally need to update, the half broken windows install may give up the ghost, because the update script can't account for hundreds of ways how windows internals may have been altered, and so they learn to not to update at all, and switch to antiviruses, qihoo and other "crapware clearners" in the end
- sitzkrieg 7y agounfortunately recreated this issue recently keeping track of freertos current tick on a 32 bit embedded system :)
- ggambetta 7y agoThis is a pretty uninformative article. It doesn't actually say why Windows would crash, as the title promises. It does some trivial math, points out there's an overflow, and then says "Clearly some code in Windows didn’t handle this too well, and Windows hung."
- usr1106 7y agoI don't agree. Nobody of the readers would care about the programming error made 25 years ago in some closed source code. However, timers wrapping around is a very current problem every programmer should be aware of. Not too long ago we had a problem with corrupted video files. After weeks of investigation it turned out that some code used an 32 bit unsigned to count microseconds. Well, that wraps around after approx. 1 h 10 min... Obviously most test cases were videos shorter than that.
- yummybear 7y agoI'm a reader and care, so at least one.
- usr1106 7y agoFair enough. If you stick to open source, then you can always know how programmers got it wrong in the past and present.
- derefr 7y agoNo, that allows you to know how programmers of FOSS got it wrong. Not all programming is the same; there are many lessons to learn about software engineering (mostly in the "what not to do" sense) which, for practical reasons, have only ever showed up in (time- and budget-constrained) closed-source codebases.
- usr1106 7y agoDo you you have any fact-based evidence that certain bugs/anti-patterns would happen less in open source code bases or free software code bases? Well, security by obscurity might happen a bit less. And hopefully many bugs in contributions are spotted instead of being merged because the author thinks it should work. But all major open source projects have had amazingly "stupid" programming bugs that went undiscovered for many years. Or the same feature has been patched again and again, but still causes more trouble. Knowing that many company-internal software projects work with little review and very low testing coverage, it should be natural that their code quality is even worse. But that certain kinds of problems would only occur in closed source does not sound evident to me.
- Wowfunhappy 7y agoIs there a good way to test for bugs like this during development? Since it’s not particularly realistic to pause development for two months to see what a given build does after that long.
- yatsyk 7y agoWhen you start development version of Windows CE or Windows Embedded (don’t remember exactly which one) tick count timer wasn’t set to zero but max dword minus number of milliseconds in two minutes. So counter overflows in 2 minutes after system start. This is very smart way to catch such bugs.
- LennyWhiteJr 7y agoThe same way you test for leap-year bugs, write unit-tested code that tests all your boundary conditions.
- mrlala 7y agoHmm that doesn't seem to be the same thing.. it's easy to test for leap-year, that's a simple case you can either test in the code or literally change your computer clock and let it rollover to see what happens. Very different than something which only happens after 50 days because obviously in small intervals it's not a noticeable bug.
- LennyWhiteJr 7y agoThe 50 days is arbitrary - the owners of GetTickTime should have written tests to handle what happens when the tick value rolls over. (Maybe they did, and allowing it to roll over was the desired behavior.) But more to the point - the consumers of GetTickTime should have also had tests to verify that the consuming code appropriately handles time rollovers. Granted, this was Win95 so I'll cut them some slack, but that should be standard procedure for any code that consumes an incrementing counter API. First question should always be - 'how will this code handle a rollover value'?
- treesknees 7y ago
- ajross 7y agoThis brings up a good meta point: people who like to complain about the quality of software in the modern world almost certainly didn't live through the early[1] days of the industry. This sounds crazy to modern ears, but at the time the idea of a desktop system actually staying booted for a whole month was weird and alien. They just didn't do that. Commercial unixes were better. It was routine to find servers that had been running for three digit (!!) uptimes, and people would brag about stuff like this. Linux, when it arrived, was in this category too and we'd all puff to our friends about how we "never turn off" the machine under our desk, because it would always be able to run for a month or so before it crashed. It was just a different world, and things, despite some of the community emotion, have gotten vastly better. We're much better at writing software than we used to be, which tends to make some of old folks a little confused when people hold up "new" ideas as being paradigm shifts in software quality. We already had the shift! We're just picking the higher hanging fruit now. [1] Do the mid-90's even count as early?
- rapind 7y agoI have a Hackintosh running High Sierra, and at most I reboot once a month.
- blackoil 7y ago<rant> The problem is not people writing buggy software or them crashing. At least for me problem is we keep on reinventing the wheel, without corresponding increase in productivity. I don't see people cranking s/w better or faster then they did with Delphi in 1998. Instead of standing on shoulders of the giants we disrespect them, our whole industry is built on abusing all the hardware and technology gains for frivolous wars and gains. </rant>
- jaclaz 7y agoWell, there are huge differences (in the MS world) between 9x and NT. DOS (before) was very, very stable (but of course was not multitasking) and widely used in industrial setups. Windows NT (before Win9x) and Windows 2000 (right after) were both, very, very stable, I had machines running 24/7/365 that were rebooted once a year or so and for other reasons (maintenance/update, hardware replacement, black outs longer than UPS capability, etc.).
- dooglius 7y agoIn fairness, I have hit this exact same problem on Linux
- chrisbennet 7y agoBack in 2005 I had encountered this bug or something similar. It was in Windows CE, the embedded version of Windows. For me, it failed at around 25 day (49.7/2?). I believe the documentation at the time [since fixed] might have had GetTickCount() returning an integer instead of an unsigned integer. I had a devil of a time tracking it down!
- ryanschneider 7y agoI worked on a service that had this exact issue; actually it was worse because it was a signed integer so rolled over in half the time. Even more insidious, we never hit the issue until months into production because we had a pretty consistent two week release process. So the issue only came to light when development slowed down as the project became more stable. Luckily deployments were staggered across datacenters so when the bug hit it didn’t happen to every server at once, but of course as always happens, when it did, the majority of the servers started hanging over the weekend while I was on call.
- yjftsjthsd-h 7y agoI worked at a company with a similar issue. The server is used to get patched and rebooted every month. Then the company decided to lay off huge chunks of operations staff. The software held up remarkably well, but we eventually discovered that software that was never designed to stay up for more than a month will leak memory like crazy if you leave it up for a long enough.
- sn_master 7y agoIIS used (still does?) to randomly kill its own processes at random because chances are, if its been running "long enough" its leaking memory anyway.
- OliverJones 7y agoIf you think this is cool, wait'll you see what un-upgraded UNIX-derived systems do on Jan 19, 2038 at 03:14:07Z.
- OliverJones 7y agoUpdate: new kernel are on top of this problem. https://lkml.org/lkml/2020/1/29/355?anz=web https://lkml.org/lkml/2020/1/29/355?anz=web It's the old systems that will suffer. Hopefully only soda machines and not avionics or intravenous infusion pumps.
- Yizahi 7y agoYeah, that happens. Here is an example of an actual bug opened a few years ago on our system. Dev team spend some time tracking the issue and found out incorrect variable type used for sessions, it was unsigned long used for milliseconds, like in the OP. We were joking that we need to allocate 50 days to verify the fix :) . https://imgur.com/a/HS3fcTj https://imgur.com/a/HS3fcTj
- lmilcin 7y agoThis is a myth that cannot be proven or disproven. Nobody was ever able to keep Windows 95/98 up for that long. Jokes aside, around 2001 I was asked to do some maintenance on a machine running Windows 3.11 that was running an app to control all access within the building. When I asked about potential upgrade the guys balked at me saying the machine has couple of years of uptime and they are not very keen to have to restart it on a schedule due to windows 95/98 bugs.
- me_me_me 7y agoThat's the reason we still have COBOL and similar systems working. For exact this reason. They are working and doing what they meant to be doing.
- miles-po 7y ago49.7 days? I wish I could get more than 7 out of my MacOS Catalina laptops before I get a gray screen.