Don't Believe Everything You Read

Don't Believe Everything You Read

  • Comments 3

Recently, I was contacted by a customer who was advised by an ISV to set a registry value under one of the sub keys in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\.  Let's call it UseQuantumComputing = 1 (value name has been changed to protect the ISV).  The customer wanted to know what this value actually did and no one could find any documentation explaining it.  These issues often come to our team because we have access to the Windows source code. I did a bit of code review to find out what this value does.  As it turns out, nowhere in Windows source code between Windows 2000 and Windows Server 2012 do we ever check for or set UseQuantumComputing.

 

I can think of a few reasons the ISV would suggest setting this value.  Perhaps they were under the impression this did something but got confused about the value name.  It's possible they hoped making a registry change would have a placebo effect.  Or, perhaps their software actually checks this value, not Windows.

 

The latter of these possibilities is probably the worst case scenario. An ISV should not create a registry value inside of keys used for Windows’ own internal use. Why? The first reason is that there's no guarantee that Microsoft won't end up coincidentally using that same value name later. This would cause a conflict between the two users of the value.  Second, we have to consider the scenario where two different ISVs both decide to use the same value. That would be bad too.  Lastly, there's no guarantee that the key in use will still exist in later versions, or that it will be writeable or readable by the ISV due to permission changes.  In addition to all these reasons, there is the common sense issue that it is just confusing. Now the ISV's software and uninstaller needs to look all over the registry, not just in their own keys.

 

On a similar note, I also recently had a case where a "Windows Tips" blog (not created, endorsed, or run by Microsoft) suggested using a registry value that was implemented in Windows but was not documented by Microsoft.  It turns out this value wasn't thoroughly tested (because it was undocumented and wasn't intended to be used in production), and using it would cause server hangs under certain conditions.  These hangs were only discovered after a large customer decided to implement the undocumented value across their enterprise. 

 

Here are a few tips for IT Pros, developers, and users alike:

  • Don't implement random registry settings if you can't find documentation for that setting on an official Microsoft site, like MSDN, TechNet, or support.microsoft.com(information on forums or answer boards (e.g. social.*.microsoft.com or answers.*.microsoft.com) is not official documentation).  At best these unknown registry settings they will do nothing, at worst they will cause you headaches later.
  • If a key/value isn't documented, changes to it likely are not tested, and could put your machine in a state that makes it difficult or impossible to support.
  • If you are a developer, keep any of your registry settings in your own key. Don't pollute in others' keys.
  • If an ISV or Microsoft suggests you implement a setting, make sure you understand the implications of that setting.

 

I'll leave you with the warning displayed in many of our KBs - it's there for a reason!

 

WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

 

-Matt

Leave a Comment
  • Please add 8 and 8 and type the answer here:
  • Post
  • This reminds me on a couple of cases I saw recently. The issue was simple - Bugcheck 0x124 on a server. There are specific hardware logs that point to faulty component and the vendor suggests (along with driver and firmware update of the faulty component) to disable intelppm driver by modifying its start value to 4 under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Intelppm. They believe that the system may be crashing due to this driver because it was on the stack of the poor  CPU... This brings me to a question if you can write up some explanatory article about idle CPUs and common analysis mistakes like blaming the intel driver above.

  • A similar rant applies to all these "optimizer" products (registry, memory, ...). Horrible.

  • Along similar lines:  Sticking with Well-Known and Proven Solutions.

    blogs.technet.com/.../sticking-with-well-known-and-proven-solutions.aspx

Page 1 of 1 (3 items)