Mark Minasi's Windows Networking Tech Page
Issue #107 May 2013

Document copyright 2013 Mark Minasi; please see below for info on subscribing, unsubscribing or copying portions of this text.

What's Inside

  • News
    • Learn with My Seminars, Audio Recordings and More!
  • Tech Section
    • Understanding CHKDSK's "No Server for Five Hours! " Automatic Startups
  • Conferences
  • To Subscribe, Unsubscribe, Read Old Newsletters or Change Your Email Address

News

Hi all —

As you may have heard, one of the quiet joys of Server 2012 (and, I guess, Windows 8) is that CHKDSK has been "defanged."  Ever rebooted a server and started doing something else as you wait for the various BIOSes to initialize?  All goes well until you notice out of the corner of your eye that the screen's a sort of a  pale gray that doesn't look familiar, until it hits you:  I'm seeing the "press Escape or CHKDSK will run for five hours on the server" message!  You bolt from your chair, leap across the room as if in slow motion involuntarily saying, "nooooooo..." and if you're lucky, you hit ESC in time.  But if not... well, that's what this newsletter and the next are about.  But first, a word from our sponsor...

Understanding CHKDSK's "No Server for Five Hours! " Automatic Startups

So what does kick off those nerve-wracking, unwanted pre-boot CHKDSK runs and what can you do about them?  Here's what's going on.

Whenever a Windows application tells Windows to read or write a file, Windows tracks the progress of that file I/O.  If there's a problem -- maybe the read or write required a few retries -- then Windows tries to fix the problem on the fly, a process that Microsoft calls "healing."  That's definitely a useful feature of Windows, and it's been around in its basic form since Windows 2000, improving a bit with every version of Windows.

Disturbing Dismounts

Some fixes, however, can't happen without doing something fairly drastic called "dismounting" the entire volume, which is essentially the moral equivalent of pulling a USB stick out of your computer.  In the same way that you can't change a tire on a car while it's driving down the road, you usually can't dismount a volume when applications have files open on that volume without incurring unpredictable side-effects.  For example, I use VMWare Workstation quite a bit and store my virtual machines on drive E:.  If I were to momentarily dismount the E: drive, then those VMs would fail -- imagine pulling the C: drive out of a running computer -- but Workstation pops up a retry/cancel-style dialog box and I can usually just tell it to retry and all's well, no harm done.  With PowerPoint, in contrast, I've seen some very serious data loss from open files on a dismounted drive, like loss of all images in the PowerPoint.  (Basically PowerPoint stores all of the images and clip art in a presentation in a folder named "Media," stored inside a PPTX file.  Dismounting an open PPTX file can somehow damage the folder, and in a trice you've lost all of your images.)

In any case, the result is the same:  dismounting volumes that happen to contain open files is a bad idea, so Windows doesn't try to do it while doing its everyday "healing" of drive areas.  Instead, Windows says to itself, "I'll remember that this drive has a problem of some kind, and I'll give it a more serious scan the next time we reboot."  The idea is that Windows has a little window between "not running" and "running" wherein it's possible for CHKDSK to dismount and examine whichever volume it wants to examine -- even C:.

Let CHKDSK Run, or Not?

That all sounds great, except for the reality that when CHKDSK does run, it usually takes forever, and users can get pretty cranky when you tell them that, um, the Exchange server had this little drive  problem and it'll probably only be four hours before email's back.  Why does CHKDSK take so long?  Simple:  when run in this pre-boot state, all CHKDSK knows is that for some reason it's been asked to fix drive F:, C: or whatever, without any context.  Knowing nothing about the drive in question, CHKDSK has no real alternative but to do an extensive time-consuming top-to-bottom scan of that drive.  If only CHKDSK had left itself a note saying, "when we next reboot, check clusters 10,021 through 10,100 -- there's something not quite right there."  The pre-boot CHKDSK run, then, would only take a few minutes rather than a few hours.  (Great idea, eh?  That's an example of what we writer types call "foreshadowing."  More on that in Part Two in the next issue.) 

Thus, Windows from XP through Server 2008 R2 can sometimes force you to have to make a terrible choice between "maybe I need to let CHKDSK do that fix so I don't lose important data" versus "I might get my butt fired for letting a server go offline for a few hours in the middle of the day."  Here's a bit more detail on what controls that CHKDSK-before-boot process.

Autochk and the Dirty Bit

The main key is a program named autochk.exe.  It can't run in a normal Windows session, but it can run during that pre-boot time.  It's started by the Session Manager, which executes a command sequence stored in a Registry entry named BootExecute in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager.  You can see that entry using either Regedit or this command, which you can run from a command prompt:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" /v bootexecute

In its simplest, default form, BootExecute's contents look like

autocheck autochk *

That tells autochk to go check all volumes to see if any of them have something called their "dirty bit" set.  The dirty bit really is a bit somewhere on the volume, and it gets set from zero to one if the operating system detects a this-needs-a-dismount-and-CHKDSK level of problem.  You can check any volume to see if it's got its dirty bit set with fsutil, as in

fsutil dirty query E:

You can also set  the dirty bit, if you like, by replacing "query" with "set," as in

fsutil dirty set E:

Be aware, however, that there's no "fsutil dirty reset E:" command, and the only way to clear a dirty bit is to run a full chkdsk /f on the volume in question, which again may require a reboot,which would kick off autochk which in turn would run that chkdsk /f.  (I should mention that someone has posted instructions on the Web on how to manually clear a dirty bit but I've not tried it, so I can't comment on whether it's a good idea or not.)

Wondering if you've ever seen a volume with a dirty bit?  Well, have you ever plugged a USB stick into your Windows system and gotten a pop-up message suggesting that something's wrong with the drive, and can Windows scan the USB stick?  If so, you've seen a volume with a dirty bit -- that triggers that message.  On Windows 8, you see the following "toast" (it pops up, get it?) message about a USB stick with a dirty bit:

Example message advising that a removeable volume has a dirty bit set

It's easy to get a "dirty USB stick" by pulling it of its socket when Windows didn't expect it.  If I were to run chkdsk g: /f then when CHKDSK was finished, a fsutil dirty query g: would show that G: did not have its dirty bit set.

Beyond the Dirty Bit:  CHKNTFS

So far, we've seen only that the presence of a dirty bit will cause pre-boot CHKDSK to run on a drive, but since Windows 2000, we can trigger a pre-boot CHKDSK on any drive.  It's done by adding some syntax to the BootExecute Registry entry with a command-line tool "CHKNTFS."  With CHKNTFS, you can reset BootExecute back to its default values ( /D), add an option to force running CHKDSK on one or more drives ( /C ), or add an option to force autochk to not run CHKDSK on one or more drives ( /X ).  Just a few examples will suffice to explain chkntfs:

  • To tell Windows to run CHKDSK /F on drive G: upon next boot, you'd type chkntfs /C G:, which would change BootExecute to contain autocheck autochk /m \??\G:\0autocheck autochk *
  • To tell Windows to return BootExecute to its default setting (which is, you may recall, autocheck autochk *), you'd type chkntfs /D without a drive letter.
  • To tell Windows specifically not to run CHKDSK on drive G:, even if it's got a dirty bit, you'd type chkntfs /X G:, which would set BootExecute to autocheck autochk /k:G *.

Oh, and you may find one more CHKNTFS command useful -- /T.  Invoke CHKNTFS with /T:nn, where "nn" is a number to control the number of seconds that Windows waits before running CHKDSK /F on some drive, like chkntfs /t:15, which would set the wait time to 15 seconds.  The default on Server 2008R2 and earlier is 30 seconds, but they dropped that value in Windows 8 and Server 2012 to just one second.  But, then, that all makes sense, if you understand how autochk and CHKDSK change in Win 8 and Server 2012... which is the topic of the next newsletter.   See you in a couple weeks!

To Subscribe, Read Old Newsletters, Send Me a Comment or Change Your Email Address

To subscribe: (which just means I'll send you about a three-tweet-sized message in plain text via email including a link to my latest newsletter), please visit http://www.minasi.com/nwsreg.htm.

To change e-mail or other info, drop me a line (haven't figured out a secure method yet).

To read old newsletters: visit http://www.minasi.com/nwstoc.htm and, if you like 'em, please consider subscribing.

To send me a comment:  I'm at help@minasi.com.

All contents copyright 2013 Mark Minasi.  I encourage you to quote this material, so long as you include this entire document. Thanks very much for reading, and see you next time.