Windows Confidential: The mystery key
Some settings are never meant to be changed or manipulated. When you find one of those, just leave it alone.
Raymond Chen
“Why does the system act funny when I modify this undocumented registry key?” That’s never the sort of question you want to hear.
A customer once observed that a particular checkbox seemed to be associated with a particular undocumented registry key. Because the customer wanted to control that checkbox programmatically, he wrote a script to manipulate that key, but then the system started to act strangely. Imagine that.
“If I start with the key set to 0 and manually set it to 1, when I go to the control panel, it shows the checkbox checked but the system behaves as if the checkbox is still unchecked. Even stranger; if I try to toggle the checkbox from the control panel, it doesn’t toggle. It just stays checked. I would appreciate your input.”
Sometimes people get so caught up in describing their problem that they forget to ask a question. In this case, the customer described all the things they did and what they observed. However, he didn’t actually state what sort of help he needed. A developer reading this might say, “That makes sense,” or possibly, “My, what an interesting story.”
Let’s assume the question is: “Can you help me develop a way to control the checkbox programmatically? Editing the registry doesn’t appear to be working.”
Do not modify
Well, the registry key in question is undocumented for a reason: Direct modification isn’t supported. Direct modification causes internal states to get out of sync. Then you get weird behavior such as the one described by the customer.
Consider you’re in a fancy restaurant. This fancy restaurant keeps a master copy of the daily menu in the kitchen. At the beginning of the day, every waiter and cook looks at the menu and commits it to memory. Sometimes, the executive chef will make a change to the menu in the middle of the day. When she does, she tells the staff about it so everyone knows and stays in agreement. “We ran out of halibut, so scratch the halibut for the rest of the evening.” That way, the waiters won’t offer guests dishes that don’t exist.
That menu is like the registry. Suppose a customer sneaks into the kitchen, takes out a pen, crosses out filet mignon and writes New York steak, then goes back into the dining room and tries to order the New York steak. (Maybe the customer also changes the price from $45 to $35 for good measure.)
The waiter will say, “I’m sorry, sir, but we don’t have New York steak today. Can I suggest the filet mignon?”
Then the customer says, “You’re wrong. You have New York steak today. Go back into the kitchen and look at the master menu. You’ll see that it’s there. This restaurant’s wait staff procedures are clearly flawed.”
The master menu in the kitchen is undocumented. How does the customer know about the master menu? Customers making changes to the master menu is totally unsupported behavior. Just because you cross out filet mignon and write New York steak doesn’t mean New York steak will suddenly appear in the kitchen.
The waiter never even saw the customer’s change because the waiter memorized the menu at the start of the day and hadn’t looked at the master menu since then. There was no need to, because the executive chef didn’t make any menu-change announcements. The customer should be thrown out of the restaurant and asked never to return.
The folks from the application compatibility team would probably read this and exclaim, “Oh how we wish that last part of the analogy carried over into software!” Some things simply aren’t meant to be changed or manipulated. Sometimes, you just have to leave things alone.
.jpg "Raymond Chen’s")
Raymond Chen’s Web site, The Old New Thing, and identically titled book (Addison-Wesley, 2007) deal with Windows history, Win32 programming and trading candy.