Holy cow, I wrote a book!
A customer reported an issue with the title
"The notification balloon for Low Disk Space does not appear
even if the free disk is very low."
They provided the following steps:
You read through the steps nodding,
"uh huh, uh huh", and then you get to the last step and you say,
"Wait a second, the subject of your report was that the balloon
doesn't appear at all, and now you're saying that it appears
after ten minutes.
So it does appear after all.
What is the problem?"
The customer explained that on earlier versions of Windows,
the Low Disk Space warning balloon appeared within one minute,
whereas in Windows 7 it can take up to ten minutes for the
balloon to appear.
Yup, that's right.
In previous versions of Windows, Explorer checked for low disk space
once a minute.
The Windows performance folks requested that the shell reduce the
frequency of checks to improve overall system performance,
and the shell team agreed to reduce the frequency to once every
(The performance team made other suggestions to reduce the impact of
that code that runs every ten minutes.)
So yes, in Windows 7, it may take up to ten minutes for
Explorer to report that you are low on disk space.
But Explorer never promised that those reports would be timely.
Or that they would even appear in the first place.
The behavior is not contractual;
it's just a courtesy notification.
How full does a hard drive have to get
before Explorer will start getting concerned?
How do I disable the low disk space notifications?
Some time back, I provided
regarding what types of files go into which folders.
Here are the official guidelines [pdf],
for those looking for something with more authority than just me
Ian Boyd wants to know
why the specific value of 500ms was chosen as the edit delay
in Windows Explorer.
Because it's your double-click time.
Since the double-click action (execute)
is not an extension of the single-click action (edit),
Explorer (and more generally, list view)
waits for the double-click timeout before entering edit mode
so it can tell whether that first click was really a single-click on its own
or a single-click on the way to a double-click.
If the timeout were shorter than the double-click time, then
double-clicking an item would end up having the first click trigger
edit mode and the second click selecting text inside the editor.
(If the timeout were longer, then everything would still work,
but you would just have to wait longer.)
"Through my testing it does not appear linked to configurable
My guess is that Ian changed the double-click timeout not by
but by whacking a registry value directly.
The values in the registry are loaded and cached at logon;
you can update them all you want at runtime, nobody will care.
A customer reported some inconsistency in how folder customizations
are handled by roaming profiles.
Why doesn't the C:\Temp customization roam?
Well, if you think about it, it makes sense that the
setting for C:\Temp doesn't roam
because C:\Temp doesn't roam either!
The C:\Temp on Server1 is not the same directory
the C:\Temp on Server2.
Let's change Step 2 slightly:
I think nobody would be surprised at the results of this second
The changes to Library\Documents are there because that folder
is part of your roaming profile.
The changes to \\server\share are there because
it is a global resource.
And the changes to C:\Temp are not there because
the first one is "C:\Temp on Server1" and the second is
"C:\Temp on Server2".
The shell saves icon size customizations in folders differently
based on whether it is a global resource (like a network share)
or a local resource (available only on the local machine).
Settings for local resources do not roam because, well, they're local
and have no meaning when roamed to another computer.
The Documents case manages to get the desired effect, but by different
Settings for libraries are based on how you customized the view
via things like the "Arrange by" menu.
Those customizations are saved in your roaming profile,
and they therefore roam with you.
reported a problem that occurred only when they
installed a particular application.
If they uninstalled it, then the problem went away.
After installing the application, the "Run As" context menu
option stopped working.
The customer didn't provide any other details,
but we were able to make an educated guess as to what was going on.
A common programming error in context menu extensions occurs in
extensions which add only one menu item.
These extensions ignore the parameters to the
IContextMenu::InvokeCommand and simply assume that
the only reason the method can be called is if the user selected
their menu item.
After all, if you have only one invokable item, there's no need
to figure out which one the user selected, because you have only
one to begin with!
The problem is that a context menu extension can be invoked
not because the user selected an item under its control
but because a verb is
being invoked programmatically,
and each handler is being asked,
"Do you know how to do this?"
The result is that the context menu host calls the extension to say,
"If you know how to do runas, then please do so,"
and the the extension says
"Sure, we do that" and starts doing its thing.
If you are unlucky and the grabby extension is asked the question
before the actual runas extension,
the runas command winds up being hijacked by the grabby
(This is the same mistake that causes
the Copy To and Move To commands to behave strangely if you add
them to the context menu:
They assume that the only reason they are invoked is that the user
invoked their command, because they weren't designed to be hosted
by context menus to begin with!
They were designed to go into the toolbar, and the toolbar hosting
code never invoked commands by name.
It's like taking a ladder and using it as a bridge between two tall
Sure, you can now cross from one building to another,
but you also run a serious risk of falling to your death.)
A variation on the initial problem is
"I found that after installing a particular program, I can't
run anything from the Start menu."
I know of at least two programs which install
context menu extensions which steal the "open" command
This problem is sufficiently prevalent that there is a
special compatibility flag that can be set on a shell extension
"This is a grabby shell extension that steals commands.
Never ask it if it supports anything, because it will
always say yes!"
Notice that the "MoveTo CopyTo Context Menu" is on the list,
which I find interesting because MoveTo/CopyTo was never meant
to go on the context menu in the first place.
Going back to our analogy, it'd be as if the ladder company
issued a safety bulletin to warn people of problems
that can occur if you use it as a bridge between two tall buildings!
In Windows Vista and Windows Server 2008,
if you go to a the advanced security settings for a directory
and uncheck "include inheritable permissions from this
then go back to the Sharing tab,
you'll find that the "Share" button is disabled.
Why is this?
We don't see this behavior on Windows 7 or
Windows Server 2008 R2.
(Yes, a customer actually noticed and asked the question.)
The sharing wizard in
Windows Vista and Windows Server 2008 does not support
folders with the SE_DACL_PROTECTED
security descriptor control bit
because it isn't sure that it can restore the ACL afterward.
And as the customer noted, this restriction was lifted in
Windows 7 and Windows Server 2008 R2.
This information is accurate as of Windows 7;
the algorithm may change for future versions of Windows.
The information is being provided for the edification of computer
network administrators, who are curious about random stuff like this
since it can affect their network load.
When you hover over a folder, Explorer shows an infotip (a special
type of tooltip) which contains information about the directory,
and the information that concerns network administrators is the
How does Explorer calculate the size?
Explorer calculates the size by performing a naïve recursive listing
of the directory and adding up the sizes of all the files it finds.
If the enumeration takes longer than three seconds, then Explorer
gives up after three seconds and reports the size as "larger than X"
where X was the size it managed to calculate so far.
If you don't want Explorer to do this calculation, you can disable
it from the Folder Options control panel
by unchecking the box labeled
Display file size information in folder tips.
In Windows 2000 and Windows XP,
you could add Summary information on the
Details property page to files of all types.
Text files, image files, some crazy file your grandmother sent you
in a file format you don't know how to open.
If Windows supports storing the Summary information in the file itself
(for example, in EXIF tags or in
Structure Storage properties),
then the information gets stored there.
Otherwise, Windows stashes the information in an alternate data stream.
Windows Vista dropped support for storing Summary information in
alternate data streams.
Support for storing Summary information in an alternate data stream
was dropped in Windows Vista
because alternate data streams were found to be too fragile.
If you back up the file to a CD-ROM or email it to a friend
or copy it to a thumb drive or upload it to a Web site
or store it in a ZIP file,
the alternate data stream ends up lost.
It was determined that it was better simple not to allow users
to create data that was so easy to destroy accidentally.
A customer had a question about their Windows XP installations.
(This question was from several years ago, so the fine details
aren't really relevant any more, but I'm actually telling this
story for a commentary opportunity.)
The customer wanted to disable all file associations for TIFF files.
Their first attempt was by deleting HKEY_CLASSES_ROOT\.tif
This successfully renders TIFF files with a generic document icon,
but when the user double-clicks the file, the registration is
re-established and Windows Picture and
Fax Viewer opens the file.
The company had some
strange company security policy that says that TIFF files
should not have any file association. I don't know the rationale
behind it, but they did say that they only needed to block
the default file association.
If the user explicitly creates a new association via the Open With
dialog, then that is not covered by the policy.
Deleting the registrations doesn't work because Windows XP
has an autorepair feature for certain commonly-corrupted file
and TIFF is one of them.
If the TIFF registration is corrupted and the user is a member
of the Administrators group, then Windows XP will restore
the default association.
(If the user is not a member of the Administrators group,
then the usual "Windows cannot open this file" dialog box appears.)
Therefore, the solution to the customer's odd problem is not to
delete the TIFF registrations (which causes them to be
detected as corrupted)
but rather to simply set a new default handler for TIFF files
that merely displays a message to the user.
If you're willing to use the Windows Script Host,
then it's a one-line program:
WScript.Echo("TIFF file associations are disabled.")
If you have been reading carefully,
you have already noticed a serious problem with the customer's
The fact that they are seeing the TIFF autorepair code kicking in
means that they are letting their employees run with Administrator
which means that their so-called "security requirement" is like
worrying about employees being able to sneak into the building
through a ventilation grating,
when you give everybody a key to the front door.
If you have a really large file and try to view its properties
in Explorer, you may find that the Version tab doesn't appear.
What's going on?
The Version tab uses the GetFileVersionInfo
family of functions
to obtain version information from files.
It so happens that the GetFileVersionInfo function
works by calling
and then using functions like
FindResource to locate the version resource
so it can
allocate a buffer to hold the version resource plus additional data
to assist in character set translation.
If the file is larger than the available address space in the Explorer
process, then the call to
LoadLibraryEx will fail due to lack of address space
into which to map the image.
Library not loaded means no version resource to show you.
When we explained this behavior to a customer, the customer wanted
to know the exact file size at which the problem occurs.
There is no single exact file size at which the problem occurs
because the amount of available address space is determined by
large numbers of factors which cannot be boiled down to a simple
It depends on the pattern of memory allocation that took place
which shell extensions and
DLLs got loaded at what point in time, where they got relocated to,
which ones got unloaded relative to others loading,
how much memory they allocated and where those allocations ended up.
It's like asking the airline,
"I know that the later I make my reservation, the less likely I'm
going to get the exact seat I want.
What is the cutover point before which I will get a window seat
and after which I won't?"
There is no specific point in time where "all reservations before
this point will definitely get a window seat,
and all reservations after this point will definitely not
It all depends on the pattern of requests before you make
Indeed, it's even possible that if you had made your reservation
later, you would have gotten that window seat, because somebody
who had a window seat called in a cancellation.
One customer apparently didn't understand the unpredictability
of the cutover point and asked,
"Is there a way to change this limit?"