Software Deployment Question

Windows Logo Testing warning on XP

01/21/2004 27846 views
I've tried for several clients to figure out how to disable the "Windows Logo Testing" warnings when installing unsigned drivers (for silent installations when unprivileged users are logged in, via SMS for example), but the assumed GPO settings don't seem to work for me. Am I missing something else? Why can't I prevent the messages from popping up on the user's screen (and the installation from aborting if they don't hit the "Continue" button in time)?

For a better description of the problem complete with detailed screen shots, see my post at http://www.ewall.org/displayarticle93.html

0 Comments   [ + ] Show comments


Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

All Answers

I regret to inform you that what you are asking is not possible.
We are a Locked Down W2K AD environment here. And made a number of attempts at this very thing.

The problem is many fold dependent on if PNP is involved or not.
But basically even if you turn off the security points generally machine policy sets it back on next reboot.
You have to reboot for the changes to be effective.

The only answer is "get the drivers signed", sorry.

Answered 01/21/2004 by: Robo Scripter
Orange Senior Belt

For the curious posterity:

I ended up scripting a work-around with AutoIt. Not very pretty, but it does the trick... More info and a link to download my example at http://www.ewall.org/displayarticle95.html
Answered 03/03/2004 by: ewall
Purple Belt

Maybe I don't understand what you are asking for but then again, maybe I do and this is your answer:

Under Properties of "My Computer"
-Go to "Hardware" tab
-Click the "Driver Signing" button under the "Device Manger" section
-Set it to "Ignore - Install the software anyway and don't ask for approval"
-Check the "Make this action the system default" under the "Administrator options" section
Answered 03/09/2004 by: casperinmd
Yellow Belt


As I explained in the link in the first post, setting this via the GUI or via GPO should fix the problem (according to all descriptions of what that setting does), but it doesn't always work. This is apparently a "known issue" that Micro$oft hasn't really paid any attention to, as plenty of people in other places have seen the same unpredictable behavior. My experience plus hearsay seem to suggest that this setting works on a stand-alone home computer, but not in a 2000/2003 domain; and/or with legacy SETUP.EXE and .INF installs but not Windows Installer-based distributions... but who knows?

Here's to hoping M$ will include this fix in XP Service Pack 2!
Answered 03/09/2004 by: ewall
Purple Belt

One reason why this may appear to be a solution on a stand-alone workstation, but not on a domain would be if your network security policy is overriding your change. This is assuming you are operating in an Active Directory environment.
Answered 03/09/2004 by: bkelly
Red Belt

Nope... This is with the domain-wide Group Policy having the correct setting for "Devices: Unsigned driver installation behavior." (I even verified that the GPO was applied to the local machine using the MMC plug-in "Resultant Set of Policies".) I've seen it at several companies myself, and heard about it at many more.

Again, this was all described with pretty pictures and everything at the link in my first post: http://www.ewall.org/displayarticle93.html

Thanks for trying, all--
Answered 03/09/2004 by: ewall
Purple Belt

Your right, autoit is a very dirty (and possible unreliable) solution. I managed to overcome this issue in the middle of last year when silently installing the IBM iSeries client.

When you switch off the driver signing warning using the GUI you will see that the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\PrivateHash value changes and changes back when you re-enable the warning.

If your organisation has used a base image build then a quick audit will confirm that you have a very small number of PrivateHash values (& therefore base builds). Now all you need to do is switch off driver signing on each build & collect your PrivateHash pairs. Now write an install to check for the "on" value, change the value to the relevant "off" value install the drivers & change it back - et voila!

If you don't have a limited number of PrivateHash values then I'm afraid your screwed unless someone can come up with the algorithm that generates these pairs!

Steve Woolrich

steve AT micramaze DOT com-NOSPAM
Answered 03/23/2005 by: steve@micramaze.com
Yellow Belt

Good tip, Steve! I'm passing it on to own Image Build Master, as he's lately been frustrated with some unsigned driver warnings during the automated build process, and this might work well for that situation. I haven't had any packages with this problem lately or I'd try it myself...
Answered 06/23/2005 by: ewall
Purple Belt

hi ewall.
i tried downloading ur killwindowslogowarning.exe but the link is invalid,
can u plz send me the s/w to my id : mahikool@yahoo.co.in ?
Answered 01/22/2007 by: mahesh123
Yellow Belt

Sorry about that, Mahesh... I just fixed the download links on my website... and emailed you the file as well. Hope it helps!
Answered 01/27/2007 by: ewall
Purple Belt

Alternative solution:
I had a similar problem recently but I approached it differently. The initial reason for getting such a warning is that something went wrong when verifying the digital signature provided with the setup software. The simple reason for this is that the signature file is missing. While creating silent driver installation, you should attach to the xxxx.inf file folder, a parallel xxxx.cat file holding the signature.
If this does not help, this could mean that the validated content of the signed files differs from the original content. To me this happened because I modified the xxxx.inf file a little bit. When making sure I was using the original file, signature verification succeeded and this stopped this "windows logo testing" error from popping up
Answered 02/07/2007 by: mirong
Yellow Belt

This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ