Is CPU-Z Risky To Run on a Production Server?

There was a conversation on Twitter recently (with the #sqlhelp hashtag) about whether it was completely safe to run the popular CPU-Z utility on a Production database server. The questioner was concerned about possible instability or even a Blue Screen of Death (BSOD) that might occur if you ran CPU-Z on a server.  I can completely understand this concern, but in this case, I think it is overstated. Database Professionals are typically more risk averse and more careful than many other I.T. Professionals, which is an admirable thing. It is very easy for a DBA to cause a lot of havoc with one quick mistake. It is good to be a detail-oriented, careful DBA.

On the other hand, life is full of risks. Everyone has to carefully consider the risks and rewards of any course of action before they decide whether to do something or not. Everyone has a different level of risk tolerance, and you have to find the right balance between being overly cautious and being overly aggressive. I have seen far too many DBAs who are almost afraid to do anything to a system. Afraid to make a configuration change to a SQL Server instance, afraid to drop an index, afraid to use data compression, etc..

One path to becoming a “wise” DBA is combining technical knowledge with good judgment and hard-won experience gained by making decisions and actually doing things as part of your day to day work. Hopefully, most of your decisions are good ones, and most things you try are beneficial, but nobody will have a 100% success ratio. Sometimes, you will fail, or just make a bad decision, but I bet you will learn from your mistake! 

You should also remember that good, experienced DBAs are very hard to find, and thus are quite valuable. Unless you have a habit of making bad mistakes and bad decisions, I would say that your reputation and job are safer than you think. In most cases, your employer needs you more than you need them. Think about that! As Franklin Delano Roosevelt said in 1933, “The only thing we have to fear is fear itself”. Well, it is time to climb down from the soapbox…

Getting back to CPU-Z, all the anecdotal evidence I have is good. I have been using it regularly for many years, running it on many hundreds of servers, never having any problems. Many other well-known SQL Server MVPs piped up with similar results in the Twitter thread. Of course, this is not definitive proof that CPU-Z will never cause a problem for anyone. If you are convinced that CPU-Z might be risky, then no amount of anecdotal evidence is likely to convince you otherwise.

If you have any sort of HA solution in place (such as fail-over clustering or database mirroring), you can always run CPU-Z on a passive node or on the mirror, to pretty much eliminate any possible risk. You can run it on the other nodes or other side of the mirror during your rolling maintenance activities. If you don’t have any HA solution in place, I would say you have bigger things to worry about than CPU-Z.

I would like to hear people’s opinions and experience with using CPU-Z on their systems, good or bad.

This entry was posted in Computer Hardware and tagged . Bookmark the permalink.

12 Responses to Is CPU-Z Risky To Run on a Production Server?

  1. Sankar Reddy says:

    Good sound advice Glenn. This is valuable for guys like me who have less experience dealing with hardware 🙂

  2. Rob Sullivan says:

    I have been running CPU-Z for years without issues with regard to CPU-Z. However, on systems where I had an underlying problem with bad memory/bad overclock/bad configuration I set (not something out of the box) I have run into instances where CPU-Z triggered that issue in a less than delightful manner. Do I blame CPU-Z for this? Not at all, in fact, I thank it for bringing it up to me.

  3. bender says:

    I’ve run it many a time on many a server and not once have I had an issue. In fact, it did help me find and fix many issues. IMHO, the benefit outweighs the risk.

  4. JohnW says:

    CPU-Z dynamically installs a device driver when you open it, and then uninstall it when you close it. By means of comparison I’m most of us schedule maintenance windows when updating drivers, for example.

    That being said…never had a problem.

  5. Andrew says:

    I have ran this on several servers myself (including ultra critical tier 1 OLTP databases) and never once ran into this issue. As a matter of fact, it more often than not helps me identify issues that need correcting. Great tool and I would suggest it as a must have tool.

  6. Paul Randal says:

    Never had a problem with it on my clients’ systems.

  7. Rob Sullivan says:

    Another thing to think about… just because this tool might just now be getting some traction in our SQL Server circles… It has been a widely used tool for hardware/overclocking enthusiasts for a while. And if you think we are a picky bunch… wait until you meet some of those guys. Such scrutiny by that community is likely why the tool is as good as it is.

  8. Glenn Berry says:

    Good point, Rob. CPU-Z has gotten heavy usage by the over-clocking community for a long time. That is how I originally discovered it many years ago.

  9. Pingback: Tweets that mention Is CPU-Z Risky To Run on a Production Server? | Glenn Berry's SQL Server Performance -- Topsy.com

  10. Just don’t leave it running…. I accidentally left it running, for days, on the passive node on one of my clusters and next time I looked it was up to 30 GB of allocated RAM.

  11. Pingback: A SQL Server Hardware Nugget A Day – Day 7 | Glenn Berry's SQL Server Performance

  12. Aaron Kempf says:

    I don’t trust ANY 3rd party software to run on any machine ever. If it wasn’t compiled in Redmond, I Just don’t trust it. Period. Only exception is WinRar and Dreamweaver.

Leave a comment