Windows 7 reliability scorecard - looking good!

Windows 7 reliability scorecard - looking good!

Summary: I've been running various builds of Windows 7 on a number of systems here at the lab since December of last year. Over time, Windows 7 became my default OS on several systems that are in daily use. During that time I've captured a lot of real-world reliability data for the OS.

SHARE:

I've been running various builds of Windows 7 on a number of systems here at the lab since December of last year. Over time, Windows 7 became my default OS on several systems that are in daily use. During that time I've captured a lot of real-world reliability data for the OS.

I'm going to be concentrating on data gathered from three heavily used Windows 7 systems. I'm going to focus on Windows 7 reliability data only for the RC (Release Candidate) and RTM (Release to Manufacturing) releases of the OS. I have data going back much further than that, but it's the final release that people are most interested in.

So, how reliable is Windows 7?

In a word, very. Even thinking back to the earliest pre-beta builds that I tried, I have always been impressed by the stability of this OS. Not only have I considered Windows 7 betas to be more stable than previous OS betas from Microsoft, they were at least as stable as Windows XP and Vista. That's very unusual for beta OS builds (heck, that's unusual for the RTM code too ...). It was obvious to me early on that Microsoft had put reliability right at the top of the list from the beginning.

Since I installed the Windows 7 RC build, and later the RTM build, the OS itself has performed almost flawlessly. In fact, after thousands of hours of usage over several systems, I've had a handful of shutdown issues (which I have fixed by updating drivers) and some problems with a few applications, in particular the third-party PDF reader Foxit. These have been harder to fix but as we edge closer to the release of Windows 7 (due October 22nd) software compatibility is getting better.

Below is a screen grab from the Windows 7 reliability Monitor on my Dell Studio XPS 13 notebook:

If I took Foxit out f the equation here, we are looking at a small number of shutdown issues having a small impact on reliability, a pattern that I see on all my Windows 7 systems. Windows 7 seems rock solid, and as drivers and applications become more mature (and they're doing so daily), reliability will improve.

Bottom line: Windows 7 is a solid, robust OS.

Topics: Windows, Microsoft, Operating Systems, Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

146 comments
Log in or register to join the discussion
  • It's very easy to keep reliability high

    when you change very little but what's on the surface.

    It's like an automobile (say a Corvette) that changes the body style every two years, but the same small block V8 (for the most part) has been in use for over 50 years. Very good reliability.
    chrome_slinky@...
    • It's not all surface

      "Minor" things like networking and scheduling got significant updates.

      I've been running Win7 since the RC was released, and running the RTM code since early August. It is indeed very stable.
      diane wilson
    • Far from only surface stuff

      There were significant changes in the kernel, including the memory manager, internals for multi-processor support and the storage and networking systems.

      To use your Corvette analogy, the body was changed, the engine replaced, and a new transmission put in. Truly a new model.
      oldsysprog
    • They made some important under-the-hood changes as well

      They made some important under-the-hood changes
      as well.

      Two very important things they changed in
      Windows 7:

      -Booting now takes advantage of multiple cores,
      and is much faster now.

      -The graphics rendering also now takes advantage
      of multiple cores, and they made some changes so
      that applications can use the graphics
      simultaneously without waiting for each other.

      There are more changes, but performance was a
      big part of Windows 7. They did quite a bit to
      make it perform better.
      CobraA1
    • So what you are saying...

      Is that Vista is as reliable as Windows 7?

      If they have not changed anything in Windows 7 then why is it more stable than anything before?

      Oh, your confusing longevity with reliability too.
      Bozzer
      • In my experience it is. However...

        [i]Is that Vista is as reliable as Windows 7?[/i]

        ...I haven't had nearly as much experience with Windows 7 as I have Vista. But since Vista has been rock solid on every system I'm familiar with I'd have to say they're equal at this time.
        ye
        • How can you say they're equal...

          when you haven't been using it very long...

          [i]...I haven't had nearly as much experience with Windows 7 as I have Vista. But since Vista has been rock solid on every system I'm familiar with I'd have to say they're equal at this time.[/i]
          Wintel BSOD
          • Please take note of the highlighted words in the quote...

            [i]...I haven't had nearly as much experience with Windows 7 as I have Vista. But since Vista has been rock solid on every system I'm familiar with I'd have to say they're equal [b]at this time.[/b][/i]

            ...of mine you included.
            ye
    • Reliability?! Have they fixed the Chkdsk file 9 error?!

      Reliable?! Have they fixed the Chkdsk file 9 error?! If not I have another question: What good is a Disk Operating System that cannot perform its primary task, namely, managing files on a disk -without corrupting the data?

      I've heard nothing of this fix Adrian, can you address this issue?
      emcauley
      • The chkdsk problem

        If the person who "found" the problem can
        reproduce the problem and work with Microsoft,
        then I'm sure Microsoft would be happy to help.
        Microsoft did some pretty exhaustive testing to
        find the problem.

        From what I can tell, the crashing part of the
        report was false, and the memory usage was by
        design (and should not crash).

        See this blog entry by Microsoft on details:
        http://blogs.msdn.com/e7/archive/2009/08/10/what
        -we-do-with-a-bug-report.aspx

        "What good is a Disk Operating System that
        cannot perform its primary task, namely,
        managing files on a disk"

        Chkdsk is a separate disk checking utility, and
        is 100% unrelated to ordinary file management.
        File management is normally related to NTFS
        drivers.
        CobraA1
        • You are a poor apologist

          This is not about "crashing" and either you don't know what you are talking about or you are attempting to change the subject. Neither is very flattering.

          The chkdsk file 9 problem has been reproduced many thousands of times since Windows 2000 (that's 10 years!) and Microsoft knows everything about it, except how to fix it, otherwise they would fix it. Microsoft has noted this flaw on every operating system since.

          chkdsk IS NOT an "unrelated" disk checking utility; it is a ubiquitous Microsoft utility that is installed with the Microsoft Operating System and has been considered an integral part of MS DOS and Windows for over 20 years! Where have you been?

          Further, it is Microsoft who uses chkdsk in order to "correct" problems on its own NTFS filesystem AND, it is Microsoft who wrote the code that calls the chkdsk operation in order to manage its NTFS file system.

          In addition to this, that code offers chkdsk in the form of a compelling prompt at boot time that enumerates filesystem irregularities highly recommends that the user run chkdsk.

          Either you are uninformed or you think your audience is uninformed. Either way, you are a poor apologist. Your poor apology conveys misinformation and it attempts to distract from a real technical problem that should be correct, yet has existed for ten years.

          It is completely unacceptable to allow this kind of flaw to exist in Software for a 10 months, let alone ten years. It is a game of Russian Roulette with customer data and it is completely and absolutely unacceptable! If I were managing MS's Quality team, we'd have that bug fixed in short order.

          emcauley
          • On further checking..

            the error was fixed in Windows 2000 SP4. If I google XP "CHKDSK file 9" or Vista "CHKDSK file 9" I can see other people who have had that issue but it is such a small amount that it could be down to hardware or another file system filter driver causing it. I have never seen the issue personally on thousands of machines I have looked after and never lost any data on an NTFS partition.
            planruse
          • Good effort

            I appreciate your taking the time to review the issue.

            Here's the problem: it has resurfaced in XP and Vista as a recurring defect and I assume we'll see it again in Win7.

            It has to be fixed for each release which begs several questions, the first of which is: "Why has MS not dedicated a team to resolving this issue?" If they dedicated a team then: "Why are you not requiring more of that team?"
            emcauley
          • After a bit of research . . .

            After a bit of research . . .

            . . . I found this article:
            http://support.microsoft.com/kb/327009

            Microsoft is claiming it's been fixed in the
            latest service packs in Windows 2000.

            And this article:
            http://support.microsoft.com/kb/831374/en-
            us#appliesto

            Again, Microsoft claims there's a fix, and that
            the most recent service pack fixes it.

            "chkdsk IS NOT an "unrelated" disk checking
            utility; it is a ubiquitous Microsoft utility
            that is installed with the Microsoft Operating
            System and has been considered an integral part
            of MS DOS and Windows for over 20 years!"

            "unrelated" meaning "not something you run every
            day, and usually started manually."

            "Either you are uninformed or you think your
            audience is uninformed. "

            I was uninformed, as I made assumptions about
            which chkdsk issue you were referring to. That
            has been corrected.

            "It is completely unacceptable to allow this
            kind of flaw to exist in Software for a 10
            months, let alone ten years."

            The flaw has been corrected. Both articles I
            pointed to make the claim that the latest
            service packs fix the problem, and unless
            presented with evidence to the contrary, I have
            no reason to believe they are making false
            claims.
            CobraA1
          • The flaw remains

            I appreciate your taking the time to review this issue.

            I am hopeful that Microsoft will get this issue fixed. I have no reason to kick them and frankly I used Vista Ultimate for a year before it pulled this chkdsk file 9 error trick on me. I liked the OS very much and had only two complaints: it was a resource hog and could occasionally be unstable in memory management. Both I considered minor.

            I have read a lot of file 9 error information; I dare say I have read all of the publicly available TSBs, KBs, etc.

            Here's the thing: This has occurred on every MS OS Win2K through Vista, including the server builds (2K3, etc.). Clearly the problem has not been identified and resolved. It has not been isolated because it must be fixed on each release separately.

            It was not fixed in Win2K because it appeared in Win XP. It was not fixed in XP because it appeared in Vista. It also appeared in Win2K Adv. Svr., Win 2k3 Svr. releases, etc.

            Do you see my point? It has not been resolved completely and continues to surface in each new release. They need a team on this to fix it, immediately. 10 years is a long time to have such a debilitating problem.
            emcauley
          • Hardware, perhaps? Upgrading?

            The pattern you give suggests it may be a
            hardware/driver issue. Most machines do not
            encounter the problem. I have encountered the
            issue once myself, but on a system I was
            upgrading. I figured it was due to my own
            actions, as the new OS had a different security
            setup and the user/group IDs were likely
            changing.

            A new OS generally won't recognize the old
            descriptors, as it has no idea how the old OS
            was set up. That's my reasoning, at least. I'm
            not in a good position to do a lot of testing,
            as I have no spare machines.

            The only time it should happen are in these
            cases:
            -Real corruption (drive going bad)
            -Upgrading the OS or reinstalling it

            If it happens during normal operations, then I'd
            highly suspect corruption and a possible issue
            with the drive itself. That's the kind of stuff
            that may happen when a drive is near the end of
            its useful life.

            A bug may be possible - but I doubt for this
            long. I'm suspecting it's due to the design of
            NTFS not handling OS upgrades very well.
            CobraA1
          • I think that

            the previous poster thought you were refering to the supposed bug from a few months ago that was blown out of proportion in regards to how much memory the utility uses in Windows 7.

            You are obviously referring to another issue, no need to turn your hackles red over it.
            JasonJD48
          • If it was as big a problem as you're claiming

            there'd be an order of magnitude more than 1450 results for

            chkdisk "file 9"

            on google.

            The bigger question is, which beta and/or third party partitioning or defrag tool did you run just before this happened to you?
            rtk
        • Error 404 for this link.

          Your link produces error 404
          ITOdeed
      • RE: CHKDSK FILE 9 ERRORS SOLUTION


        Basic Info From MS & A Possible Solution From
        MajorGeeks.com Forum Blog RE: ChkDsk File 9 Errors:


        http://support.microsoft.com/kb/327009

        Chkdsk Utility Finds Incorrect Security IDs After You Restore or Copy a Lot of Data

        SYMPTOMS:

        After you restore or copy a lot of data and the NTFS file system security information
        that is associated with that data, Chkdsk.exe may report errors on the partition. This
        problem may occur even if you restore or copy the data to a partition that you know
        to be error-free.

        Chkdsk may report errors that are similar to these:

        CHKDSK is verifying security descriptors (stage 3 of 3)...
        Repairing the security file record segment.
        Deleting an index entry with Id 8447 from index $SII of file 9.
        Deleting an index entry with Id 31126 from index $SII of file 9.
        Deleting an index entry with Id 50636 from index $SII of file 9.
        Deleting an index entry with Id 31126 from index $SDH of file 9.
        Deleting an index entry with Id 50636 from index $SDH of file 9.
        Deleting an index entry with Id 8447 from index $SDH of file 9.
        Replacing invalid security id with default security id for file 1461234.
        Security descriptor verification completed.
        Windows found problems with the file system.


        Note that the number of reported errors and the security IDs may vary. The index
        entry IDs and the file numbers may also vary.

        If you then run the chkdsk /f command on the partition and you perform an audit of the
        applied permissions, some files and folders may have lost user-defined permissions.
        These permissions may have been replaced by default permissions that give access
        only to Local System and Administrators.

        This problem may occur no matter which program you use to restore or copy the data.
        The problem has been reported after restoring data (with its security information) by
        using the Ntbackup.exe tool, and after copying data (with its security information) by
        using Xcopy.exe with the /o and /x switches.




        CAUSE:

        The design of the NTFS file system requires that security descriptors be written in
        blocks, and that at least 20 bytes be left free at the end of each security descriptor
        block. This leaves space for a security descriptor header. However, in some cases,
        a miscalculation by the NTFS code might cause security descriptors to be written
        near the end of a block so that less than 20 bytes free space is left.

        Chkdsk.exe then removes these security descriptors and replaces them with default
        security descriptors to make sure that a minimum of 20 bytes of free space remains
        at the end of the block. This causes a loss of user-defined security for some files and
        folders.



        -----------------------------------------------



        SOLUTION:

        http://forums.majorgeeks.com/showthread.php?t=178462


        Re: "file 9" problem (ChkDsk kills winXP, secedit.sdb corrupt)

        ---------------------------------------------

        For the benefit of anyone who may come across this thread while trying to solve a similar problem, here's my solution:

        [0. Use ERUNT (freeware) to backup the registry, and/or Acronis True Image if you have it before letting ChkDsk run. Also, I always disable my antivirus, firewall and all non-essential start-up programs before repairs.]

        1. Let ChkDsk /f run during boot-up even though it deletes files or modifies their attributes. Apparently using ChkDsk /r is even better because it can repair access free setup files for further repairs, but it's only available from the Recovery Console i.e. from the WinXP setup CD, unless previously installed.

        2. ChkDsk may run for hours, and the percentage progress figures may appear frozen, but just give it time. The first time this happened I thought it had frozen, turned the computer off, and subsequently couldn't boot to Windows anymore. If you cannot boot to Windows, then you have to use ERUNT from Recovery Console or Bart's PE type boot disk, or some other restoration utility, but assuming you can still get to Windows, or the command prompt at least, then you can probably fix the ChkDsk damage.

        3. If you cannot move folders, the taskbar has disappeared, nothing works, etc. after ChkDsk has finished, then try changing the security settings for C. Microsoft provides this command prompt command to give everyone access:


        Quote:
        cacls c:\ /g everyone:F /c /t

        link: http://support.microsoft.com/kb/311724

        It takes a while to run too. However, modified 'Properties -> Security -> Advanced' options for C: to (a) take ownership of all files and folders (for Admins), (b) remove restrictions, and (c) grant Full Control to Admins, Creator Owner, and System, and Read access to Users... There's various boxes you have to check/uncheck and tabs to go through to get it all to work, plus you have to disable 'Simple Folder Sharing' before you can even access the Security tab, and again then it takes a long time for the computer to modifying those attributes for each folder and file.

        Also, I had to do equivalent of the above process for all the registry keys (take ownership and reset permissions) - I used Registry Workshop to do it. And sometimes reboots were needed before the changes took effect.

        That's it for the ChkDsk.

        Next I had the secedit.sdb problem, which may or may not have been independent of the ChkDsk problem. In any case, I still got the secedit error message at Control Panel -> Adminstrative Tools -> Local Security Policy -> ...

        That problem was solved by (a) copying the esentutl.exe file from my Windows setup CD on the C: drive, and (b) subsequently running the following command prompt command:


        Quote:
        esentutl /p %windir%\security\database\secedit.sdb

        You may need to use /g or /r or something instead of the /p option, but /p (repair) worked for me. I also used /d later to defrag it. One of the links a_cup posted has the details.

        That took care of secedit, but my $UsnJrnl file was still all over the place (1.5GB or something), very fragmented, and inaccessible to DiskKeeper and JKdefrag - I solved that by deleting it using another utility available on the Windows setup CD; fsutil.exe. The command for running that was:


        Quote:
        fsutil usn deletejournal /D c:

        The details are at my previous link. My understanding is that Windows will reinitialize the file once a program requests it. You may also be able to repair it, but I opted for the deletion since the file had grown and mutated into a monster.

        For future purposes, I changed NtfsMftZoneReservation value to 3 in the registry; HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Filesystem. Default is 1 (smallest) and 4 is the max. I'm hoping that will reserve more space for my system files making it easier to defrag them and keep them healthy.

        Next... Well, almost everything is running smoothly now. I switched back Simple File Sharing, Firewall and Anti-Virus are back on. However, I still cannot run Piriform's Defraggler except in Safe Mode (other defraggers I've tried work fine), and I had to re-install the Recovery Console from Safe Mode. It may have something to do with HP's iastor/iaahci drivers (3rd party SATA drivers); they are always complicating things. I may ask about that in another thread, but for now I'm done dealing with computer problems...

        -----------------------------------------------
        michaelleo@...