Holy cow, I wrote a book!
Literary detective Paul Collins
stumbled upon a precursor to today's Mad Libs
Revelations of My Friends.
Listen to the NPR story to hear Scott Simon play,
and go to Paul Collins' web site to see some of the drawing that Scott
Sometimes I see people ask a question and get an answer,
but the answer doesn't quite work.
But instead of trying to understand the answer in order to see why
it doesn't work and develop a better solution, they just play stupid.
Here's an example.
The names have been changed but the story's the same.
How do I get a handle to a bright pink elephant?
We have a dialog box that talks about elephants, and we'd like to
put some information about the bright pink ones on it.
An answer came back rather quickly.
Some time later, the customer came back with a follow-up question.
I can't get it to work.
I get a compiler error:
error C2065: 'EPHNT_BRIGHTPINK' : undeclared identifier
Am I missing a header file?
error C2065: 'EPHNT_BRIGHTPINK' : undeclared identifier
Am I missing a header file?
(So much for
people knowing what to do when they get this error message.)
Don't be helpless.
Your head isn't just for looks.
At least pretend to try to understand what you're doing.
In this case, the function is GetElephantHandle,
and you're having trouble because the EPHNT_BRIGHTPINK
value we want isn't defined.
Why not check out the values that are defined?
#define EPHNT_DUMBO 0
#define EPHNT_BABAR 1
#define EPHNT_WHITE 2
#define EPHNT_BRIGHT_PINK 3
Wow, I bet the person who wrote EPHNT_BRIGHTPINK really meant
Armed with this new skill, perhaps you can solve this person's problem:
Somebody recommended that I add the DS_SHELLEXT style
to my property sheet dialog template to fix a sizing problem,
but when I try that, I get an error that tells
me that DS_SHELLEXT is not defined.
Is there a file I have to include?
One of the major changes to services in Windows Vista
session 0 isolation.
After reading the summary, you can follow that first supplementary link,
Impact of Session 0 Isolation on Services and Drivers
in Windows Vista,
to dig deeper and receive guidance on how you need to modify your
Then again, some of the questions I see regarding session 0
reveal that they were relying on behavior that wasn't true even
in Windows XP.
Many people† assume that session 0 is the one connected to the
but there is no such guarantee.
If you turn on Fast User Switching and have multiple users logged on,
the second and subsequent users will be on sessions other than
session 0, even though they are at the physical keyboard
when they log in.
if you use Remote Desktop Connection to connect to a Windows XP
machine, you can connect to session 0 remotely.
So whatever they were doing, it was already broken.
†The phrase "many people" means "many people".
Microsoft employees fall under the category of people.
(I can't believe people are
nitpicking the nitpicker's corner.)
Nearly all computer administrators are idiots.
That's not because the personnel department is incompetent
or because it's impossible to train competent administrators.
It's because, for a consumer operating system,
the computer administrator didn't ask to be one.
In nearly all cases,
the computer administrator is dad or grandma.†
They didn't ask to be to be the computer administrator.
They just want to surf the web and read email from Jimmy.‡
All this means is that you can't say,
"Well, if the user is an administrator, as opposed to a normal user,
then it's okay to show them all these dangerous things (such as
critical operating system files) because they
know what they're doing."
Grandma doesn't know what she's doing.
For a consumer operating system, a friendly user interface means
protecting the administrators from themselves.
One article without a nitpicker's corner and look what happens.
†The words "dad" and "grandma" refer to archetypes for
non-technical home users and are not
intended to be interpreted as literally dad and grandma.
‡Not all grandchildren are named Jimmy.
Some friends gave me a bottle of spearmint
as a gift.
And as it turns out, it was a mean-spirited gift.
Let's look at that bottle.
It calls itself "pure, simple mintwater®".
What the heck is pure mintwater?
Do you go to the local mintwater stream and collect it?
Oh, wait, sorry.
That should be
With some trepidation, I took a sip.
It's like drinking chewing gum.
Why would anybody want this?
But wait, there's more.
On the side of the bottle,
there's a picture of a thermometer, and the mercury reads −6°,
or "extra cool."
Whatever that means.
The bottle never explains.
page, if you click through to "rehydrate",
it says that "the good stuff in Metromint gets where
it's going quicker, and goes to work faster."
What's the scientific basis for this claim?
Quicker than what?
And the biggest mystery of them all:
What part of Metromint is the "good stuff"?
I haven't found it yet.
My point is that this stuff is awful.
I'm not the only person who thinks so.
If you've designed your program so that it assumes that the the only
thing a user can use drag/drop for is dropping your object into a file
system directory, then you've already lost.
piers wants to be able to determine the destination of a drag/drop
From the description, it appears that what piers really wants is the
destination path, but who says that the drop destination
is a directory?
The user might have dropped the item into an email message,
onto an FTP site, onto a Web site (via Web Folders),
or even a directory on an operating system
running inside a virtual machine!
The follow-up question makes things even more confusing.
If the user drops the files into an FTP site or some other virtual
folder, how is your program supposed to be able to restart the transfer?
You don't know the user's password on that FTP site.
You don't know how to restart that virtual machine and log the user on.
And even if you did, you don't know how to write to a directory on a
virtual machine; only the virtual machine manager knows how to do that.
There are an infinite variety of potential virtual folders out there;
I doubt you know how to (or even have the ability to)
push your data into each one.
Once the user drops the data object, the remainder of the
transfer is a private matter between the data source and the drop
It's not like a data source can tell all drop targets,
"I want to take over the transfer,"
because even if the drop target agreed to it,
that still leaves the data source the problem of
figuring out how to carry out that take-over.
What is my recommendation?‡
The data object in the drag/drop loop should follow the standard
shell data object transfer protocol
so that users can drop the object into an email message,
onto an FTP site, etc.°
For the special bonus behavior,
I would create a drag/drop hook.
A user that wants to do a transfer mediated by your program
can use the right mouse button† to drag.
When the drop occurs, a context menu will appear, including
the drag/drop hook you created.
That hook would create a new item called something like
"Copy with CoolProgram".
(Of course, the hook adds this item only if the data object
identifiers itself as coming from CoolProgram.)
If the user selects "Copy with CoolProgram",
then you can do your CoolProgram-mediated copy.
†More properly, the secondary mouse button, since you may have
‡Notice that I do not assert that
all Microsoft products follow my recommendation.
Note also that this is my personal recommendation,
not the official position of Microsoft Corporation.
°And you should already understand the standard shell
data object transfer protocol
before you go off and design a nonstandard one.
I don't even watch
but this sequence of
Endless Caruso One Liners cracks me up.
Wikipedia entry for Horatio Crane
acknowledges the awesome power of the Sunglasses of Justice,
Jim Carrey gets into the act.
Last year, a Windows security update got a lot of flack for causing some machines to hang, and it was my fault. (This makes messing up a demo at the Financial Analysts Meeting look like small potatoes.)
The security fix addressed a category of attacks wherein people could construct shortcut files or other items which specified a CLSID that was never intended to be used as a shell extension. As we saw earlier, lots of people mess up IUnknown::QueryInterface, and if you pass the CLSID of one of these buggy implementations, Explorer would dutifully create it and try to use it, and then bad things would happen. The object might crash or hang or even corrupt memory and keep running (sort of).
To protect against buggy shell extensions, Explorer was modified to use a helper program called verclsid.exe whose job was to be the "guinea pig" and host the shell extension and do some preliminary sniffing around to make sure the shell extension passed some basic functionality tests before letting it run loose in Explorer. That way, if the shell extension went crazy, the victim would be the verclsid.exe process and not the main Explorer process.
The verclsid.exe program created a watchdog thread: If the preliminary sniffing took too long, the watchdog assumed that the shell extension was hung and the watchdog told Explorer, "Don't use this shell extension."
I was one of the people brought in to study this new behavior, poke holes in its design, poke holes in its implementation, review every line of code that changed and make sure that it did exactly what it was supposed to do without introducing any new bugs along the way. We found some issues, testers found some other issues, and all the while, the clock was ticking since this was a security patch and people enjoy mocking Microsoft over how long it takes to put a security patch together.
The patch went out, and reports started coming in that machines were hanging. How could that be? We created a watchdog thread specifically to catch the buggy shell extensions that hung; why isn't the watchdog thread doing its job?
That was a long set-up for today's lesson.
After running its sanity tests, the verclsid.exe program releases the shell extension, un-initializes COM, and then calls ExitProcess with a special exit code that means, "All tests passed." If you read yesterday's installment, you already know where I messed up.
The DLL that implemented the shell extension created a worker thread, so it did an extra LoadLibrary on itself so that it wouldn't get unloaded when COM freed it as part of CoUninitialize tear-down. When the DLL got its DLL_PROCESS_DETACH, it shut down its worker thread by the common technique of setting a "clean up now" event that the worker thread listened for, and then waiting for the worker thread to respond with a "Okay, I'm all done" event.
But recall that the first stage in process exit is the termination of all threads other than the one that called ExitProcess. That means that the DLL's worker thread no longer exists. After setting the event to tell the (nonexistent) thread to clean up, it then waited for the (nonexistent) thread to say that it was done. And since there was nobody around listening for the clean-up event, the "all done" event never got set. The DLL hung in its DLL_PROCESS_DETACH.
Why didn't our watchdog thread save us? Because the watchdog thread got killed too!
Now, the root cause for all this was a buggy shell extension that did bad things in its DLL_PROCESS_DETACH, but blaming the shell extension misses the point. After all, it was the fact that there existed buggy shell extensions that created the need for the verclsid.exe program in the first place.
Welcome Slashdot readers. Since you won't read the existing comments before posting your own, I'll float some of the more significant ones here.
The buggy shell extension was included with a printer driver for a printer that is no longer manufactured. Good luck finding one of those in your test suite.
The security update was recalled and reissued in a single action, which most people would call an update or refresh, but the word recall works better in a title.
I heard an interesting report on
surprises in the self-checkout lane.
Impulse buying is down, and stores have come up with other
ways to entice you into buying something you hadn't planned.
And it turns out that fears from retailers that customers would
cheat at the self-checkout turned out to be misplaced:
The reality of the situation is that most losses or theft
come from the employees themselves.
One of the things that we're realizing is actually that
customers are more honest than the people that are working there.
Exiting is one of the scariest moments in the
lifetime of a process.
(Sort of how landing is one of the scariest moments of air travel.)
Many of the details of how processes exit are left
unspecified in Win32, so different Win32 implementations can
follow different mechanisms.
Win32s, Windows 95, and
Windows NT all shut down processes differently.
(I wouldn't be surprised if Windows CE uses yet another
Therefore, bear in mind that what I write in this mini-series
is implementation detail and can change at any time without warning.
I'm writing about it because these details can highlight
bugs lurking in your code.
In particular, I'm going to discuss the way processes exit
on Windows XP.
I should say up front that I do not agree with many steps in the
way processes exit on Windows XP.
The purpose of this mini-series is not to justify the way processes
exit but merely to fill you in on some of the behind-the-scenes
activities so you are better-armed when you have to investigate into
a mysterious crash or hang during exit.
(Note that I just refer to it as the way processes exit
on Windows XP rather than saying that it is how process
exit is designed.
As one of my colleagues put it,
"Using the word design to describe this is like using
the term swimming pool to refer to a puddle in your garden.")
When your program calls ExitProcess a whole lot of
machinery springs into action.
First, all the threads in the process (except the one calling
are forcibly terminated.
This dates back to the old-fashioned theory on how processes
Under the old-fashioned theory,
when your process decides that it's time to exit,
it should already have cleaned up all its threads.
The termination of threads, therefore, is just a safety
net to catch the stuff you may have missed.
It doesn't even wait two seconds first.
Now, we're not talking happy termination like ExitThread;
that's not possible since the thread could be in the middle of
Injecting a call to ExitThread would result in
DLL_THREAD_DETACH notifications being sent at times
the thread was not prepared for.
Nope, these threads are terminated in the style of
Just yank the rug out from under it.
This is an ex-thread.
Well, that was a pretty drastic move, now, wasn't it.
And all this after the scary warnings in MSDN that
TerminateThread is a bad function that should
Wait, it gets worse.
Some of those threads that got forcibly terminated may have
owned critical sections, mutexes, home-grown synchronization
primitives (such as spin-locks), all those things
that the one remaining thread might need access to during its
Well, mutexes are sort of covered; if you try to enter that
mutex, you'll get the mysterious
WAIT_ABANDONED return code
which tells you that "Uh-oh, things are kind of messed up."
What about critical sections?
There is no "Uh-oh" return value for critical sections;
EnterCriticalSection doesn't have a return value.
Instead, the kernel just says "Open season on critical sections!"
I get the mental image of all the gates in a parking garage just
opening up and letting anybody in and out.
As for the home-grown stuff, well, you're on your own.
This means that if your code happened to have owned a critical section
at the time somebody called ExitProcess,
the data structure the critical section is protecting has a good
chance of being in an inconsistent state.
(Afer all, if it were consistent, you probably would have exited
the critical section!
Well, assuming you entered the critical section because you were
updating the structure as opposed to reading it.)
Your DLL_PROCESS_DETACH code runs,
enters the critical section, and it
succeeds because "all the gates are up".
Now your DLL_PROCESS_DETACH code
starts behaving erratically because the values in that data
structure are inconsistent.
Oh dear, now you have a pretty ugly mess on your hands.
And if your thread was terminated while it owned a spin-lock
or some other home-grown synchronization object,
your DLL_PROCESS_DETACH will most likely simply
hang indefinitely waiting patiently for that terminated thread
to release the spin-lock (which it never will do).
But wait, it gets worse.
That critical section might have been the one that protects
the process heap!
If one of the threads that got terminated happened to be in
the middle of a heap function like HeapAllocate
or LocalFree, then the process heap may very
well be inconsistent.
If your DLL_PROCESS_DETACH tries to allocate or
free memory, it may crash due to a corrupted heap.
Moral of the story:
If you're getting a DLL_PROCESS_DETACH due to
don't try anything clever.
Just return without doing anything
and let the normal process clean-up happen.
The kernel will close all your open handles to kernel objects.
Any memory you allocated will be freed automatically when
the process's address space is torn down.
Just let the process die a quiet death.
Note that if you were a good boy and cleaned up all the
threads in the process
before calling ExitThread,
then you've escaped all this craziness, since
there is nothing to clean up.
Note also that if you're getting a DLL_PROCESS_DETACH
due to dynamic unloading, then you do need to clean up
your kernel objects and allocated memory
because the process is going to continue running.
But on the other hand,
in the case of dynamic unloading, no other threads should be
executing code in your DLL anyway (since you're about to be unloaded),
so—assuming you coded up your DLL correctly—none of your
critical sections should be held and
your data structures should be consistent.
Hang on, this disaster isn't over yet.
Even though the kernel went around terminating all
but one thread in the process,
that doesn't mean that the creation of new threads is blocked.
If somebody calls CreateThread in their
DLL_PROCESS_DETACH (as crazy as it sounds),
the thread will indeed be created and start running!
But remember, "all the gates are up", so your critical sections
are just window dressing to make you feel good.
(The ability to create threads after process termination has begun
is not a mistake; it's intentional and necessary.
Thread injection is how the debugger breaks into a process.
If thread injection were not permitted, you wouldn't be able
to debug process termination!)
Next time, we'll see how the
way process termination takes place on Windows XP
caused not one but two problems.
†Everybody reading this article
should already know how to determine whether
this is the case.
I'm assuming you're smart.
Don't disappoint me.