Holy cow, I wrote a book!
If you search MSDN for CtlPanelClass,
you'll find a few really old Knowledge Base articles
that include it in a list of "class names of common
I'm not sure why the Knowledge Base articles bothered to list those
there is no technical reason for applications to need to know this,
and including the information merely encourages programmers to
rely on the window class name in strange undocumented ways.
(This is another one of those cases where
a Knowledge Base article written to assist in troubleshooting
becomes interpreted as formal documentation.)
Windows Vista finally got rid of that window class.
It took only ten years.
The window class was used by the old Windows 3.1 Control Panel
Back in Windows 3.1, the Control Panel was a standalone
application and was not integrated into the shell namespace
(in large part
because there was no such thing as a shell namespace back then
for it to be a part of).
There was one program which not only searched for a window of that
specific class name,
but it also sent the window WM_COMMAND messages,
since of course it knew what the menu IDs were for the Control Panel
and it knew that the Windows developers would never change the IDs
or replace the standalone Control Panel application with anything else.
When the standalone Control Panel application was converted to
a virtual folder,
it also came with
in order to maintain compatibility with older programs that
relied on the old behavior in strange undocumented ways.
One of those decoys, the CtlPanelClass
was removed for Windows Vista.
A crash was traced back to a bug in the decoy window
which manifested itself if
a control panel took more than ten seconds to launch itself.
To fix the bug, we just removed the decoy window,
but we were prepared to write a compatibility shim in case
there were people still running that ancient application
We didn't actually turn the compatibility shim on,
but we were ready just in case.
We removed the decoy and crossed our fingers.
We got lucky.
Today is Election Day in the United States.
Some years ago, seventh grade students (age 12)
were asked to imagine they had just been elected president
and to give an address to the nation on one thing they would change.
Remember, these are only the most entertaining ideas.
Do not assume all student ideas are like these.
And this sentence came from a student destined for greatness as
"Something must be done, and I will make it happen."
A customer wanted to do one of those user-hostile things that
Windows doesn't make easy to do (the sort of thing I tend to call out
on this Web site).
After receiving an explanation that Windows doesn't provide a way
of doing what they want because it abuses the component in question
and goes against user expectations, the customer countered,
"Yes, we understand that, but our case is different."
The customer then proceeded to explain how they intended to use
this newfound power (if only they could figure out how to do it)
and under what circumstances they intend to invoke it.
Their explanation was interesting in that the description
could be applied to
any other program on the planet.
Yes, we understand that, but our case is different.
We would do this only after the user installs the program
or reconfigures it from the Add or Remove Programs control panel.
After a few days, we would stop doing it, unless triggered by
a reinstall or a reconfiguration.
So far, there's nothing here that explains why your program should be
able to do this, but not, say, Photoshop.
There is no evidence that
this program is any different from the tens of thousands of other programs
out there, many of which probably want to do that very same thing this program
wants to do.
Just because you say that your case is different doesn't make it so.
Commenter littleguru asks,
"Why does the End Now button not kill the process immediately?"
When you click the End Now button,
the process really does end now,
but not before a brief message from our sponsor.
When you kill a hung application,
Windows Error Reporting steps in to record the state of the
hung application so it can be submitted to the mother ship
(with your permission).
If you are running Windows XP or Windows Vista,
you can briefly see a process called dumprep.exe
or WerFault.exe; these are the guys who are doing
the data collection.
After being uploaded to Microsoft,
these failure reports are studied
to determine why the application stopped responding and what
could be done to fix it.
I've been asked to do quite a few of these analyses myself,
and sometimes it's something pretty mundane
(an application sends a cross-thread message while holding a
critical section, and the thread can't receive the message
because it's stuck waiting for the critical section that the
sender is holding—classic deadlock),
and sometimes it's something pretty weird
(application has a bug if
the number of sound output devices is not equal to one).
Whatever the reason, I write up my analysis,
and the people who are in charge of such things make arrangements
for the information to be sent back
to the vendors who wrote the application
(assuming the vendors are
registered with Winqual).
If you don't want Windows Error Reporting to collect application
crash and hang reports,
you can disable it from the Group Policy Editor under
Windows Error Reporting.
Of course, if you do this, then
you don't get to vote on which
program crashes and failures Microsoft should work on fixing.
This entry is an experiment:
I mentioned Windows Error Reporting and WHQL.
If people complain about digital certificate authorities,
that'll just confirm my bias against returning to those old
Experimental results obtained.
No more stories involving Windows Error Reporting and WHQL.